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

Reply via email to