Em 20/09/2013 03:42, "nitz-...@gmx.net" <nitz-...@gmx.net> escreveu:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
