All, > Be aware of the trap that Elardus hinted to: your allocation can be > modified by ACS routines, possibly differently on different LPARs, > caused by different variables passed to it.
Thanks for testing. On our system, I am the master of everything (SMS, allocation), you name it. There isn't anything defined in SMS to take over. All I am doing in SMS is sent everything to an SMS-managed volume (with the exception of a few things that should be non-SMS). No data classes defined. No ALLOCxx anywhere in the parmlib concatenation, so we're taking all the defaults. It is interesting that some of the newly allocated data sets (nothing but allocation via iefbr14) contain one or more members already. In that case I would also think that something is done using "helpful ACS routines". Oh, and to trick SMS, you could change the DSORG to POU (unmovable). On my system such a data set ends up on a storage mounted volume, which in non-SMS, despite the ACS routine sending it to an SMS volume. As few interference from ACS as possible. 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). Since I already knew that the allocation was invalid, I didn't even attempt to edit the newly allocated data set. >Maybe a minor correction could be asked to IBM. Yes, but I am not in a position to report any bug to IBM, no matter how valid the bug, since the RDT licence does not include 'bug fixing' support, much less 'bug reporting' support. And in case you're wondering: I stumbled across this trying to set up test cases for our own product. I did not intend to test IBM allocation! :-( Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
