As to the "religious" aspect, I did try to signal the less-than-practical nature of my note with the <Rant> and </Rant> tags.
To your point about tailoring and dynamically submitting JCL, it really is an issue. In a typical large z/OS shop today, dynamically tailoring and submitting JCL is only permitted for test environments and users. "Production" JCL is frozen and controlled and submitted only by the scheduler software, and there is no political possibility to dynamically adjust the parameters even if it is technically feasible. There *are* non-theoretical solutions to "runaway" file output. The *ix system model of using "disk quotas" per "user" makes it entirely possible to imagine z/OS "application" users with "reasonable" disk quotas specific to the application (i.e., not by job but by suite of jobs). Not the best solution? Maybe not, but ISTM to be better than having to predict what each and every process (i.e., job and file) output volume will be. And there may well be other process models out there different from anything I know or imagine. I don't claim to have an exclusive lock on ideas to replace what we have to deal with. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Gerhard Postpischil Sent: Monday, June 10, 2013 1:32 PM To: [email protected] 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 -- 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
