Create SYS1.IEBCOPY(IEBCOPY)? On Fri, Sep 23, 2022 at 8:28 PM Gibney, Dave <[email protected]> wrote: > > 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
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
