IMHO you can do the following:
a) the easiest. Just add a step "increase library size". Red letters in
the Dialog, bold the manual. Clearly put exact commands with *suggested
parameters*. That's what I teach people. ;-) Cost of the change is marginal.
b) Provide recommended size. It can be additional field for each library
or just predefined % amount. Be generous - disks are cheap (when
compared to z/OS or CPU). Or even simpler: just increase the size and
allow people to decrease it it they want.
c) variant of b). Use different % values for zero-secondary libraries
and maybe some others.
d) add some simple (rexx script?) tool for increasing library size.
Mostly usable for offline servicing. Maybe invoked automatically by
SMP/E during x37 processing. Of course it won't solve volume full
problem (unless it'd be enhanced to move the library to other volume,
with DDDEF update).
BTW: You ask which libraries should be increased - YOU (IBM) should know
it, we apply there PTFs from IBM. Some stats form the past would be
helpful (yes, it's boring job).
Last, but not least: John, THANK YOU for joining the discussion. I
appreciate it.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2014-04-28 21:58, John Eells pisze:
One or two people at the past SHARE voiced this very same opinion.
Let's say, for the sake of argument, that that's four so far. How do
others feel about this?
First, some background: As I recall, the current design of the
ServerPac dialog does not allow space to be reduced below the default
shipped values, which with a few exceptions include a fixed percentage
of free space. There are sound reasons, in my opinion, to NOT allow
those values to be reduced from what is shipped today.
Historically, those values have been minimized to help prevent the
allocation of additional disk volumes when orders for, say, z/OS and
other products included in z/OS orders don't happen to occupy space
that's comfortably far away from typical volume boundaries. Editing
the ALLOCDS job to reduce allocations and fit within a given number of
volumes is painful. Running out of space during service APPLY
processing is painful. Allocating additional volumes is painful.
On the other hand disk volumes are, by and large, probably rather
larger these days. But we've no direct view of what everyone does
with volume sizes "out there in the 'real world.'"
So...what should we do here?
a) We might blanket increase the free space for every data set. (In
this case, by how much should we increase it?) This one has the
benefit of being easier than the others, I suspect.
b) We might add a "recommended space" value and make it possible to
reduce space from "recommended" to "minimum." (What should
"recommended" be?)
c) We might make SMP/E recover from space abends when possible.
(Enough space on the *same volume* would likely be a requirement. A
potential for even more severe foot damage following careless use of
SMP/E on a running instance of software might well ensue.)
d) We might add a "Super Size Me!" option to the z/OSMF Software
Management software instance cloning function.
e) We might do something else...what?
Bear in mind that, as always, this is a zero-sum game. So if we give
you any of these things we will might well have to defer something
else in this same area.
Vote early and often...as usual, no promises, except that I'll at
least listen.
R.S. wrote:
W dniu 2014-04-28 20:47, Mark Pace pisze:
I don't understand why library sizes on a fresh install of z/OS never
seem
to account for doing maintenance. <snip>
100% agreed.
<snip>
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: [email protected]
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
