If it is a physical dump, is there a way to search for matching VTOC entries on the tape?
Or could a SPHERE keyword get all associated VSAM files? On Thu, Jan 24, 2013 at 3:20 PM, Joel C. Ewing <[email protected]> wrote: > If the original problem was that the dataset was inadvertently deleted, then > you would have lost the catalog and VVDS entries as well. But if you know > the approximate time of deletion and have SMF records from that period, you > could use freeware DAF (Dataset Audit Facility) from Michael Cleary > https://sites.google.com/site/michaeljosephcleary/home/freeware > to scan SMF records and see if an INDEX component was deleted at the same > time and what volume(s) it was on. > > If all you have is a physical volume DUMP as stated, dss TYPRUN=NORUN would > probably be unable to provide any CLUSTER association info, and the INDEX > component might be on another volume and not even in the same dump. Short > of lfinding both DATA and INDEX components in the same dump, recognizing you > had a KSDS would be difficult without either the old catalog entry or the > original IDCAMS DEFINE statement. > > One requirement we had was that every production (and test counterpart) VSAM > dataset had to have a corresponding member in a "known" PDS that gave the > IDCAMS statements for redefining the data set (and any alternate indices), > so that in-house utilities could reorganize the file if necessary, or so you > would at least have some place to start in event of dataset loss and there > would be no question about the data set attributes. > > I've never considered trying to recover KSDS records from just the DATA > component from a physical volume dump, but if this was a KSDS with INDEX on > a different volume that could be the case you face. If it can be done by > faking it as an ESDS, at best you could only recover the data records in > physical CI order, not key order, as any CI splits and CA splits in the > original KSDS would render the logical ordering of the CI's unknown without > the corresponding INDEX CI's. > JC Ewing > > On 01/24/2013 12:39 PM, willie bunter wrote: >> >> Boris, >> Thanks for the valuable information. One last question. With the >> problem I encountered, since the dataset was restored from a physical DFDSS >> backup, only the DATA component was restored. I tried the LISTCAT of the >> .DATA component and since there was no cluster the LISTCAT was unsuccessful. >> In this case, how would I be able to tell what type of VSAM dsn it is? >> >> >> ________________________________ >> From: Boris Lenz <[email protected]> >> To: [email protected] >> Sent: Thursday, January 24, 2013 1:00:54 PM >> Subject: Re: DIFFERENTIATION OF VSAM DSNS >> >> >> On Thu, January 24, 2013 18:25, willie bunter wrote: >>> >>> I checked the LISTCAT however I didn't see anything. Any suggestions? >> >> Examine the output of LISTCAT ENT(/) ALL. >> >> KSDS: >> - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. >> - has an INDEXED ATTRIBUTE in the DATA section. >> >> VRRDS: >> - has DATA+INDEX ASSOCIATIONS in the CLUSTER section. >> - has a NUMBERED ATTRIBUTE in the DATA section. >> >> ESDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a NONINDEXED ATTRIBUTE in the DATA section. >> >> LDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a LINEAR ATTRIBUTE in the DATA section. >> >> RRDS: >> - has only a DATA ASSOCIATION in the CLUSTER section. >> - has a NUMBERED ATTRIBUTE in the DATA section. >> >> Regards, >> Boris >> >> > ... > > -- > Joel C. Ewing, Bentonville, AR [email protected] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
