Hear, hear!
Regards Thomas Berg ____________________________________________________________________ Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ) > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Farley, Peter x23353 > Sent: Monday, June 10, 2013 5:38 PM > To: [email protected] > Subject: Storage paradigm [was: RE: Data volumes] > > <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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
