My DEFAULT DATACLAS specifies a SPACE allocation, fairly large with RLSE. This, plus space constraint relief, and also EXT as the DEFAULT has eliminated almost all x37 abends here. I also still run FDR COMPAK, fairly aggressive DFHSM migration to ML2 VTL, and a good sized overflow pool.
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Sean Gleann > Sent: Tuesday, March 05, 2019 3:37 AM > To: [email protected] > Subject: Re: Disk space allocation question [EXTERNAL] > > *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 <[email protected]> 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 < > > [email protected]> 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:[email protected]] > >> On > >> > Behalf Of Feller, Paul > >> > Sent: 04 March, 2019 16:40 > >> > To: [email protected] > >> > 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:[email protected]] > >> On > >> > Behalf Of Elardus Engelbrecht > >> > Sent: Monday, March 04, 2019 6:33 AM > >> > To: [email protected] > >> > 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 [email protected] 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 [email protected] with the message: INFO > >> > IBM-MAIN > >> ******************************************************** > >> For information, services and offers, please visit our web site: > >> https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.klm.com&d=DwI > >> FaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb- > Je7sw&r=u9g8rUevBoyCPAdo5 > >> > sWE9w&m=49tBKqt3DtO5KERZ5KGRq3NPLbm_Fiu1pFgEh7Xu0gw&s=LmQLIB > IdIE9lAxq > >> frpOrkAXMYXx48hjRXZsfxc0324Q&e=. 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 [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
