John, These DFSMSdss dumps were not from AUTODUMP, were they? Because if they were, the DUMPCLASS could have the RESET keyword in its definition.
Bob Richards -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Thursday, December 14, 2006 12:34 PM To: [email protected] Subject: Re: HSM Missing Member from Recalled Dataset -- Update > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of Jack Kelly > > or the changed bit was reset and hsm thought that the dsn had > not changed and then reconnected? Opened a PMR with DFSMShsm, and among other things they explained how hsm determines a dataset's eligibility for "Fast Subsequent Migration" (FSM), or "reconnection" to the most recent migration copy: " [H]ere is the general logic behind the eligibility checking for FSM (aka reconnection): The "change bit" (DS1IND02) is checked in the Format1 DSCB of the dataset being evaluated for possible reconnection. If the bit is on, the dataset is migrated normally, that is, no reconnection is attempted. If the bit is off, DFSMShsm must determine if that is the case because the dataset has not been opened for output since being recalled, or if DFSMShsm turned the bit off when it backed up the dataset after it was recalled. This determination is made using information in our BCDS. If the BCDS indicates that the dataset was backed up on or after the date of recall, the dataset is migrated normally (no reconnection). If the BCDS shows that no backup copy exists at all, or that the most recent backup copy was made prior to the recall, the dataset is deemed eligible for reconnection since there is no evidence that it has changed since being recalled." We had "moved" the volume containing the updated dataset to the new datacenter via DFSMSdss full-volume dump of the source volume to tape, followed by full-volume restore to the new target volume in the new datacenter. HSM level2 consulted with DSS level2, and were informed that DSS does NOT reset any "change bits" unless explicitly instructed to do so via the RESET keyword in the DUMP command. Note that we did NOT specify RESET anywhere, at any time. Yesterday I performed a test on our "sandbox" system and found that the DSS DUMP FULL / RESTORE FULL sequence DOES reset ALL "change bits" on the target volume, WITHOUT having specified RESET. I forwarded doc of my test to IBM, and DSS now has the PMR. They are examining my doc and will attempt to duplicate my result in their lab. LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] ---------------------------------------------------------------------- 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
