There is no need to be so afraid of runaway disk space consumption, when we don't control similar problems that precisely in other areas: spoolspace utilization, job execution time (/*JOBPARM T=), GBs written to tape, etc. etc. In those areas, the control is to let people do their thing without prior specification of prediction and only take action if certain limits are exceeded.
Why not tread Dasd the same: let people specify Dataclass and skip SPACE (we can now already) and set limits on the size of the dataset per Dataclass. Like JES: Warn or abend the job if the size is exceeded, control who can use different Dataclasses etc. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Monday, June 10, 2013 19:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage paradigm [was: RE: Data volumes] On 6/10/2013 11:38 AM, Farley, Peter x23353 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. If it's that predictable, it's trivial to write code to produce an estimated output volume from input, and tailor and submit the appropriate JCL. So that's a non-issue. > 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> There is no theoretical solution. On any system running jobs, it is possible for one job to monopolize available space, requiring other jobs to wait forever or be terminated. Even on a single job system that job may exhaust space. Requiring a space specification may be a PITA, but it guarantees that a started job will finish (subject to other constraints). And the SA experts, especially for sequential files, can be avoided with simple estimator programs. This seems to be more of a religious war than a practical discussion. Gerhard Postpischil Bradford, Vermont ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
