<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
