From: Ravi Gaur <gaur.ravi2...@gmail.com> Date: 03/22/2013 05:31 AM
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).. ------------------------------- I'm going to ask a dumb question. I do not expect an answer. Did you have the SYSUT3 and SYSUT4 DDs specified? If so, were they specified in CYL not TRK, and with NO secondary, and CONTIG? Given the size that you have said this PDS is, I would fully expect IEBCOPY to have needed the SPILL datasets in order to do the compress (even with 1600 or fewer directory blocks). ------------------ Requirement: SYSUT4 must be in a single contiguous extent, because SYSUT4 will contain a copy of the output partitioned data set directory. The design of data management requires that a partitioned data set directory be within a single extent. IEBCOPY ignores all DCB information that is specified for SYSUT3 or SYSUT4. ------------------ z/OS DFSMSdfp Utilities SC26-7414-03 Regards, Steve Thompson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
