*sigh* I sometime wonder why I spend so much time making sure that text positioning, justification, etc is 'just right', only to see all that work thrown away. I hope those that read my previous response can make sense of it...
Sean On Tue, 5 Mar 2019 at 11:32, Sean Gleann <sean.gle...@gmail.com> wrote: > Thanks to all who have responded on this. I've been having 'fun' > experimenting with allocating files of various sizes on a badly fragmented > disk volume and at least I now understand why an 'I' command against a file > shown in an ISPF 3.4 list occasionally shows such surprising values. > > I don't appear to be able to make ALLOCxx settings (such as PRIM_ORG or > RLSE) affect matters at all. I played around with various settings, but all > to no avail, but then I spotted Paul's response where he says "...ALLOC > should not step in if you have SPACE coded in your JCL...". So I removed > the SPACE clause in my DD statement... and the job failed with a JCL error > and messages: > IEF344I jobname REQ911 REQ911 - ALLOCATION FAILED DUE TO DATA FACILITY > SYSTEM ERROR > IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET > The IGD... message means that "...No space was specified on the JCL or in > the data class for the allocation of the data set..." which is precisely > the situation. My JCL did not feature a SPACE clause, and my SMS dataclass > rule for the file in question has 'override space' set to 'N', and no > 'Space' values defined. I had expected ALLOC values to be used, but that > did not happen. > > I'm not sure where to go from here. I cannot claim to be proficient with > SMS at all, so I don't really want to risk upsetting a system to works > (most of the time!) > > Regards > Sean > > > On Mon, 4 Mar 2019 at 15:50, Vernooij, Kees (ITOP NM) - KLM < > kees.verno...@klm.com> wrote: > >> There are ACS options: >> ACS routines can assign a Dataclass with Space Atributes plus the option >> that it will override space in JCL, even for non-SMS managed datasets. >> For SMS managed datasets, the DataClass' Space Constraint Relief options >> can adjust space allocations. >> >> Kees >> >> >> > -----Original Message----- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On >> > Behalf Of Feller, Paul >> > Sent: 04 March, 2019 16:40 >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: Disk space allocation question [EXTERNAL] >> > >> > It is my understanding that the ALLOC should not step if you have SPACE >> > coded in your JCL. By default you should get your space request, though >> > it might be in more than one extent (up to 5). Now if you have some 3rd >> > party software installed it might be stepping in to prevent the initial >> > X37 abend on allocation. I don't recall if you could code something in >> > the ACS routines to step in to adjust the primary allocation. >> > >> > Thanks.. >> > >> > Paul Feller >> > AGT Mainframe Technical Support >> > >> > -----Original Message----- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On >> > Behalf Of Elardus Engelbrecht >> > Sent: Monday, March 04, 2019 6:33 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: Disk space allocation question [EXTERNAL] >> > >> > Sean Gleann wrote: >> > >> > >Does z/OS / SMS have a set of default space allocation sizes and if so, >> > where are they held and can I alter or control them? >> > >> > Look in ALLOCxx as kindly suggested by Roger Lowe. >> > >> > If you know what SMS routines were used, look at their definitions. >> > >> > >> > >I have a situation where insufficient contiguous disk space results in >> > the SPACE request parameters supplied for a DISP=(NEW...) file with >> > values that are too low to fulfil the final requirements. >> > >Example: I request SPACE=(TRK,(9000,1000)… and what I get is >> > ...TRK,(7200,500), which eventually leads to a B37 abend. >> > >> > Please post that full B37 abend message. There may be another reason why >> > you are not getting what you want. >> > >> > What about trying to use more than one volser for your allocation >> > attempts? >> > >> > >> > >It's that 'eventually' bit that is most disheartening. I would far >> > rather have the space request completely refused along with a job abend >> > rather than have the system 'try to help' me. >> > >> > Buy more disks... ;-) >> > >> > Pre-allocations may help before you actually use it, but of course, how >> > do you know what size is 'correct'? >> > >> > Groete / Greetings >> > Elardus Engelbrecht >> > >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >> > ---------------------------------------------------------------------- >> > Please note: This message originated outside your organization. Please >> > use caution when opening links or attachments. >> > >> > ---------------------------------------------------------------------- >> > 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 >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
