Jesse 1 Robinson wrote: >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?
Good one. +1 for you. For me: c all 'B37' 'ICH408I' ;-) >Gil may have been right about this being the October popic. 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. Agreed. This is why there is the ability to do 'rolling maintenance'. You leave out live things out and setup new IPL/other volsers with bigger than big datasets. Of course, can you do that or not. YMMV. >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. Those 'manage-by-airline-rag' execs also are extrememely offended (because of no brain cells) by this: 1. No applying fixes on 'live' things. 2. Downtime and approvals and double check-outs/verifications are needed. 3. z/OS does not need 'three finger salute' (CTRL-ALT-DEL for reboot). 4. Nothing to click on. no GUI. (yes, I know about the new products with GUI interfaces, but ... ) 5. ... etc ... >... 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. This is why you see in Program Directories the required space for each dataset/OMVS files needed for each product you ordered. >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. We discourage updates of live modules, but 'they' won't listen. Only when something crash, then 'they' rememeber... :-( >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. You're a true risk taker! ;-D Seymour J Metz wrote: >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. Good. Unless you are in a catch-22 situation, but I believe you also *prefer* not to be there. ;-) This thread is a very interesting one. Thanks! Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
