A couple of things, that could be applicable: ALLOCxx does nothing for JCL.
ISPF "I" command shows the final situation, after a lot of interventions might have happened to your original JCL Space request: - the primary space reported by ISPF is the space of the current first extent. This might have few or no relation to your original primary space request. - the secondary space reported by ISPF is what is really is now, apparently someone/thing changed your original secondary space request. - the Dataclass can overrule your requested space, apparently not in your case. - Primary space may be acquired in up to 5 extents. The first of these 5 is reported by ISPF as the 'primary space'. - DADSM does 'extent consolidation': if 2 extents of a file are adjacent, they are combined to 1 extent. If this is the new first extent, it will again be reported by ISPF as the 'primary space'. - Space Constraint Relief can change your primary space, your secondary space and the above mentioned 5 extents for primary space. You say now " My JCL did not feature a SPACE clause " but before you said I request SPACE=(TRK,(9000,1000)… and what I get is ...TRK,(7200,500)," Can you redescribe your problem, as asked before with JCL and the full B37 abend. Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sean Gleann > Sent: 05 March, 2019 12:32 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Disk space allocation question [EXTERNAL] > > 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- > m...@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- > m...@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 ******************************************************** 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
