Clark is correct that the ability to limit maximum dataset size is
missing and needed - this facility has existed in other non-IBM
operating systems for 40 years or longer. But there is another requirement:
The other essential piece is some assurance that requested dataset
extensions can actual be taken, assuming there is still space in the
storage pools. Most application programmers have never fully understood
that there is no guarantee of getting up to 15 secondary extensions
after getting the primary on a volume. Since the primary in the old
days could be allocated in up to 5 extents, that could have immediately
limited the secondary allocations to at most 11, but in reality since
contiguous tracks were required for each secondary and successful volume
allocation only depended on finding enough space for the primary, there
was always the possibility that 0 secondary extensions would be
available when the dataset needed them.
SMS provides a fairly effective solution to the unreliability of
secondary extent availability via appropriate parameters defined to a
DATACLAS, but I strongly suspect some are unaware of this. I don't have
a manual available at this moment, but I believe it is "extent
reduction" coupled with "extended attribute" and the ability to
dynamically add additional volumes to the dataset which enables both
primary and secondary allocations to be satisfied on up to 123(?)
extents per volume and across multiple volumes without the user having
to worry about whether primary or secondary spaces exceed what is
available in free space at that moment on a single volume. The large
number of extents allowed, and allowing an arbitrary number of extents
across an almost arbitrary number of volumes for each allocation, almost
guarantees success unless the entire storage pool is out of space.
Joel C. Ewing
On 08/08/2011 04:38 PM, Clark Morris wrote:
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
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
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
