Maybe, somewhere in the middle, IEBCOPY is relocated... > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Mark Zelden > Sent: Friday, September 23, 2022 2:32 PM > To: [email protected] > Subject: Re: z/OSMF PSWI > > [EXTERNAL EMAIL] > > 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: > https://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!J > mPEgBY0HMszNaDT!o5Z075cMrDIbOCIYk0ebADpYeQRA1NUQq2ZoKoVpOvr > xa6AUxjn7-X9smRfTE32YEX1-waVjw7Uy$ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
