Hi Marjory, Yes, we met before, I think already on the famous European User Conferences organized by Germany and a few years ago we had contact about the problem where GDGs were incorrectly expired because of IXMNAINT problems with the Catalog Search Interface.
I have investigated what happened with the backups and found as I stated, the backup created on day 10 became extra backup on day 100 and on the next IXMAINT run received an expiration date of 10+50=60 and was expired that moment. IXMAINT says it was deleted because its expiration date was day 60. My problem is, that I read this also from the SMS manual: http://www.bookserver.ces.klm.nl/bookmgr-cgi/EPHBOOKS/FRAMESET/MVSDATA.BOOKMGR.ZOSV1R11.DGT2S680.BOOK/1.6.4.7?SHELF=MVSDATA.BOOKMGR.ZOSV1R11.DGT2BK91.BKSHELF&DT=20090610113354&ACTION=MATCHES&REQUEST=Retain+Days+Extra+Backup&TYPE=FUZZY&CASE=&searchIndex=INDEX&searchText=TEXT&searchTopic=TOPIC&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT It seems to be working as designed, but not as desired by users. Of course, if you take daily backups like the example in the manual assumes, it works rather well. However, if you take irregular backups, it turns out to be complete useless. So my question is whether HSM really does work this way. If so, CA-DISK is working correctly and I can only submit an enhancement to IBM. I am quite sure HSM is working this was, but I am looking for proof. I you wish, you can set up a test case easily, with smaller periods. The crucial point is when the Retain Days Extra Backups start counting: from the day the backup was taken or from the day the backup became Extra Backup. I just read that Allan is preparing a testcase. Let's wait what the outcome is Regards, Kees. -----Original Message----- From: Marjory Montgomery [mailto:[email protected]] Sent: dinsdag 26 juni 2012 21:15 To: [email protected]; Vernooij, CP - SPLXM Cc: Marjory Montgomery Subject: Re: SMS Retain Days Extra Backup Versions - question. Hi Kees, I'm fairly sure we met before. I'm the Product Architect for CA Disk and have worked on it since 1983 when it was DMS/OS. I believe you are might be correct however there are other Factors. The z/OS V1R12.0 DFSMShsm Storage Administration manual states: You can control how long to keep extra backup versions for data sets, how long to keep the only backup version of data sets that have been deleted, and how long to keep specific backup versions. (DFSMShsm does not delete the only backup version of a data set that exists unless you specifically delete the backup version.) The attributes that control the number of days to keep extra backup versions are overridden by the attributes that control the number of versions to keep. That is, if you have more backup versions than are specified by the appropriate NUMBER OF BACKUP VERSIONS attribute, the excess versions are deleted by the EXPIREBV command even though they may not have reached the age specified by the RETAIN DAYS attributes. The retention period for a specific backup version can be specified with the RETAINDAYS keyword on the data set backup command. The value specified on the RETAINDAYS keyword overrides all other retention values. The RETAIN DAYS EXTRA BACKUP VERSIONS attribute controls the number of days that you keep backup versions that are older than the most recent one. You can specify values from 1 to 9999 or NOLIMIT for this attribute. If you use the NOLIMIT value, you can delete extra backup versions based on the following criteria: • The value you assign to the NUMBER OF BACKUP VERSIONS attribute. • The issuance of a DFSMShsm command to delete specific backup versions. • The value assigned to the RETAIN DAYS ONLY BACKUP VERSION attribute. Note:All remaining backup versions are deleted after the retention period specified if you assign a value other than NOLIMIT. We would really have to know all the values specified in your management class to see when the backup copy should be expired. You have the SMSPRINT DD statement in Ixmaint that lists why we deleted the backup copy. What does it say? Marjory Montgomery, CA Technologies Software Architect ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
