One suggestion I would like to make. When a dataset is deleted, a very tiny EOF record is written to each track. Just enough so the actual dasd unit erases all records on that track. If we were still using real 3390s, I would suggest a track full of EOF records. And not an intensive rewrite of the track like ICKDSF TRKRMT or the current VSAM ERASE would do.
On Fri, Sep 20, 2013 at 1:41 AM, [email protected] <[email protected]> wrote: > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
