My thought on this is that every shop has felt this problem and how to take care of it, well that defiantly not an easy answer. I think a factor that you did not explicitly state, but should be considered is the question, should the data set be allowed to go into extents or not (secondary = 0), it is kind of implied, but in looking at solutions, I think that should be a factor, not as much as it used to be, but still something to consider.
A thought I have would be to gather a few statistics on how often has a particular data set had a fix applied to it, SYS1.LINKLIB is an obvious HIGH score. Maybe a factor can be generated for each data set and using that factor adjustments could be made. Looking at your items and here is my $0.02: a) Increase free space...? You are correct it is the easiest, but do you do it by "n%" or "n tracks(Cyl)?" b) Recommended space? You are correct in asking, what should the "Recommended" space be and again that is a data set, by data set type of answer. A second option these days could be, what is the size of your "SYSRES" volumes and how many? Are you attempting to keep to "n" number of Mod 3's, Mod 9's or Mod 27's .... Here is where you could have a program take as input the number of volumes and the data sets and then figure out where to put them, kind of like doing a "Jigsaw Puzzle". c) We might make SMP/E recover from space abends..? Oh, I do not remember the IBM product name, I think it is in the Tivoli suite of products that automatically handles "x37 ABENDS." d) We might add a "Super Size Me!"... See the later part of "b)" previous, tell it how many volumes and size and it figures out where to put the data sets and expand the size to "Fill in the gaps!" e) ... not sure I have an idea for this one. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Eells Sent: Monday, April 28, 2014 3: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
