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: [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Joel C. Ewing Sent: Friday, 8 March 2019 02:23 To: [email protected] 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 +0000, 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 [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
