elardus.engelbre...@sita.co.za (Elardus Engelbrecht) wrote:
John Eells wrote:
Yeah, we can't win there.
You can and you have already won. The fact is, with each system there is a list
of space requirements in the program directory and/or installation manual.
Use these lists and add about 10-50% or more extra depending on your own
requirements and past installations.
PDS and PDSE directories are somewhat trickier to do estimates of course.
I hope to be able to get rid of program directories some day. But in
the meantime:
Anything released in the past 15-20 years has listed the space required
for each data set using a standard block size (SDB for most, 32,760 for
load libraries, and a specific block size for fonts, if memory serves).
Anything older that that uses (for the most part) arbitrary block
sizes, and for a variety of historical reasons, such a product might
have a program directory that significantly mis-states space
requirements in either direction. Further, products tend to "grow" as
PTFs get applied, and older products can have had significant "growth"
since new. I'd guess that there are plenty of older products still
around and in use.
Theoretically, ignoring the problem above, to find the space for, say,
LINKLIB, you to find the space required for all of the products that
have one or more members in it and add them all together. Once you're
done, if all the space tables in all those program directories are
perfect, you will have a total that is larger than necessary because we
don't list fractions of tracks (or cylinders) in program directories.
You will have a directory allocation that's larger than necessary for
the same reason. Repeat for all the rest of the shared data sets, with
similar results. Now, I'll certainly admit that "larger than necessary"
certainly beats "smaller than necessary," but this isn't ideal for a
broadly shared data set.
Then, there are special cases, like NUCLEUS (another shared data set),
where the size of the largest member plus some fudge factor to allow for
growth of that member has to be available as minimum free space to be
able to have a reasonable chance of updating it without a space abend.
That number plus the normal free space buffer have to be added to arrive
at an appropriate free space value.
This is why ServerPac production detects the space actually used by each
data set after they are populated, adds a percentage of free space (and
directory space), and handles the special cases to create the space
values in the configuration table that is used to allocate the data sets
on your end. This is also the primary reason ServerPac no longer lets
you change the block size in the installation dialog. Choosing other
values just let people run out of space faster, and in some cases even
fail to load the data sets in the first place.
The free space I was referring to when I said "we couldn't win" is the
default space we ship for each data set in those tables used to allocate
the data sets. The free space in those tables is an imperfect
compromise between minimizing disk space requirements for installation
and limiting your exposure to x37 abends when installing service.
For making reasonably sure you can put on a few years' worth of RSU
service, the combination of ServerPac's View and Change option of Modify
System Layout and the CH(ange) SP(ace) command is your friend. It will
let you increase the space for whatever subsets of the data sets in the
configuration you want by whatever percentage you deem appropriate to
allow for future service.
At some point we should reopen the discussion about how much free space
is "enough" without it being "too much." The last time we had it,
people were leaning toward more than we provide as a default today, but
we knew z/OS V2.1 was going to have a significant bump in required space
because of the new font element, and 2.2 a somewhat smaller one because
it includes z/OSMF, so I thought letting the dust settle first might be
good. If we're looking at this the wrong way, don't be shy about
telling us so!
<snip>
--
John Eells (Product packaging and ServerPac Design alumnus)
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
