Region size requirements for DEDB Unload

The DEDB Unload utility operates in a virtual storage region as z/OS® batch job steps. FABCUR1 and FABCUR1U run in 31-bit addressing mode.

Region size for the unload program depends on the number of unload subtasks, the size of a UOW, the number of IOVF buffers allocated, the number of output files, and the TASKCTL specifications.

Typically, database maintenance is a relatively important function. To increase the performance of the unload program, it would be advisable to run it in a region that has a relatively high dispatching priority (that is, at least equal to the dispatching priority of a message processing region).

Estimating the region size for unload

The region size required for the unload processor (FABCUR1) is a function of the number of areas being unloaded, the number of output files, and of the TASKCTL specifications used.

In most cases, the specification on the EXEC statement for FABCUR1 of a region that is too small, is detected during the main task's initialization processing. This causes processing to be terminated at that point. Under certain conditions, the region-size shortfall does not become evident until the actual unload has begun. If this occurs, one or more unload subtasks are quiesced in an attempt to free up sufficient storage to complete the requested processing. Should this fail, the main task ends with an abend code. There is no option to restart unload processing. The job must be completely rerun. Thus, the region-size calculations should always be performed prior to initiating unload processing.

The following worksheet is for estimating the region size that is required for a typical unload job. The actual region size depends on the keywords that are specified for the job. Therefore, when you specify the region size in your JCL, use a higher value than the value calculated from this worksheet.

Figure 1. Worksheet for estimating the region size for Unload
Unload programs, internal tables, control blocks         260,000
Number of unloaded areas * nnn                          -------- (nnn=800 if ACCESS=VSAM, nnn=950 if ACCESS=FAST)
Number of areas defined in input DBD * 160              --------
Number of areas defined in output DBD * nnn             -------- (nnn=700 if reorganization mode, nnn=780 if restructure mode)
Number of output files * (1200 + BLKSIZE * BUFNO)       --------  
     Internal tables, control blocks             53,000
     Iovfbufs * max CISZ in old DBD             -------
     max CISZ * (max CIs per track * 2 + 1)     -------
     aa * UOW1+ bb * iovfbufs                   -------          (aa=12,bb=24 if ACCESS=VSAM, aa=60,bb=72 if ACCESS=FAST) 
     max CISZ * UOW1                            -------

                                  Subtotal      -------
Number of unload subtasks X Subtotal                    --------

             Total bytes of unload storage              --------

Reducing region size constraints

The unload program (FABCUR1) is implemented using various techniques aimed at extracting the segment data from DEDB areas in the shortest possible time. The trade-off is increased storage requirements. As seen in the examples, the region-size requirements for FABCUR1 can easily become very large. The following list shows a series of actions that may be taken to reduce the region-size requirements for a given unload request. They are listed in increasing order of impact on the performance of FABCUR1.

  1. Reduce the number of the unload subtasks specified on the TASKCTL control statement.
    • This eliminates the storage required for the BASE/DOVF buffer area and a set of IOVF buffers for each of the unload subtasks removed.
    • It also reduces the amount of storage allocated at a given time by VSAM for the sequential ACBs used to access the BASE and DOVF CIs in the areas being unloaded.
  2. If the maximum block size for the output file devices is large, specify the DCB=BLKSIZE=nnnnn parameter in the DD statement. Typically, reduce the block size to 15 - 20 K (depending on the number of output files being produced).
    • This reduces the storage required for the QSAM buffers for each of the files.
  3. Reduce the number of the output files.
    • This eliminates the storage required for the QSAM buffers for each of the removed files.
    • It also might introduce the requirement to sort the output files prior to reload processing.
  4. Reduce, within reason, the value of the TASKCTL iovfbufs parameter below the level of the maximum number of IOVF CIs used by a UOW being unloaded.
    • This reduces the storage required for the set of IOVF buffers allocated to each unload subtask.
    • It results in extra I/O for some UOWs, as the IOVF buffer sets do not contain all the CIs required to unload the UOWs with IOVF utilization greater than the specified value. FABCUR1 may be required to "steal" buffers and subsequently reread some IOVF CIs.
  5. Specify a value for the TASKCTL bdbufsz parameter. If the UOW1 value for the database being processed is large, this is almost certainly required. The value is typically calculated as (UOW2 + ((UOW1 - UOW2) / 4)) X CISIZE, to a maximum of 250-300K. (Larger values may be specified, if the number of unload subtasks being used is very small.)
    • This reduces the storage required for the BASE/DOVF buffer area allocated to each unload subtask.
    • It results in increased elapsed processing time as the BASE portion of each UOW must be processed in several "pieces."
  6. Specify an AMP=('BUFND=...') override on the DD statements for the areas being unloaded to reduce the number of buffers below the "2 X CIs-per-Track + 1" value. This should be considered only as a last resort. FABCUR1 automatically calculates an optimum value for this parameter when Opening the VSAM Sequential ACBs. The value calculated by FABCUR1 is designed to maximize the number of CIs read per EXCP. A JCL override takes precedence over the calculated value and can have a drastic effect on the number of EXCPs issued to extract the segment data in the areas being unloaded.
    • This reduces the storage required for the buffers acquired by VSAM.
    • It results in increased elapsed processing time as the EXCP count increases, and more channel contention and I/O wait time incurs.