1. Defrag should not release space when secondary space is 0. 2. I vote for 20% free space when secondary space is 0. 3. I vote for 20% of primary as secondary space.
On Mon, Apr 28, 2014 at 2: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 -- 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
