My concern is for Linklist's problem with secondaries. Thus, please enhance link list to handle secondaries or allow for compression.
Othewise, enhance serverpak to have: -- An option for Zero secondary for load libs -- Option to alloc a PDS/E where appropriate Ken Smith State of Maryland On Mon, Apr 28, 2014 at 3:58 PM, John Eells <[email protected]> wrote: > 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
