Hello,
(a) are you sure that the management class is question is using "expire
date/days" rather than "expire non-usage" ?
It's very easy to inadvertently reset the last reference date on a dataset.
(b) if it was migrated, is the hsm secondary space management working properly?
look at the logs for that dataset and see if there's a mention.
As previously stated, there may be an return code against it.
Usual issue is a "rc= 53" which means Hsm expects it to have a backup but it
doesnt, so Hsm won't delete it.
A simple hsm backup will sort that one, but if you have multiple RC 53's you
may have a flaw in sms routines, like allocating a dataset with a "backup"
mgmtclas to a "no backup" Storage group or Hsm died during its Automatic backup
cycle sometime and flags are out of sync.
For migrated "rc= 53" datasets its recall and backup.
If you've got multiple 53's during primary space management a backvol total for
the pack concerned will sort it.
It's good practice to undertake occasional "Backvol total" backups for all
storagegroups/packs where every dataset on a pack will be backed up regardless
of a recent backup (if mgmtclas specified) to tidy up issues like this.
There is a patch you can use to disable checking for backup before expiry, but
this is a sledgehammer approach.
You are better off checking for errors now and then to identify flaws.
Regards,
Dave
***********************************************************************************************
Uriel,
I think David's on to something here.
HSM will not delete a dataset that is supposed to have a backup but doesn't.
Check your HSM space management job output and look for code 53 errors. These
are delete candidates that don't have backups so HSM can't delete them. Do your
datasets show up on this list? If so, they need backups or need manual
intervention.
David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:[email protected] <-- New Address
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of O'Brien, David W. (NIH/CIT) [C]
Sent: Tuesday, October 09, 2012 11:35 AM
To: [email protected]
Subject: Re: DFSMSHSM Management Class Question
Uriel,
Do the unexpired datasets have HSM backups?
-----Original Message-----
From: Uriel Carrasquilla [mailto:[email protected]]
Sent: Tuesday, October 09, 2012 2:32 PM
To: [email protected]
Subject: DFSMSHSM Management Class Question
I have a situation that I am hoping someone can shine some light.
I am conflicted by a behavior in our zOS 1.11 system.
We have a Management Class defined to expire datasets after a given number of
days.
I know it is working because I found some datasets about to expire, waited for
them to expire, and now I can see they are no longer in the catalog (the
management class stipulates that we keep one backup for a few years after
deleting).
But, I also noticed that some files that have exactly the same management class
and should have been expired/deleted a long time ago are still catalogued. I
recalled one of them and it had no expiration date and confirmed that it
belongs to the same management class.
I am trying to figure out why this behavior is taking place but don't know
where to go next.
Any suggestions would be greatly appreciated.
Sincerely yours,
Uriel
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
