Wow, this has snowballed. To summarize: I am allocating a DSORG=PO data set with an explicit zero space value for directory blocks. This data set *is* SMS-managed. The ACS routines don't interfere with any DCB attributes, and there is no ALLOCxx anywhere within the parmlib concatenation. (And I came across this when I set up testcases for our own product.)
The data set allocated will not show a consistent value of zero for the directory information. Instead, it takes whatever is written on DASD where the data set is allocated as directory information. VSM UseZosV1R9Rules(YES) does not influence the outcome. 1. I used a valid allocation (DSORG=PO,SPACE=(TRK,(10000,0,66000))). The data set ended up on volume SMS003. 2. Delete the data set, rerun the job using DSORG=PO,SPACE=(TRK,(10000,0,0)). ISPF shows the data set on SMS003 as having 66000 directory blocks. (0 was specified, clearly an error.) 3. Delete the data set, rerun the job using DSORG=PO,SPACE=(TRK,(1,0,0)). ISPF shows the data set on SMS002 and I get "I/O error" in ISPF for the "i" line command. I believe that gil's hypothesis correct: Since the specified directory blocks is 0, allocation does not format a directory, and does not write the terminating EOF. Later, allocation sees that DSORG=PO, and does not write an EOF (which would be real, not pseudo) at the beginning lest it destroy the directory had it created one. Subsequent behavior depends on the residual content of the first allocated track. Doug found this IBM statement in SC26-7407-07 DFSMS Implementing System-Managed Storage: "The system provides data integrity for newly allocated data sets that have not been written to. For these data sets, whether SMS managed or non-SMS managed, DFSMSdfp writes a physical end-of-file character at the beginning of the data set when space for the data set is initially allocated. This makes it unnecessary to OPEN data sets for the sole purpose of writing an EOF and to avoid reading old data if the data set is read immediately after being allocated." This is clearly not true in my test case above. I agree with Gerhard on "In any case, IBM should be persuaded to either produce a JCL error or modify the directory build to write an EOF." I tend to the second solution: Write the EOF in any case. (In setting up my testcases, I have used IEBDG excessively, and quite a few allocations that succeeded nevertheless produced unusable data sets. So I don't think a JCL error is the way to go. But correct setting of the EOF marker should be required and should be aparable, since the manual clearly says that that should have happened. Doug also found this in SC26-7410-11 Using Data sets: "To allocate a PDS, specify PDS in the DSNTYPE parameter and the number of directory blocks in the SPACE parameter, in either the JCL or the data class. You must specify the number of the directory blocks, or the allocation fails." I reran the DSORG=PO,SPACE=(TRK,(10000,0,0)) job explicitly specifying DSNTYPE=PDS (and with VSM UseZosV1R9Rules back to NO). Note that directory blocks are specified! This time the data set ended up on SMS001 but still shows 66000 directory entries. Then I deleted and reran, the data set ended up on SMS004 and I got I/O error. Presumably that means we don't do erase on scratch. If anyone wants to report this to IBM as a bug, feel free. I would do it, but our contract doesn't allow me to report bugs. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
