In general, I agree. But I will say that I need something to limit run-away usage of disk space. Why? Because we have had programmers who didn't want to be bother either. So they put out a "report" to SPOOL. And then their program went into a loop; writing the same message over and over. This exhausted the SPOOL space. Which caused a production outage on a weekend (we run "dark" on the weekends). I can easily envision the same thing happening if DASD ever went to an "all you can eat". Of course, with SMS control, it is easier to segregate the data into pools. We currently try to do a type of "all you can reasonably eat" by having our data classes have a dynamic volume count of 59. And we have a semi-standard (read: recommendation) that files of an "unknown size" be allocated CYL,(500,100) . Oh, and we use space release in the data class to get rid of excess allocation. If the data set cannot abide space release for some reason, there is an exempt data class for the programmers to use.
On Mon, Jun 10, 2013 at 10:38 AM, Farley, Peter x23353 < [email protected]> wrote: > <Rant> > Like a few others on this list, I have often gritted my teeth at the > necessity to estimate disk storage quantities that vary widely over time in > a fixed manner (i.e., SPACE in JCL) when the true need is just to match > output volume to input volume each day. > > Why is it that IBM (and organizations that use their mainframe systems) so > vigorously resist a conversion off of the ECKD "standard"? (Yes, I know > it's all about "conversion cost", but in the larger picture that is a red > herring.) Not that I'm likely to see such a transition in my lifetime, but > in this dawning time of soi-disant "big data", perhaps it is past time to > change the storage paradigm entirely, not from ECKD to FBA but to > transition instead to something like the Multics model where every object > in the system (whether in memory or on external storage, whether data or > program) has an address, and all addresses are unique. Let the storage > subsystem decide how to optimally position and aggregate the various parts > of objects, and how to organize them for best performance. Such decisions > should not require human guesstimate input to be optimal, or nearly so. > Characteristics of application access are far more critical specifications > than mere size. The ability to specify just the desired application access > characteristics (random, sequential, growing, shrinking, > response-time-critical, etc.) should be necessary and sufficient. > > EAV or not EAV, guaranteed space or not, candidate volumes, striped or not > striped, compressed or not compressed - all of that baggage is clearly > non-optimal for getting the job done in a timely manner. Why should > allocating a simple sequential file require a team of "Storage > Administration" experts to accomplish effectively? > </Rant> > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Ed Jaffe > Sent: Sunday, June 09, 2013 10:47 AM > To: [email protected] > Subject: Re: Data volumes > > On 6/9/2013 7:12 AM, Scott Ford wrote: > > We need bigger dasd ...ouch > > The largest 3390 volumes in our tiny shop hold 3,940,020 tracks or 262,668 > cylinders. That is the maximum size supported by the back-level DASD we are > running. Newer DASD hardware can support volumes up to 1TB in size. I > assume nearly all zEC12 and z196 customers are capable of exploiting these > large sizes. But, do they? > > I spent three years dealing with, and eventually helping IBM to solve (via > OA40210 - HIPER, DATALOSS), a serious EAV bug that should have been seen in > most every shop in the world that uses the DFSMSdss CONSOLIDATE function > (with or without DEFRAG). The experience was a real eye-opener for me and I > concluded that almost nobody is using EAV! > > Why not? Personally, I would find it embarrassing if the Corsair thumb > drive in my pocket held more data than our largest mainframe volumes. > But, that's just me... > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
