I don't apply to live system, I do make a copy of my RES volume, now volumes with increase in size of the 2.1 system. But the way I was taught was to make a .NEW library when one filled up. A pain in the butt, but (no pun intended) it is what I was taught. I was unaware of a PDS tool.
The 5 problem datasets, at least this time. CSF.SCSFMOD0 SYS1.SHASMIG SYS1.SERBLINK - This is at the top of my documentation to enlarge during install ISF.SISFLOAD ASM.SASMMOD1 On Mon, Apr 28, 2014 at 4:43 PM, Ed Gould <[email protected]> wrote: > Dave, > sigh you are forgetting about the people that apply maintenance to a live > running system (UGH). > > Ed > > > On Apr 28, 2014, at 3:28 PM, Gibney, Dave wrote: > > Since I copy (and you should) my SMP/E Targets to an operational RESVOL, >> so what if some APPLY stuff fails the first time. The PDS tool from CBT >> makes it easy to add more space where it is needed and re-run the APPLY. >> >> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] >>> On Behalf Of John Eells >>> Sent: Monday, April 28, 2014 12:58 PM >>> To: [email protected] >>> Subject: Re: New install library size >>> >>> One or two people at the past SHARE voiced this very same opinion. >>> Let's say, for the sake of argument, that that's four so far. How do >>> others feel >>> about this? >>> >>> First, some background: As I recall, the current design of the ServerPac >>> dialog >>> does not allow space to be reduced below the default shipped values, >>> which >>> with a few exceptions include a fixed percentage of free space. There >>> are >>> sound reasons, in my opinion, to NOT allow those values to be reduced >>> from >>> what is shipped today. >>> >>> Historically, those values have been minimized to help prevent the >>> allocation >>> of additional disk volumes when orders for, say, z/OS and other products >>> included in z/OS orders don't happen to occupy space that's comfortably >>> far >>> away from typical volume boundaries. Editing the ALLOCDS job to reduce >>> allocations and fit within a given number of volumes is painful. >>> Running out >>> of space during service APPLY processing is painful. Allocating >>> additional >>> volumes is painful. >>> >>> On the other hand disk volumes are, by and large, probably rather larger >>> these days. But we've no direct view of what everyone does with volume >>> sizes >>> "out there in the 'real world.'" >>> >>> So...what should we do here? >>> >>> a) We might blanket increase the free space for every data set. (In >>> this case, >>> by how much should we increase it?) This one has the benefit of being >>> easier >>> than the others, I suspect. >>> b) We might add a "recommended space" value and make it possible to >>> reduce space from "recommended" to "minimum." (What should >>> "recommended" be?) >>> c) We might make SMP/E recover from space abends when possible. (Enough >>> space on the *same volume* would likely be a requirement. A potential >>> for >>> even more severe foot damage following careless use of SMP/E on a running >>> instance of software might well ensue.) >>> d) We might add a "Super Size Me!" option to the z/OSMF Software >>> Management software instance cloning function. >>> e) We might do something else...what? >>> >>> Bear in mind that, as always, this is a zero-sum game. So if we give >>> you any >>> of these things we will might well have to defer something else in this >>> same >>> area. >>> >>> Vote early and often...as usual, no promises, except that I'll at least >>> listen. >>> >>> R.S. wrote: >>> >>>> W dniu 2014-04-28 20:47, Mark Pace pisze: >>>> >>>>> I don't understand why library sizes on a fresh install of z/OS never >>>>> seem to account for doing maintenance. <snip> >>>>> >>>> 100% agreed. >>>> >>> <snip> >>> -- >>> John Eells >>> z/OS Technical Marketing >>> IBM Poughkeepsie >>> [email protected] >>> >>> ---------------------------------------------------------------------- >>> 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 >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
