It might be worth pointing out what might be a little known fact. Any allocation, primary or secondary, can be done in up to 5 extents. That means that, on a highly fragmented pack, SPACE=(CYL,(5,5)) might only get 16 cylinders (in 16 extents) before running out of extends. Fragmentation at this level is unusual on modern systems, but I wouldn't assume that all allocations were in single extents. If you have significant fragmentation, perhaps because work packs are not managed like other packs, you may be dealing with a different problem then you think.
If you think specifying FILSZ might help, have you considered adding a REXX EXEC that issues a CALL LISTDSI or a SQL SELECT COUNT(*) ... and that calculates a crude estimate of space from that information. The result could then be passed to the COBOL program, either as a parm or in a VIO dataset, and the COBOL program could pass that to sort. Have you tried it and are getting some kind of negative result, or are you just in the planning stage? OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Wed, Jul 4, 2018 at 3:36 PM, Peter Hunkeler <p...@gmx.ch> wrote: > Some background, first. > > I was asked to help a COBOL application calling DFSORT internally via > INPUT / OUTPUT PRODECURE (E15/E35) interface. The input data size is > unknown, but varying greatly. FILESZ cannot be supplied. So, DFSORT has no > way to calculate the required disk work space. > > > The application was asked to change from JCL allocated SORTWKnn to > dynamically allocated sort work space. > > > DFSORT options DYNALLOC, DYNAPCT, and DYNSPC are the options used to help > DFSORT optimally allocate the sort work space. Some extracts from the > manual are listed below. > > > I read the relevant parts in the Installation & Customization, the > Application Programmer, and the Tuning Guide, but still I'm not sure I > understand how and when the work space data set are allocated. The disk > space allocated is of special interest here. > > > Suppose: DYNALLOC=(,8),DYNAPCT=50,DYNSPC=2400 > > > Now here are the statements with a lot of uncertainty, and question marks. > I'd appreciate confirmation, or correction where I'm wrong. > > > a) DFSORT will allocate 8 initial work data sets with primary space, and > 50% of that, i.e. 4 reserve data sets with zero space initially. The total > amount of primary space is the equivalent of 2400 MB. The manual says this > is the total over *all* work data sets. > > > > b) So, the primary space for each of the 12 work data sets is 200MB, but > only the 8 initial ones are allocated with that primary amount. The 4 > reserved data sets are initially allocated with 0 space, but 200 MB will be > allocated once DFSORT decides it needs them. > > > > > c) The secondary space is said to be 20% of the primary, i.e. 480MB. It is > not clear to me, whether this means any secondary extent is 480MB, or > whether the secondary value is 480MB / 12, i.e. 40MB. This greatly > influences the theoretical total amount of workspace. > > > > > d) When DFSORT decides it needs more space, will it extend one, some, or > all of the additional work data sets? At this time, the initial work data > set have probably been extended to their maximum size (1 x primary + 15 x > secondary). Will the additional data sets be extended by the primary amount > only, and will grow later as needed? > > > > > e) The first extension amount used with d) will be the primary amount > calculated above, i.e. 200MB, right? Later, these additional data sets can > be expanded by the secondary extent value, up to 15 times. Correct? > > > > > > Extracts from the Application Programmer's Guide: > > DYNAPCT=x > > specifies additional work data sets to be dynamically allocated with zero > space. DFSORT only extends these data sets when necessary to complete a > sort application. > > x specifies the number of additional work data sets (y) as a percentage of > the maximum number of dynamically allocated work data sets > (DYNALLOC/DYNALOC n value) in effect. > > DYNSPC=n > > DYNSPC=n temporarily overrides the DYNSPC installation option, which > specifies the total default primary space allocation for all of the > dynamically allocated work data sets when the input file size is unknown. > > ..., DFSORT uses the DYNSPC value in effect as the approximate amount of > primary space. DFSORT uses 20% of the primary space as secondary space. > Although the primary space is always allocated, secondary space (up to 15 > extents) is only allocated as needed. > > n specifies the total default primary space, in megabytes, to be allocated > for all dynamically allocated work data sets (n is not the primary space > for each data set). > > > -- > Peter Hunkeler > > ---------------------------------------------------------------------- > 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
