EXPIREBV is run daily. FWIW, this same problem plagues certain GDG datasets as well. However, this is not a system-wide problem.
David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Monday, July 08, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups <snip> The datasets are created by a weekly job which creates a new dataset with a LLQ containing the date (e.g.: D130701. Hence, there is no change to the original dataset. This means only one backup is created. However, the backup gets deleted at the time the original dataset expires -- intermittently. </snip> As far as I can tell, this should not be happening. From the online help for Management Class (SYS1.DGTPLIB(DGTHMC41)): <QUOTE> RETAIN DAYS The value in the RETAIN DAYS ONLY BACKUP data column shows how ONLY BACKUP long the most recent backup version of a data set will be kept ---(15)---- after the data set is deleted or if RETAIN DAYS EXTRA BACKUPS 24 has the value NOLIMIT, how long all remaining backup versions of a data set will be kept after the data set is deleted. Possible values: 1 to 9999 After a data set is deleted, keep its most recent backup version for this number of days. If RETAIN DAYS EXTRA BACKUP VERSIONS has a value of NOLIMIT, then all remaining backup versions will be deleted after the retention period as well. NOLIMIT After a data set is deleted, its most recent backup version or versions will be kept for an unlimited period. </QUOTE> So, to summarize to this point: A dataset is created weekly with a LLQ that is unique. Thus the original dataset will be kept for 35 days with only one backup. The specification to keep 3 backup versions is superfluous, since each LLQ will generate a unique dataset. According to the specification, the backup should be deleted 70 days after the original dataset is deleted (or 105 days from creation). The only thing I can see, is that someone/thing is referencing the dataset during the 35 days, which would generate a conflict between EXPIRE NON USAGE and EXPIRE DATE/DAYS. Another quote from the online help for Management Class (SYS1.DGTPLIB(DGTHMC34)): <QUOTE> EXPIRE The value in the EXPIRE NON-USAGE data column shows how NON-USAGE many days an unaccessed data set or object in this ---(3)--- Management Class can exist before expiring. Data sets or 100 objects become eligible for expiration when the number of days since last access reaches the value in this column. Possible values: 1 to 93000 NOLIMIT If both the EXPIRE AFTER DAYS NON-USAGE and EXPIRE AFTER DATE/DAYS fields have a value of NOLIMIT, the data sets or objects never expire. If either field has a value of NOLIMIT and the other field specifies an expiration date or the number of days until expiration, the data sets or objects expire at that specified time. If both fields specify expiration dates or the number of days until expiration, the data sets or objects expire on the later date. The following special characters may appear in this data column: ??????? If the value cannot be displayed due to a data conversion error. </QUOTE> (Expire after Days Non-usage . : 35 Expire after Date/Days . . . . : 35). I would suggest either DAYS NON USAGE or DATE/DAYS, but not both. Since the datasets are SMS-managed, I do not believe EXPIREBV will have any impact, however, how often does EXPIREBV run? HTH, ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
