On Wed, 15 Jun 2016 15:39:01 +0000, פנינה קוניגסברג wrote: >Always interesting, I am dealing this week with an error that I hoped would >be solved by the different solutions presented here, but after trying some of >the solutions presented herein have not recovered. >Background: In preparation for a system cutover, executed IDCAMS LISTC with >SYSPRINT to a PDS file containing very important cutover data. (thought that >was an efficient method of documentation :) - the laugh is on me). >The original file was a typical jcl type (80 lrecl) after running the LISTC >and updating the results, the PDS members which existed prior to the LISTC job >execution were unreadable - IO ERROR. Since the disk was a 'sandbox' type >disk, it wasn't backed up nor dumped. I have been trying various recovery >methods - many of them as advised on this discussion list to not avail. Any >ideas ? Would it be preferable for me to specify the actions I already did >to try to recover the file? > If you allocate the PDS with the original RECFM=FB,LRECL=80,BLKSIZE=????? you should be able to read the older members correctly and the member(s) created as IDCAMS SYSPRINT will receive I/O errors.
That's why I use UNIX files wnenever possible: none of this attributes mickeymouse. DFSMS should *never* permit changing the attributes of an existing nonempty data set. Bad design. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
