Whether 'tis nobler in the mind to suffer The slings and arrows of secondary extents, Or to take arms against a sea of B37s, And by opposing end them?
Gil may have been right about this being the October Topic. For ServerPac data sets, I encourage the *judicious* use of secondary extents. That's largely because we (OK, almost) never update live data sets. We install maintenance in a service-only container--oh snaps, I just made that up--and migrate it to a live environment with an IPL. A swollen data set can be inconspicuously compressed before it's (re)introduced to the wild. OTOH dealing with a data set that has incrementally outgrown its original primary-only allocation can be a major PITA even in a service-only container. The catch is that You Need to Know What You're Doing. I know, this requirement offends manage-by-airline-rag execs who see knowledge and experience as obstacles to hiring practices. So be it. So why not, as someone suggested, just make every data set Godzilla-size so that you never run out of space? Back when MVS releases showed up every six months, usage growth from one release to the next could somewhat be anticipated. But we all have to live with finite sysres volume(s), and after a couple of years' worth of new function before the next ServerPac, anticipating the long-term growth of every library is pretty much a crapshoot. Defining secondary extents that may or may not be needed in the current release is a fairly cheap maneuver to head off an inconvenient space crunch. As we all agree, install fixes on live systems infrequently and with great care, but IBM has invested tons in mechanisms that make continuous availability possible if not trivial. Just come clean that it's this or guaranteed IPL. I've made a handful of gambles over the years. Won more than I've lost, but each one is a cliff hanger. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Seymour J Metz Sent: Wednesday, October 03, 2018 1:06 PM To: [email protected] Subject: (External):Re: S106 abends after copying into LINKLIST I stated that I *prefer* to never update I live linklist library, not that I wouldn't or haven't done it in an emergency situation. What I do to avoid an outage is not what is sound for routine maintenance. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Ed Jaffe <[email protected]> Sent: Tuesday, October 2, 2018 7:06 PM To: [email protected] Subject: Re: S106 abends after copying into LINKLIST On 10/2/2018 8:43 AM, Seymour J Metz wrote: > I prefer to avoid the problem by never updating a live linklist library. NEVER is a strong word. Too strong for the dynamic modern world, IMHO. If there is some sort of *major* error that needs fixing NOW, then we will receive the fix and -- if it has no IPL hold -- stop LLA, apply the fix, bring LLA back up, and perform any documented DYNACT restart. Problem solved. No downtime whatsoever... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
