> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, |
A likely result from reading a block larger than the blksize. > DCB > > 000224D8.:0224DF. LENGTH(X'08')--All bytes contain X'00' > 000224E0 01D10000 00F43026 002FE5A2 05025C70 | .J...4....Vs..*. | > 000224F0 00004000 00027390 02010580 5000F208 | .. .........&.2. | > 00022500 00B84848 008C5A6C 1AE30E68 00CA99F8 | ......!%.T....r8 | > 00022510 0A018238 021903E8 30013030 00027400 | ..b....Y........ | > 00022520 00000000 00000000 000000C8 00000000 | ...........H.... | > 00022530 00000000 > The first dataset is VBS with LRECL=200,BLKSIZE=1000 > The second dataset is VBS with LRECL=230,BLKSZIE= 1150. decimal values in hex: 200 -> c8 230 -> e6 1000 -> 3e8 1150 -> 47e I see 3e8 at 22516, this is likely the BLKSIZE 1000 DCBLRECL is 18 decmal bytes from *after* blocksize (20 bytes from BLKSIZE) That's 22528 which contains 00c8 -> LRECL 200 The DCB contains the BLKSIZE/LRECL from the first dataset of the concatenation. This would result in QSAM trying to read an 1150 byte block in the second dataset with a read for 1000 bytes and getting a wrong length record I/O error. The unlike cocatenation close/open didn't merge in the new BLKSIZE and LRECL. Why not? Perhaps because they were already set before the first open... What does the *SOURCE* DCB & JCL look like? Do either specify LRECL and/or BLKSIZE? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
