On Fri, 23 Sep 2022 07:33:37 -0500, Carmen Vitullo <[email protected]> wrote:
>yes I read it, and that would be great if every single client, every
>single site had the same wisdom as you, I've worked at sites where I was
>not the lead z/os or mvs guy, I had no control over what anyone else
>did, and we all paid the consequences updating a live system, acceptable
>or not, I change the allocation to not allocate secondary space period.
A point I was trying to convey was that secondary space or not if you update
the live system without knowing what you are doing you're going to have
unexpected results. Instead of the secondary (which can happen)
you would have just run into an x37 instead and maybe half your
change was copied in (assuming it was more than one LMOD). Or
maybe one of those less experienced people doesn't know to do an
LLA update or refresh. Or maybe they forget the sysres is shares
on other systems and forget to do the LLA update or refresh there. Maybe
the maintenance process is done from a system outside the sysplex and
they break a PDSE (all things I have run into at shops I've consulted
at).
So to me, I really don't care about the secondary for some libraries
because no matter what if someone needs to update the live sysres
for an emergency, there is more than just "what happens if this library
takes an additional extent" consideration. In your scenario of "no
control of what anyone else does" they can break the system just
as easily regardless of no secondary defined in any number of ways.
That is my point.
BTW, if a secondary is taken, a compress will put everything back into the
first extent (assuming this is being done as a "fix" and not really adding
additional modules / some individual module that is much bigger) and doing
an LLA UPDATE of the library will fix it all after the compress. An
LLA update of the modules or library has to be done anyway.
In an emergency, the better way to do it would be to have the 'fix' in a
separate library anyway and do a dynamic LNKLST update with the
new library concatenated ahead of the original.
>
>my main issue was how the space was defined initially using the
>serverpac dialog, been burnt a couple times during the SP install, so I
>update the space requirements then.
>
Again, the history of that I think was to facilitate applying maintenance and
maybe
to help accommodate poor "JCL" / allocations in Serverpac also. But as you
indicated, at least there was a way to update it at install time if that is
what you wanted to do.
>that is for MY site, and my MY way of installing and maintaining a
>site IMHO I've seen it done wrong, and things gone bad, and seen it
>done a way that's safe and makes sense, that methodology I adopt.
>
Exactly. But not everyone does it the same or has the same considerations,
so IBM made it a choice. I don't consider it "wrong", it is an option that
I happen to like to facilitate maintenance. Maybe the better ServerPac default
would have been no secondary to begin with. Can't please everyone though...
This reminds me... back in the older days (pre DFSMS/MVS 1.3) at
a shop I was at we ran a post clone process with FDRCPK to combine
extents to avoid the LNKLST limitations. Still had the secondaries
though to facilitate maintenance. I wrote an exec (LNKVER) still on my
web site to help manage it.. The doc has the old rules:
(32) + (16n) + (k-1)
n = the number of DASD extents (PDSE counts as 1)
k = the number of data set in the link list
The result of the algorithm cannot exceed 2040.
Best Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:[email protected]
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
