We also once had a situation like this, where a PDS with ca. 12.000
members got
unusable during compress, the directory was overwritten and unusable.
But we managed to read the members sequentially without using the
directory,
this way moving the members to another dataset, naming them with generic
names
like M0000001, M0000002 and so on. IIRC, we did this with an ASSEMBLER
program,
which simply ignored EOF condition and continued reading ... the EOF
condition signalled
the start of a new member.
Drawback, of course, was, that we got all the deletes members, too, and
that we had to
recover the original member names from the content, but this was
possible for most of
the 12.000 members (although hard work). There was no (actual) backup,
only out-dated
backups.
The content was module descriptions, that is: documentation text. No
source code,
but very important, anyway.
Kind regards
Bernd
Am 22.03.2013 10:31, schrieb Ravi Gaur:
We had a very weird situation where one of the TSO user compressed the PDS
dataset which had 6000+ members however eventually the JCL in all of these
members got similar atmost ..so look like during stow somehow same memory
overlaid or Directory TTR got wrong...
We had no backup of the dataset and then have had to create new and with best
knowledge or recovered members from 2011 ...
Now challenge been to figure out what really happened and any way to restore it
back to the stage it was compress(been push it's not possible... but thought to
bring it on table)..
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
