I am not a LUW person, other than I use a windows machine for simple things, so I am curious how external storage is allocated and controlled in that environment. I think we have all heard the complaints about the short-comings of MVS in this area, but what would be a realistic solution?
I would imagine the people at IBM have spent a little time on this, and if it was easy would have started transitioning us from ECKD to 'the new way' a long time ago. The idea of a 'run-away' program is what is the hang-up. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, June 10, 2013 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Sunday, June 09, 2013 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
