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
