Re: Disk space allocation question [EXTERNAL]
If the DSORG supports multivolume, then add UNIT=(,5) to everything that opens the file for output. That does not mean the IEFBR14 that allocates it; you want the program that writes to it. You can do this with the DATACLAS as well, with or without using SCR, but with a large number of datasets you need to watch the TIOT. Ron Hawkins Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m: +61 400029610 | h: +61 387399252 | f: +1 4087912585 | email: ron.hawk...@ipsicsopt.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing Sent: Friday, 8 March 2019 02:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Disk space allocation question [EXTERNAL] On 3/6/19 10:32 AM, Paul Gilmartin wrote: > On Wed, 6 Mar 2019 08:36:23 +, Sean Gleann wrote: >> Up until reading the doc regarding ALLOCxx, I was unaware that >> "...Primary space may be acquired in up to 5 extents" and that was >> the root cause of the problem report that I was given. That doc and >> the further testing I've done has allowed me to understand the >> numbers seen in the resulting ISPF 'I' command output, and to >> communicate that information to the person who reported the 'problem' (I >> requested 9000 tracks! Why did I get only 7200? >> Why did my job go to a B37 after that??) >> > I have routinely done Info on one data set then changed the DSN and > Allocated, intending to create one very similar. I have been dismayed > when space is different from what I requested on the original data set. > > I consider this a bug. > > -- gil > > ... > Backward compatibility will always leave specifying allocation the old ways in units of tracks or cylinders problematic. If you actually care whether you get a specific amount of space, you need to be using newer SMS allocation techniques, specifying space using AVGREC and record size, using System-Determined Blocksize, specifying (in JCL or via SMS definitions) multi-volumes, and using extended datasets (which greatly increases allowed extents per volume and allows secondary allocations to also have multiple physical extents). It also helps with volume fragmentation issues if your SMS rules don't attempt to allocate huge datasets in the same SMS storage pools as smaller datasets. Yes the old allocation rules are a mess and in retrospect perhaps a bad design choice, but since IBM is supplying other ways to solve the allocation problem and reduce allocation dependency on physical DASD architecture, don't expect the old rules to change. Another major exposure the old allocation rules always had: While a 16 extent limit per volume implied there was always a possibility of adding 11 to 15 secondary extents, If DASD space was getting scarce and the primary allocation proved insufficient, there was never any guarantee of space for ANY secondary allocations being available for later allocation when the primary space limit was exceeded. Just dynamically adding DASD space from anywhere to files as needed as long as some job limit, step limit, or total storage limit wasn't exceeded would obviously be a much nicer solution today from a user standpoint (and has been used on other mainframe operating systems); but when the original DASD allocation schemes were created for OS/360, allowing explicit control to restrict the number of extents and encourage allocation of contiguous tracks and contiguous cylinders was considered essential for maximizing DASD performance. Joel C Ewing -- Joel C. Ewing -- 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
Re: Disk space allocation question [EXTERNAL]
On 3/6/19 10:32 AM, Paul Gilmartin wrote: > On Wed, 6 Mar 2019 08:36:23 +, Sean Gleann wrote: >> Up until reading the doc regarding ALLOCxx, I was unaware that "...Primary >> space may be acquired in up to 5 extents" and that was the root cause of >> the problem report that I was given. That doc and the further testing I've >> done has allowed me to understand the numbers seen in the resulting ISPF >> 'I' command output, and to communicate that information to the person who >> reported the 'problem' (I requested 9000 tracks! Why did I get only 7200? >> Why did my job go to a B37 after that??) >> > I have routinely done Info on one data set then changed the DSN and > Allocated, intending to create one very similar. I have been dismayed > when space is different from what I requested on the original data set. > > I consider this a bug. > > -- gil > > ... > Backward compatibility will always leave specifying allocation the old ways in units of tracks or cylinders problematic. If you actually care whether you get a specific amount of space, you need to be using newer SMS allocation techniques, specifying space using AVGREC and record size, using System-Determined Blocksize, specifying (in JCL or via SMS definitions) multi-volumes, and using extended datasets (which greatly increases allowed extents per volume and allows secondary allocations to also have multiple physical extents). It also helps with volume fragmentation issues if your SMS rules don't attempt to allocate huge datasets in the same SMS storage pools as smaller datasets. Yes the old allocation rules are a mess and in retrospect perhaps a bad design choice, but since IBM is supplying other ways to solve the allocation problem and reduce allocation dependency on physical DASD architecture, don't expect the old rules to change. Another major exposure the old allocation rules always had: While a 16 extent limit per volume implied there was always a possibility of adding 11 to 15 secondary extents, If DASD space was getting scarce and the primary allocation proved insufficient, there was never any guarantee of space for ANY secondary allocations being available for later allocation when the primary space limit was exceeded. Just dynamically adding DASD space from anywhere to files as needed as long as some job limit, step limit, or total storage limit wasn't exceeded would obviously be a much nicer solution today from a user standpoint (and has been used on other mainframe operating systems); but when the original DASD allocation schemes were created for OS/360, allowing explicit control to restrict the number of extents and encourage allocation of contiguous tracks and contiguous cylinders was considered essential for maximizing DASD performance. Joel C Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disk space allocation question [EXTERNAL]
On Wed, 6 Mar 2019 08:36:23 +, Sean Gleann wrote: > >Up until reading the doc regarding ALLOCxx, I was unaware that "...Primary >space may be acquired in up to 5 extents" and that was the root cause of >the problem report that I was given. That doc and the further testing I've >done has allowed me to understand the numbers seen in the resulting ISPF >'I' command output, and to communicate that information to the person who >reported the 'problem' (I requested 9000 tracks! Why did I get only 7200? >Why did my job go to a B37 after that??) > I have routinely done Info on one data set then changed the DSN and Allocated, intending to create one very similar. I have been dismayed when space is different from what I requested on the original data set. I consider this a bug. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disk space allocation question [EXTERNAL]
That 5 extent business has been around since Old Man Noach cornered the market in gopher wood, long before ALLOCxx came along. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Sean Gleann Sent: Wednesday, March 6, 2019 3:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disk space allocation question [EXTERNAL] Kees: Ok, so - as I've found out for myself - "ALLOCxx does nothing for JCL." If that is the case, then what is point of the various SPACE subparameters in ALLOCxx? If they are coded, where or when *do* they come in to play? I haven't seen anything in the Init guide that is specific on this point. Up until reading the doc regarding ALLOCxx, I was unaware that "...Primary space may be acquired in up to 5 extents" and that was the root cause of the problem report that I was given. That doc and the further testing I've done has allowed me to understand the numbers seen in the resulting ISPF 'I' command output, and to communicate that information to the person who reported the 'problem' (I requested 9000 tracks! Why did I get only 7200? Why did my job go to a B37 after that??) There's a bit of confusion regarding "My JCL did not feature a SPACE clause". The missing bit is that I'd commented out the SPACE clause *in that particular test*. I'd expected the ALLOC values to take effect, because there was nothing specified in SMS that could be used. As for re-describing the problem, now that I've managed to explain to the user how SPACE requests are fulfilled, the problem has been marked as 'solved' and I've been told to drop it. Thanks to you and all others who have responded on this, but the user now realises that they were reading the 'I' command output incorrectly. Regards Sean On Wed, 6 Mar 2019 at 07:23, Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote: > RLSE in the Dataclas? This is a Mgmtclas option. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gibney, Dave > > Sent: 05 March, 2019 23:19 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > 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 On > > > Behalf Of Sean Gleann > > > Sent: Tuesday, March 05, 2019 3:37 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 > > 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 '
Re: Disk space allocation question [EXTERNAL]
Sean, I still have not seen an explanation why the secondary space changed from the requested 1000 to 500. Kees. > -Original Message- > From: Vernooij, Kees (ITOP NM) - KLM > Sent: 06 March, 2019 9:43 > To: 'IBM Mainframe Discussion List' > Subject: RE: Disk space allocation question [EXTERNAL] > > Sean, > > ALLOCxx states its working environment: > "-SPACE- Specifies the installation defaults for some space allocation > parameters. These defaults apply to only dynamic allocation and VIO > requests." > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of Sean Gleann > > Sent: 06 March, 2019 9:36 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > Kees: > > Ok, so - as I've found out for myself - "ALLOCxx does nothing for > JCL." > > If > > that is the case, then what is point of the various SPACE > subparameters > > in > > ALLOCxx? If they are coded, where or when *do* they come in to play? I > > haven't seen anything in the Init guide that is specific on this > > point. > > > > Up until reading the doc regarding ALLOCxx, I was unaware that > > "...Primary > > space may be acquired in up to 5 extents" and that was the root cause > of > > the problem report that I was given. That doc and the further testing > > I've > > done has allowed me to understand the numbers seen in the resulting > ISPF > > 'I' command output, and to communicate that information to the person > > who > > reported the 'problem' (I requested 9000 tracks! Why did I get only > > 7200? > > Why did my job go to a B37 after that??) > > > > There's a bit of confusion regarding "My JCL did not feature a SPACE > > clause". The missing bit is that I'd commented out the SPACE clause > *in > > that particular test*. I'd expected the ALLOC values to take effect, > > because there was nothing specified in SMS that could be used. > > > > As for re-describing the problem, now that I've managed to explain to > > the > > user how SPACE requests are fulfilled, the problem has been marked as > > 'solved' and I've been told to drop it. > > > > Thanks to you and all others who have responded on this, but the user > > now > > realises that they were reading the 'I' command output incorrectly. > > > > Regards > > Sean > > > > > > On Wed, 6 Mar 2019 at 07:23, Vernooij, Kees (ITOP NM) - KLM < > > kees.verno...@klm.com> wrote: > > > > > RLSE in the Dataclas? This is a Mgmtclas option. > > > > > > Kees. > > > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List [mailto:IBM- > > m...@listserv.ua.edu] On > > > > Behalf Of Gibney, Dave > > > > Sent: 05 March, 2019 23:19 > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > > > > > 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 > On > > > > > Behalf Of Sean Gleann > > > > > Sent: Tuesday, March 05, 2019 3:37 AM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > 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 > > > > wrote: > > > > > > > > > > > Thanks to all who have responded on this. I've been having > 'fun' > > > > > > experimenting with allocating files of various sizes on a > ba
Re: Disk space allocation question [EXTERNAL]
Sean, ALLOCxx states its working environment: "-SPACE- Specifies the installation defaults for some space allocation parameters. These defaults apply to only dynamic allocation and VIO requests." Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sean Gleann > Sent: 06 March, 2019 9:36 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Disk space allocation question [EXTERNAL] > > Kees: > Ok, so - as I've found out for myself - "ALLOCxx does nothing for JCL." > If > that is the case, then what is point of the various SPACE subparameters > in > ALLOCxx? If they are coded, where or when *do* they come in to play? I > haven't seen anything in the Init guide that is specific on this > point. > > Up until reading the doc regarding ALLOCxx, I was unaware that > "...Primary > space may be acquired in up to 5 extents" and that was the root cause of > the problem report that I was given. That doc and the further testing > I've > done has allowed me to understand the numbers seen in the resulting ISPF > 'I' command output, and to communicate that information to the person > who > reported the 'problem' (I requested 9000 tracks! Why did I get only > 7200? > Why did my job go to a B37 after that??) > > There's a bit of confusion regarding "My JCL did not feature a SPACE > clause". The missing bit is that I'd commented out the SPACE clause *in > that particular test*. I'd expected the ALLOC values to take effect, > because there was nothing specified in SMS that could be used. > > As for re-describing the problem, now that I've managed to explain to > the > user how SPACE requests are fulfilled, the problem has been marked as > 'solved' and I've been told to drop it. > > Thanks to you and all others who have responded on this, but the user > now > realises that they were reading the 'I' command output incorrectly. > > Regards > Sean > > > On Wed, 6 Mar 2019 at 07:23, Vernooij, Kees (ITOP NM) - KLM < > kees.verno...@klm.com> wrote: > > > RLSE in the Dataclas? This is a Mgmtclas option. > > > > Kees. > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] On > > > Behalf Of Gibney, Dave > > > Sent: 05 March, 2019 23:19 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > > > 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 On > > > > Behalf Of Sean Gleann > > > > Sent: Tuesday, March 05, 2019 3:37 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > 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 > > > 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 er
Re: Disk space allocation question [EXTERNAL]
You are likely correct. I set this up many years ago now. All our application data is SMS. I probably do cover rlse with the most commonly used, default MGMTCLAS > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Tuesday, March 05, 2019 11:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Disk space allocation question [EXTERNAL] > > RLSE in the Dataclas? This is a Mgmtclas option. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Gibney, Dave > > Sent: 05 March, 2019 23:19 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > 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 > On > > > Behalf Of Sean Gleann > > > Sent: Tuesday, March 05, 2019 3:37 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 > > 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 > > > &
Re: Disk space allocation question [EXTERNAL]
Kees: Ok, so - as I've found out for myself - "ALLOCxx does nothing for JCL." If that is the case, then what is point of the various SPACE subparameters in ALLOCxx? If they are coded, where or when *do* they come in to play? I haven't seen anything in the Init guide that is specific on this point. Up until reading the doc regarding ALLOCxx, I was unaware that "...Primary space may be acquired in up to 5 extents" and that was the root cause of the problem report that I was given. That doc and the further testing I've done has allowed me to understand the numbers seen in the resulting ISPF 'I' command output, and to communicate that information to the person who reported the 'problem' (I requested 9000 tracks! Why did I get only 7200? Why did my job go to a B37 after that??) There's a bit of confusion regarding "My JCL did not feature a SPACE clause". The missing bit is that I'd commented out the SPACE clause *in that particular test*. I'd expected the ALLOC values to take effect, because there was nothing specified in SMS that could be used. As for re-describing the problem, now that I've managed to explain to the user how SPACE requests are fulfilled, the problem has been marked as 'solved' and I've been told to drop it. Thanks to you and all others who have responded on this, but the user now realises that they were reading the 'I' command output incorrectly. Regards Sean On Wed, 6 Mar 2019 at 07:23, Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote: > RLSE in the Dataclas? This is a Mgmtclas option. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gibney, Dave > > Sent: 05 March, 2019 23:19 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Disk space allocation question [EXTERNAL] > > > > 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 On > > > Behalf Of Sean Gleann > > > Sent: Tuesday, March 05, 2019 3:37 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 > > 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
Re: Disk space allocation question [EXTERNAL]
RLSE in the Dataclas? This is a Mgmtclas option. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: 05 March, 2019 23:19 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Disk space allocation question [EXTERNAL] > > 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 On > > Behalf Of Sean Gleann > > Sent: Tuesday, March 05, 2019 3:37 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 > 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 > > >> >
Re: Disk space allocation question [EXTERNAL]
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 On > Behalf Of Sean Gleann > Sent: Tuesday, March 05, 2019 3:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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 Low
Re: Disk space allocation question [EXTERNAL]
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
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 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
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-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. > >
Re: Disk space allocation question [EXTERNAL]
Check the Dataclass. Does it have SPACE CONSTRAINT specified? We have b37s on occasions, as the process reduces space to the point where the data set cannot allocate sufficient storage https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas200/handle05.htm#handle05 If you have SPACE=(...,RLSE) + Space Constraint Relief = SB37 randomly Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Vernooij, Kees (ITOP NM) - KLM > Sent: Monday, March 04, 2019 8:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Disk space allocation question [EXTERNAL] > > 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
Re: Disk space allocation question [EXTERNAL]
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
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
Re: Disk space allocation question
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
Re: Disk space allocation question
On Mon, 4 Mar 2019 11:19:19 +, 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? >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. >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. > >Regards >Sean > Have a look in the ALLOCxx member of PARMLIB . Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Disk space allocation question
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? 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. 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. Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
