Let me see whether I can add some information about some of the more
common themes before I ask my question (below).
First, although intuitively it would seem we "ought to know," we in fact
*don't* really know how much space every data set will require in
service for every possible mix of products that might share them, or
even how much space will be required to put on the service we have
already built. In fact, until a ServerPac order is built, we don't even
know how much space every data set in a given order will actually
occupy. There are a number of reasons for this. One of them is that
there is no space data included in PTFs; and, even if it were, it would
not actually be 100% useful. (One example: What happens when a part
gets bound into more than one load module and/or program object, in one
or more libraries, and the number of modules into which it's bound and
which libraries are affected depends on which products are installed?)
Another is that the order in which the members of a library is loaded
can affect the space it requires. There are more, and while many or
perhaps even most represent small variances, the algebraic sum of the
number of cumulative small errors we might have will not always be in
our favor.
The most practical, accurate way to find out how much space a data set
will actually occupy on disk is, by far, to load it and look. We have,
in all probability, more important code to write in place of all the
code it would take to solve this set of problems comprehensively. (And
then we'd have to keep it in sync with backstore hardware changes!)
As some have observed, not everything can be a PDSE. The reasons are
pretty well known, I think. This is something Greg Dyck kindly offered
to fix in another discussion thread, but for one reason or another
nobody seems to have taken him up on it. (Maybe nobody wants to lug
around over 110+ pounds of twenty dollar bills.) However, the ServerPac
dialog does have a "switchable" attribute, and the View and Change
displays in Modify System Layout make it very easy to find the data sets
that must be PDSEs if you are interested. More on View and Change below.
In my view, we really do not want people to be able to reduce data set
size below the minimum sizes shipped already. Over the years, we have
already accumulated more than enough experience with "we don't have
enough space for the ___________ data set" problems during package
installation (never mind later service).
As one or two have proposed, we could ask the owners of the ServerPac
dialog to look at a new variable for "increase space for everything by
x%," and to increase default free space to, say, 20%. Does this seem as
though it would be something most could live with? No promises!
Two other notes:
Note 1: Secondary space allocations *are supported* for link list data
sets. There are, however, two related issues. The first is that the
number of extents in the link list is limited to 255, and it is not
terribly hard to hit this limit with a large link list if very many of
the data sets have more than one extent. The second is that if a link
list data set used by a running system is extended, its new extents will
not be represented in its DEB, and attempts to access a member in a new
extent will result in an ABEND106-F, if memory serves.
The second issue can be avoided simply by refusing to update a running
system, which I think most (in my view, everyone who's rational) agree
is the best solution. The first requires you to make sure you will stay
shy of the extent limit even if putting service on the maintenance (not
running) copy of your system causes one or more data sets to be
extended, which is a bit harder because you have to take an extent count
after every APPLY and then apply any necessary remediation.
Note 2: For those unaware, the ServerPac CH(ange) SP(ace) command can be
used to very quickly add space for selected data sets within View and
Change. One example among many: You can display only the link list
libraries and increase the space for all of them. In fact, you can
display using a variety of primary (e.g., "link list eligible") and
secondary (e.g., "Yes" and/or "No") attributes and then use various CH
subcommands to add or remove secondary space allocations where allowed,
change eligible PDSs to PDSE, and so on, very quickly. And with just
one display and one command, you can increase the allocations for
everything. Just pick any primary attribute and display data sets with
all the secondary attributes selected (for example, select link list
eligible, and then select both Yes and No), and issue CH SP. Done!
I do recognize that this is far easier to remember for people who use
the dialog far more often than is likely usual for most readers here,
and for that reason alone it represents a usability issue. I also
understand the value of a variable you can "set and forget" so that it
gets picked up the next time you model after a saved order. But you do
at least have this capability, right now.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
