On 8 Aug 2011 13:58:44 -0700, in bit.listserv.ibm-main you wrote: >On Mon, 8 Aug 2011 20:43:03 +0000, Ted MacNEIL wrote: > >>>Does this then allow the programmer more space than initially >>>requested/intended, or does it deduct 1 from the number of >>extents allowed when it does this? 123...122...121... >> >>Why would it deduct anything? >>It's a single extent after consolidation. >> >I was thinking of the case where a programmer used SPACE() cautiously >to limit the space occupied by a data set -- he might prefer to endure a >Sx37 rather than have a single data set written by a runaway program >devour an entire volume and likely cause other programs to fail. > >>Also, the extent limits have been raised, as of 1.7. >> >I hope I telegraphed my awareness of this by "123..." supra. Or is there >yet more than I'm aware of. Regardless, the increase from 15 to 123 much >thwarted the design of my hypothetical cautious programmer. > >Is the behavior of z/SO becoming more UNIXy? Time was when a >programmer coded SPACE() he knew he was allowed that much and >no more. Nowadays it's less determinate.
Long ago space allocation should have been changed to be initial, increment, maximum rather than just initial and increment. One way to do that might be to honor the OUTLIM parameter for all data sets. Clark Morris > >-- gil > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
