I personally would prefer the shipped size to be exactly what the dataset needs (maybe on cylinder boundaries) including directory allocation. Or maybe a documented % over allocated (maybe 5-10%) that is the same across the board. I can easily globally add x% to both fields or better yet give me a ServerPac variable for primary, secondary, directory % increase (separate variables for target and dlib please).
Not really a big deal for me at this point because I have it in my procedures to globally add x% to my target libs, dlibs I leave alone as shipped. Although larger volumes are/have been available I'm pretty much stuck with 3390-9 (and -3 in some cases). Whatever you do please make sure we know about the change before we try to install. CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | [email protected] This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -----Original Message----- John Eells Sent: Monday, April 28, 2014 3:58 PM 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
