IEFBR14 merely allocates space. It does not open the dataset in any way. What you are seeing is residual data. SMS *WILL* write an EOF marker when the dataset is allocated, however, you have indicated that SMS is being bypassed Unless you erase (RACF option) data on scratch (or the hardware equivalent), whatever remained on the track from the prior usage is there.
HTH, <snip> Today, there wasn't any activity (other than my testing) on our z/OS 1.13 system. That's why I know that the last successful allocation for a PO data set via JCL had the directory size of 66000 (I ran that allocation, too!). And the next allocation took that blue-sky number and invalidly re-used it. I figure that all of these batch jobs ran in the same initiator, too. I can allocate 66000 directory entries in 10000 tracks, but 66000 directory entries won't fit into the allocation of only one track. Hence the I/O error in ISPF after successful allocation. That would also explain why some of you get the I/O error (like I did with the invalidly big directory size). </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
