Re: FDRABR ARCHIVE
Dave, I would definitely recommend you pick up the phone and call the Innovation folks to discuss any misunderstandings you might have with the operation of FDR/ABR. They'll only be too happy to talk with you and review what it is you are doing. As for your comment on a useful equivalet to HSM recycle, you need to review the documentation on FDRTSEL. Stephen Mednick Computer Supervisory Services Sydney, Australia -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Wednesday, 21 May 2008 5:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE No, or I've misunderstood the FDR doc. If you specify catalog retention against the two TAPE DD's, FDR doesn't assign an expire date to the archive dataset. The archive will exist until it is uncataloged. That's why I need two archive steps. One does the NOLIMITs (that FDRABR flat interprets different than HSM) and the other does all the other MGMTCLAS's. The whole backup/archive job has around 40 or 50 steps. A combination of FDRREPORT, REXX, SORT, DCOLLECT, and FDRABR steps. I can't decide if it's kludgy or elegant :) If I'm wrong, I'd like to here about it soon. What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
Hi Dave, Regarding this: |What I don't have as yet is a useful equivalent to HSM recycle. But | I'm using virtual tape with 99,999 available volumes. FDRABR provides a utility call FDRTSEL to recycle archive tapes. FDRTSEL (FDR Tape Selection Utility) can identify older tapes and copy, re-stack, and consolidate tapes to new volumes. The FDRTSEL process will automatically update the Archive Control File and related catalog entries. FDRTSEL will retain the original dump characteristics, archive date, backup data set names, and expiration date. FDRTSEL has options to select archive backups primarily by age, or expiration date, but it can also select files by disk volume or backup volume. Also with FDRTSEL you can put the output tapes under catalog control and maintain a fixed expiration date in the Archive Control File. For more information, please contact Innovation Support. Joe Butz Gibney, Dave wrote: No, or I've misunderstood the FDR doc. If you specify catalog retention against the two TAPE DD's, FDR doesn't assign an expire date to the archive dataset. The archive will exist until it is uncataloged. That's why I need two archive steps. One does the NOLIMITs (that FDRABR flat interprets different than HSM) and the other does all the other MGMTCLAS's. The whole backup/archive job has around 40 or 50 steps. A combination of FDRREPORT, REXX, SORT, DCOLLECT, and FDRABR steps. I can't decide if it's kludgy or elegant :) If I'm wrong, I'd like to here about it soon. What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, May 19, 2008 9:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Dave, In my shop we routinely recall datasets that were migrated 4 to 10 years ago. From your post below you are arbitrarily changing your retpd from NOLIMIT (or don't delete) to 1 year. Have you checked with your users? How about legal? One would think if the original retention was set to Nolimit then the data owner did not want his/her data automatically deleted. From: Gibney, Dave [mailto:[EMAIL PROTECTED] Sent: Mon 5/19/2008 6:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Sounds like Joseph is correct. I am finishing a conversion from HSM to FDR and I found I needed two archive runs. One for MGMTCLAS with all NOLIMIT (which HSM keeps forever and FDRABR keeps a year) where I use catalog control of the FDRABR tape and another step for the rest of my MGMTCLAS's where FDRABR pays attention to SMS rules. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
I read about FDRSEL and expect to use it. The main shortcoming compared with HSM is not direct interface with tape management. Looks like I'll need to parse the output and generate TMSUPDTE statements. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Butz Sent: Wednesday, May 21, 2008 7:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Hi Dave, Regarding this: |What I don't have as yet is a useful equivalent to HSM recycle. But | I'm using virtual tape with 99,999 available volumes. FDRABR provides a utility call FDRTSEL to recycle archive tapes. FDRTSEL (FDR Tape Selection Utility) can identify older tapes and copy, re-stack, and consolidate tapes to new volumes. The FDRTSEL process will automatically update the Archive Control File and related catalog entries. FDRTSEL will retain the original dump characteristics, archive date, backup data set names, and expiration date. FDRTSEL has options to select archive backups primarily by age, or expiration date, but it can also select files by disk volume or backup volume. Also with FDRTSEL you can put the output tapes under catalog control and maintain a fixed expiration date in the Archive Control File. For more information, please contact Innovation Support. Joe Butz Gibney, Dave wrote: No, or I've misunderstood the FDR doc. If you specify catalog retention against the two TAPE DD's, FDR doesn't assign an expire date to the archive dataset. The archive will exist until it is uncataloged. That's why I need two archive steps. One does the NOLIMITs (that FDRABR flat interprets different than HSM) and the other does all the other MGMTCLAS's. The whole backup/archive job has around 40 or 50 steps. A combination of FDRREPORT, REXX, SORT, DCOLLECT, and FDRABR steps. I can't decide if it's kludgy or elegant :) If I'm wrong, I'd like to here about it soon. What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, May 19, 2008 9:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Dave, In my shop we routinely recall datasets that were migrated 4 to 10 years ago. From your post below you are arbitrarily changing your retpd from NOLIMIT (or don't delete) to 1 year. Have you checked with your users? How about legal? One would think if the original retention was set to Nolimit then the data owner did not want his/her data automatically deleted. From: Gibney, Dave [mailto:[EMAIL PROTECTED] Sent: Mon 5/19/2008 6:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Sounds like Joseph is correct. I am finishing a conversion from HSM to FDR and I found I needed two archive runs. One for MGMTCLAS with all NOLIMIT (which HSM keeps forever and FDRABR keeps a year) where I use catalog control of the FDRABR tape and another step for the rest of my MGMTCLAS's where FDRABR pays attention to SMS rules. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
No, or I've misunderstood the FDR doc. If you specify catalog retention against the two TAPE DD's, FDR doesn't assign an expire date to the archive dataset. The archive will exist until it is uncataloged. That's why I need two archive steps. One does the NOLIMITs (that FDRABR flat interprets different than HSM) and the other does all the other MGMTCLAS's. The whole backup/archive job has around 40 or 50 steps. A combination of FDRREPORT, REXX, SORT, DCOLLECT, and FDRABR steps. I can't decide if it's kludgy or elegant :) If I'm wrong, I'd like to here about it soon. What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, May 19, 2008 9:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Dave, In my shop we routinely recall datasets that were migrated 4 to 10 years ago. From your post below you are arbitrarily changing your retpd from NOLIMIT (or don't delete) to 1 year. Have you checked with your users? How about legal? One would think if the original retention was set to Nolimit then the data owner did not want his/her data automatically deleted. From: Gibney, Dave [mailto:[EMAIL PROTECTED] Sent: Mon 5/19/2008 6:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Sounds like Joseph is correct. I am finishing a conversion from HSM to FDR and I found I needed two archive runs. One for MGMTCLAS with all NOLIMIT (which HSM keeps forever and FDRABR keeps a year) where I use catalog control of the FDRABR tape and another step for the rest of my MGMTCLAS's where FDRABR pays attention to SMS rules. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
snip What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. /snip You will use those up faster than you think. I would suggest (as a minimum) at least another 100K volsers, and preferably another 200K volsers. Good luck! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
One other thing, I was forced to make 2 copies to get a longer retention on copy 2. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Eden Sent: Friday, May 16, 2008 7:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: FDRABR ARCHIVE Is anyone using FDRABR to archive SMS managed datasets? The doc says that the COPY1 expiration date is calculated using the F1 DSCB Last Ref Date and the MGMTCLAS LEVEL 1 Days Non-Usage if there is not a specific RETPD specified for the dataset. I do a simulate and datasets with no RETPD specified are getting a years RETPD in the archive file. Any thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
I'm small, about 4.5 terabytes of primary EMC DASD. But I'm in the 20,000s already, so, you may be giving good advice. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, May 20, 2008 12:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE snip What I don't have as yet is a useful equivalent to HSM recycle. But I'm using virtual tape with 99,999 available volumes. /snip You will use those up faster than you think. I would suggest (as a minimum) at least another 100K volsers, and preferably another 200K volsers. Good luck! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
Sounds like Joseph is correct. I am finishing a conversion from HSM to FDR and I found I needed two archive runs. One for MGMTCLAS with all NOLIMIT (which HSM keeps forever and FDRABR keeps a year) where I use catalog control of the FDRABR tape and another step for the rest of my MGMTCLAS's where FDRABR pays attention to SMS rules. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Butz Sent: Friday, May 16, 2008 9:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Hi Tom, I don't see a record of support being contacted on this, so I only have this information to go on. Section 51.01 is the ABR Archive section that discusses the options for Archiving. In the SMS-Managed Volumes section, it references Section 70 to review in addition to Section 51. Section 70.12 'Archive Expiration' addresses most of the different scenarios that can occur. The expiration dates can come from the DSCB, the SMS Management Class, or lastly the default of 365 if ABR cannot calculate the date from other sources. Without seeing the SMS Management Class settings and the operands specified on the ABR Archive, I would have to guess that the SMS Management Class attributes of EXPIRE AFTER DAYS NON-USAGE' and EXPIRE AFTER DAYS/DATE both have a value of NOLIMIT. When this is the case, then the expiration is set to the normal ABR COPY2 expiration which is 365 days. If you are specifying SMSEXPIRE=YES, I'd suggest using SMSEXPIRE=PRT to get the calculations showing how the expiration dates are calculated using the Management Class criteria. Refer to Section 70.12 for this information. You can contact me directly or anyone in support for further assistance with this. Joe Butz Tom Eden wrote: Is anyone using FDRABR to archive SMS managed datasets? The doc says that the COPY1 expiration date is calculated using the F1 DSCB Last Ref Date and the MGMTCLAS LEVEL 1 Days Non-Usage if there is not a specific RETPD specified for the dataset. I do a simulate and datasets with no RETPD specified are getting a years RETPD in the archive file. Any thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
Dave, In my shop we routinely recall datasets that were migrated 4 to 10 years ago. From your post below you are arbitrarily changing your retpd from NOLIMIT (or don't delete) to 1 year. Have you checked with your users? How about legal? One would think if the original retention was set to Nolimit then the data owner did not want his/her data automatically deleted. From: Gibney, Dave [mailto:[EMAIL PROTECTED] Sent: Mon 5/19/2008 6:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FDRABR ARCHIVE Sounds like Joseph is correct. I am finishing a conversion from HSM to FDR and I found I needed two archive runs. One for MGMTCLAS with all NOLIMIT (which HSM keeps forever and FDRABR keeps a year) where I use catalog control of the FDRABR tape and another step for the rest of my MGMTCLAS's where FDRABR pays attention to SMS rules. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FDRABR ARCHIVE
Is anyone using FDRABR to archive SMS managed datasets? The doc says that the COPY1 expiration date is calculated using the F1 DSCB Last Ref Date and the MGMTCLAS LEVEL 1 Days Non-Usage if there is not a specific RETPD specified for the dataset. I do a simulate and datasets with no RETPD specified are getting a years RETPD in the archive file. Any thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html DSLIST - Data Sets Matching TL.YE.LYE1323R.G0001V00 Row 1 of 1 Command === Scroll === CSR Command - Enter / to select action Message Volume --- TL.YE.LYE1323R.G0001V00YT6256 * End of Data Set list TL.YE.LYE1323R.G0001V00 --RECFM-LRECL-BLKSIZE-DSORG FB8027920 PS --VOLUMES-- YT6256 F1 E8E3F6F2F5F6 0001 6C0058 00 01 00 00 C9C2D4D6E2E5E2F24040404040 6C0058A0400400 4000 90 00 6D10 0050 00 82 90005556 00 E5A2 014F0008004F0008 00 DSLIST - Data Sets Matching TL.YE.LYE1323R.G0001V00 Row 1 of 1 Command === Scroll === CSR Command - Enter / to select action Message Volume Tracks % XT Device Dsorg Recfm Lrecl Blksz CreatedExpiresReferred Catalog --- TL.YE.LYE1323R.G0001V00YT6256 1 0 1 3390 PS FB 80 27920 2008/03/28 ***None*** 2008/03/28 CATALOG.MVSICF1.VMVS824 From FDR run COPY1 EXPIRES 2009.136 - COPY2 EXPIRES 2009.136 FOR DSN=TL.YE.LYE1323R.G0001V00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDRABR ARCHIVE
Hi Tom, I don't see a record of support being contacted on this, so I only have this information to go on. Section 51.01 is the ABR Archive section that discusses the options for Archiving. In the SMS-Managed Volumes section, it references Section 70 to review in addition to Section 51. Section 70.12 'Archive Expiration' addresses most of the different scenarios that can occur. The expiration dates can come from the DSCB, the SMS Management Class, or lastly the default of 365 if ABR cannot calculate the date from other sources. Without seeing the SMS Management Class settings and the operands specified on the ABR Archive, I would have to guess that the SMS Management Class attributes of EXPIRE AFTER DAYS NON-USAGE' and EXPIRE AFTER DAYS/DATE both have a value of NOLIMIT. When this is the case, then the expiration is set to the normal ABR COPY2 expiration which is 365 days. If you are specifying SMSEXPIRE=YES, I'd suggest using SMSEXPIRE=PRT to get the calculations showing how the expiration dates are calculated using the Management Class criteria. Refer to Section 70.12 for this information. You can contact me directly or anyone in support for further assistance with this. Joe Butz Tom Eden wrote: Is anyone using FDRABR to archive SMS managed datasets? The doc says that the COPY1 expiration date is calculated using the F1 DSCB Last Ref Date and the MGMTCLAS LEVEL 1 Days Non-Usage if there is not a specific RETPD specified for the dataset. I do a simulate and datasets with no RETPD specified are getting a years RETPD in the archive file. Any thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
