On Sat, Apr 24, 2021 at 08:05:26PM +0200, Peter Sylvester wrote: > then beginning with the directory blocks, you always have a 12 byte > header which contains the length of the followong data. there are > zero length records to terminate.
Have you done EXCP or built channel programs for DASD? I would think you would recognize a DASD CKD count field if you had... That's what IEBCOPY writes for each block. Here's the first IEBCOPY unload record from a load library PDS (directory): record 7 offset 28c length be0 0000: 0be0 0000 0000 0000 0000 0000 0008 0100 |.\..............| 0010: c1e2 c3c2 4040 4040 00fc c1c2 c5d5 c4f0 |ASCB .ÜABEND0| 0020: c3f1 0000 262c 0000 2c00 0000 0000 c3f2 |C1............C2| 0030: 0000 0800 0800 0000 8800 0001 0000 c1c3 |........h.....AC| 0040: c6d7 d9e3 4040 000b 282c 000b 2d00 0000 |FPRT ..........| 00: 0be0 0000 - block length in BDW/RDW format 04: 0000 0000 - zeros, perhaps for alignment? 08: 0000 0000 0008 0100 - DASD count field: CCHHRKDD -> note the 8 byte key for a directory block 10: c1e2 c3c2 4040 4040 - actual 8 byte hardware key from disk block 18: 00fc - bytes used in directory block (& start of dir block) Now the count field written for directory blocks isn't real as the CCHHR is always zero. The data records have the original CCHHR values. IEBCOPY matches the CCHHR values with the TTRs from the directory entries to know which blocks belong to which member. Which also takes knowing the dataset extents, which is why they are in the copyr2 record (along with the device type information in copyr1). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
