Re: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
I would hope FDR full volume restore would do an honest restore and leave the change bits as they were. Of course we do -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris I hope that you will be trying to convince your management to send this to your IBM sales representative or higher. Incidentally how does Innovation's FDR handle this? I've heard that FDR does not touch the change bits on restore. -jc- -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
We were talking primarily about full volume dump/restore. What constitutes a reasonable default for the changed bit for a restore of individual datasets may be different, and more debatable, than what makes sense for a full volume restore. At least when restoring a limited number of known datasets, there conceivably would be some possibility of using some post-restore utility to alter individual dataset change bits if the default didn't suit your purpose. If you are restoring individual datasets, it is highly unlikely that your intent is to restore the entire system to some prior point in time. Whether it makes sense to set, reset, or leave the changed bit as-is in such a case depends on whether or not your system uses DFHSM fast migrate and/or whether another auto-backup of the restored dataset is desired. If you are restoring entire volumes, it is highly likely that you ARE trying to restore the entire system to a prior point in time, in which case the only action that makes sense is an accurate restore without any modification of the change bits. I would hope FDR full volume restore would do an honest restore and leave the change bits as they were. Stephen Mednick wrote: If you're referring to the update indicator in the DS1DSIND field of the F1 DSCB, FDR will by default always turn the update indicator on after restoring or copying a dataset. Stephen Mednick Computer Supervisory Services Sydney, Australia -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Sunday, 1 April 2007 7:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update I hope that you will be trying to convince your management to send this to your IBM sales representative or higher. Incidentally how does Innovation's FDR handle this? On 31 Mar 2007 13:24:05 -0700, in bit.listserv.ibm-main you wrote: Good Lord! What idiot could have thought this counter-intuitive behavior is a reasonable default: When restoring data in a full volume or tracks operation, DFSMSdss resets the data-set-changed indicator in the VTOC entries of each data set that has had its data restored. This is to indicate that the data set has not changed since its last backup. ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Joel C. Ewing Sent: Monday, 2 April 2007 9:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update We were talking primarily about full volume dump/restore. SNIP If you are restoring entire volumes, it is highly likely that you ARE trying to restore the entire system to a prior point in time, in which case the only action that makes sense is an accurate restore without any modification of the change bits. I would hope FDR full volume restore would do an honest restore and leave the change bits as they were. On a full volume FDR restore, every restored track will look exactly like it did when it was dumped and this includes leaving the change bits the way they were. Stephen Mednick Computer Supervisory Services Sydney, Australia -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
Good Lord! What idiot could have thought this counter-intuitive behavior is a reasonable default: When restoring data in a full volume or tracks operation, DFSMSdss resets the data-set-changed indicator in the VTOC entries of each data set that has had its data restored. This is to indicate that the data set has not changed since its last backup. IBM, the first and foremost default function of a volume restore should be to restore a volume to its state at the time of the backup, not try to second-guess whether games should be played with the content on restore!!! You have by this incredibly ill-advised choice made point-in-time Disaster Recovery without potential dataset loss impossible for any site using DFHSM Fast Subsequent Migration and DFDSS as a volume backup agent!!! With the changed bit unconditionally reset, DFHSM will erroneously assume inactive obsolete dataset versions existing on an ML2 tapes are current and delete rather than re-migrate changed versions of the datasets on a restored system at a DR site. Since we DO have DFHSM Fast Subsequent Migration enabled, IBM has managed to put a serious dataset integrity exposure into our whole approach to point-in-time disaster recovery, of which, but for IBM-main, we would still be blissfully unaware. This is a serious enough deficiency in DFDSS that if this is not resolved in one or two months at most, we will seriously consider dropping DFDSS and looking at some alternative DUMP/RESTORE product that supports DR recovery properly. In an SMS environment, because of the random placement of datasets by SMS and the difficulty of accessing un-cataloged SMS datasets, I can only conceive of using full volume restores in two scenarios: (1)recovery of a production volume in a test MVS environment, (2)recovery of all production volumes at DR to restore the entire production system to a prior point-in-time. In neither of these cases does resetting of the changed bit make any sense, and in the latter it is highly detrimental. This is not just a issue with data integrity when using DFHSM fast subsequent migration. It also means that in the event of a point-in-time Disaster Recovery system restore that required DFHSM auto backups that were pending will not take place as well. To me, that should raise this to a Sev 1, data loss concern as users will subsequently assume backups exist when they do not. Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards.Bob Sent: Thursday, December 14, 2006 4:01 PM No, and I just read it a few hours ago in an attempt to help you. That DEFAULT behavior WAS NOT documented. The subject DOC APAR closed today, 26 March. I VIGOROUSLY RECOMMEND anybody who uses DFSMSdss full-volume or track-range (aka physical) DUMP / RESTORE for D/R, data movement, etc. to READ AND UNDERSTAND this DOC APAR. You **ARE** at risk of losing data or data integrity via DFSMSdss Full-volume or track-range (aka physical) DUMP / RESTORE if you have ANY OTHER PRODUCT that depends upon the setting of the change bit in the Format-1 DSCB. The DFSMSdss Level 2 rep also submitted Marketing Request # MR0302074136, requesting that a switch (similar to the RESET keyword on DUMP) be provided to allow the user to specify how DFSMSdss should handle the change bit at RESTORE time. Those interested should add their voices via appropriate channels. SHARE members who have not done so, please vote on Requirement # SSMVSS07002, which requests a design change to DFSMSdss' default behavior on full-volume RESTORE. -jc- ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
I hope that you will be trying to convince your management to send this to your IBM sales representative or higher. Incidentally how does Innovation's FDR handle this? On 31 Mar 2007 13:24:05 -0700, in bit.listserv.ibm-main you wrote: Good Lord! What idiot could have thought this counter-intuitive behavior is a reasonable default: When restoring data in a full volume or tracks operation, DFSMSdss resets the data-set-changed indicator in the VTOC entries of each data set that has had its data restored. This is to indicate that the data set has not changed since its last backup. IBM, the first and foremost default function of a volume restore should be to restore a volume to its state at the time of the backup, not try to second-guess whether games should be played with the content on restore!!! You have by this incredibly ill-advised choice made point-in-time Disaster Recovery without potential dataset loss impossible for any site using DFHSM Fast Subsequent Migration and DFDSS as a volume backup agent!!! With the changed bit unconditionally reset, DFHSM will erroneously assume inactive obsolete dataset versions existing on an ML2 tapes are current and delete rather than re-migrate changed versions of the datasets on a restored system at a DR site. Since we DO have DFHSM Fast Subsequent Migration enabled, IBM has managed to put a serious dataset integrity exposure into our whole approach to point-in-time disaster recovery, of which, but for IBM-main, we would still be blissfully unaware. This is a serious enough deficiency in DFDSS that if this is not resolved in one or two months at most, we will seriously consider dropping DFDSS and looking at some alternative DUMP/RESTORE product that supports DR recovery properly. In an SMS environment, because of the random placement of datasets by SMS and the difficulty of accessing un-cataloged SMS datasets, I can only conceive of using full volume restores in two scenarios: (1)recovery of a production volume in a test MVS environment, (2)recovery of all production volumes at DR to restore the entire production system to a prior point-in-time. In neither of these cases does resetting of the changed bit make any sense, and in the latter it is highly detrimental. This is not just a issue with data integrity when using DFHSM fast subsequent migration. It also means that in the event of a point-in-time Disaster Recovery system restore that required DFHSM auto backups that were pending will not take place as well. To me, that should raise this to a Sev 1, data loss concern as users will subsequently assume backups exist when they do not. Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards.Bob Sent: Thursday, December 14, 2006 4:01 PM No, and I just read it a few hours ago in an attempt to help you. That DEFAULT behavior WAS NOT documented. The subject DOC APAR closed today, 26 March. I VIGOROUSLY RECOMMEND anybody who uses DFSMSdss full-volume or track-range (aka physical) DUMP / RESTORE for D/R, data movement, etc. to READ AND UNDERSTAND this DOC APAR. You **ARE** at risk of losing data or data integrity via DFSMSdss Full-volume or track-range (aka physical) DUMP / RESTORE if you have ANY OTHER PRODUCT that depends upon the setting of the change bit in the Format-1 DSCB. The DFSMSdss Level 2 rep also submitted Marketing Request # MR0302074136, requesting that a switch (similar to the RESET keyword on DUMP) be provided to allow the user to specify how DFSMSdss should handle the change bit at RESTORE time. Those interested should add their voices via appropriate channels. SHARE members who have not done so, please vote on Requirement # SSMVSS07002, which requests a design change to DFSMSdss' default behavior on full-volume RESTORE. -jc- .. -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
If you're referring to the update indicator in the DS1DSIND field of the F1 DSCB, FDR will by default always turn the update indicator on after restoring or copying a dataset. Stephen Mednick Computer Supervisory Services Sydney, Australia -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Sunday, 1 April 2007 7:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update I hope that you will be trying to convince your management to send this to your IBM sales representative or higher. Incidentally how does Innovation's FDR handle this? On 31 Mar 2007 13:24:05 -0700, in bit.listserv.ibm-main you wrote: Good Lord! What idiot could have thought this counter-intuitive behavior is a reasonable default: When restoring data in a full volume or tracks operation, DFSMSdss resets the data-set-changed indicator in the VTOC entries of each data set that has had its data restored. This is to indicate that the data set has not changed since its last backup. -- 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: DFSMSdss DOC APAR OA20117 (was RE: HSM Missing Member from Recalled Dataset -- Update
I'd like to second John's request/recommendation on adding your voices to either the marketing request or the SHARE requirement. The more people interested in a particular change that add their voices/votes, the more it helps the priority get set so that the change gets done. Thanks, Andrew Wilt IBM DFSMSdss Architecture/Development Tucson, Arizona IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 03/26/2007 01:26:32 PM: The subject DOC APAR closed today, 26 March. I VIGOROUSLY RECOMMEND anybody who uses DFSMSdss full-volume or track-range (aka physical) DUMP / RESTORE for D/R, data movement, etc. to READ AND UNDERSTAND this DOC APAR. You **ARE** at risk of losing data or data integrity via DFSMSdss Full-volume or track-range (aka physical) DUMP / RESTORE if you have ANY OTHER PRODUCT that depends upon the setting of the change bit in the Format-1 DSCB. The DFSMSdss Level 2 rep also submitted Marketing Request # MR0302074136, requesting that a switch (similar to the RESET keyword on DUMP) be provided to allow the user to specify how DFSMSdss should handle the change bit at RESTORE time. Those interested should add their voices via appropriate channels. SHARE members who have not done so, please vote on Requirement # SSMVSS07002, which requests a design change to DFSMSdss' default behavior on full-volume RESTORE. -jc- -- 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
