> In my case it certainly is NOT by ACS-routines! I can only think of reuse of > space with a (part of) member index. > > And this must in a production environment imply a security leak ?!
Having spent quite a bit of time recently with the different ways a DCB is populated, this is an invalid allocation. There are warnings liberally sprinkled that it is the responsibility of the program opening the dataset to make sure that all relevant information is consistent and available. As far as I know (but I may be wrong) I cannot change the directory space allocation after the data set was allocated (at least not without a lot more than average knowledge of internal data structures). That's why I would have expected either an allocation error or at least some sort of consistent setting for the space information. I did specify DSORG=PO (which was honoured), and the allocation did not honour the 0 directory blocks that I had explicitly specified. Instead a number (66000) that wasn't specified in this job is used (last successful space setting in this initiator, a blue-sky, random number), and that (in my opinion) is a bug. I don't dare comment on this being a security leak. Wasn't there something with allocation that lead to an explicit eof being written in case of a sequential data set to prevent reading the tracks due to such an allocation? Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
