System-managed storage

The Storage Management Subsystem (SMS) makes data set allocation very easy and efficient. Having SMS manage the temporary data sets can be a good first step in migrating to system-managed storage. However, the SMS automatic class selection (ACS) routines can unintentionally affect DFSORT data set allocations and job performance, so you might need to coordinate changes to the ACS routines with the site's storage administrator, as described here.

When any data set is allocated on an SMS system, the allocation request passes through the system's data class and storage class ACS routines. If the data set will be system-managed, the request also passes through the system's management class and storage group ACS routines. There is only one set of ACS routines per site, and they are very powerful. They can override DFSORT installation options, such as VIO=NO, and can even override requests for a certain data, storage, or management class, or a certain unit or volume.

It is important to use &maxsize rather than &size in the ACS routines for volume assignment decisions related to the size of DFSORT work data sets. &size only takes into account the primary allocation, whereas &maxsize takes into account both the primary and possible total secondary allocation. Thus, the use of &maxsize will allow for a more accurate decision on the assignment of unit, storage class, storage group, and so on.

As an example of how ACS routines can affect the performance of DFSORT applications, consider a storage class ACS routine that assigns all temporary data sets to the STANDARD storage class, as shown in Figure 1. The storage class is then used to assign the temporary data sets to a storage group. Because the routine does not differentiate between DFSORT temporary data sets and other temporary data sets, the storage group ACS routine cannot selectively prevent DFSORT temporary data sets from being assigned to VIO. Allocating temporary data sets to VIO works well in most cases, but might not be desirable for DFSORT temporary data sets, as explained in VIO for DFSORT data sets.

Figure 1. ACS Storage Class Routine. &DSTYPE is used to assign temporary data sets to the STANDARD storage class.

   
PROC 1 STORCLAS   
     ......   
     ......   
     SELECT   
        WHEN(&DSTYPE = 'TEMP')   
          SET &STORCLAS = 'STANDARD'   
     END   
     ......   
     ......   
END /* END OF PROC */

One way to avoid allocating DFSORT temporary data sets to VIO is to write the ACS storage class routine so it assigns all DFSORT temporary output and work data sets (for example, those with ddnames SORTOUT, SORTOFdd, SORTWKdd, and SORTDKdd) to a special NONVIO storage class. Using the &DD variable is the most efficient way to determine whether or not a data set is a DFSORT data set. Because you cannot use the &DD variable to check the ddname in the storage group ACS routine, you must check for DFSORT temporary data sets in the storage class ACS routine as shown in Figure 2.

Figure 2. Storage Class ACS Routine. &DSTYPE and &DD are used to assign storage class NONVIO for DFSORT temporary data sets. The ddnames of these temporary data sets should be reserved names.

   
PROC 1 STORCLAS   
   
/* DEFINE DFSORT TEMPORARY DATA SETS  */   
   
FILTLIST DFSORTDD INCLUDE(SORTWK*,SORTDK*,SORTOF*,'SORTOUT')   
     ......   
     ......   
/* ASSIGN 'NONVIO' STORAGE CLASS TO DFSORT TEMPORARY DATA SETS */   
/* AND 'STANDARD' TO ALL OTHER TEMPORARY DATA SETS                */   
   
     SELECT   
        WHEN(&DSTYPE = 'TEMP')   
          IF (&DD = &DFSORTDD)   
           THEN SET &STORCLAS = 'NONVIO'   
           ELSE SET &STORCLAS = 'STANDARD'   
        OTHERWISE SET &STORCLAS = '   
     END   
     ......   
     ......   
END /* END OF PROC */

The storage group ACS routine can then look for the SORT storage class, and assign the data sets to a non-VIO storage group, as shown in Figure 3. The site's storage administrator will need to create the special NONVIO storage class and alter the storage class and storage group ACS routines.

Figure 3. Storage Group ACS Routine. &DSTYPE and &STORCLAS¬=SORT are used to prevent VIO allocation for DFSORT temporary data sets. PRIME is a pool storage group used for most data sets.

   
PROC 1 STORGRP   
     ......   
     ......   
/* ASSIGN ALL TEMPORARY DATA SETS THAT ARE NOT DFSORT    */   
/* DATA SETS TO 'SGVIO'                                  */   
   
     SELECT   
        WHEN(&DSTYPE = 'TEMP' && &STORCLAS; ¬= 'SORT')   
          SET &STORGRP = 'SGVIO','PRIME'   
   
/* ASSIGN DFSORT TEMPORARY DATA SETS TO 'PRIME'          */   
   
        OTHERWISE SET &STORGRP = 'PRIME'   
     END   
     ......   
     ......   
END /* END OF PROC */

Be aware that the ddnames SORTOUT, SORTWKdd, and SORTDKdd can be changed to other names when a program calls DFSORT. If other DFSORT output and work data set ddnames are in common use at your site, you should also include them in the ACS routines. This scheme does not work for OUTFIL data sets specified with the FNAMES operand unless common ddnames are specified.

Note: Filtering on SORTIN in the ACS routines cannot prevent DFSORT temporary input data sets from being allocated to VIO. These data sets are allocated in preceding steps and passed to DFSORT. Thus, SORTIN is not the ddname used when these data sets are allocated.

If the only DFSORT temporary data sets are dynamically allocated work data sets, another way to avoid VIO allocation is to use a non-VIO generic device type for the installation option DYNALOC and the run-time option DYNALLOC. The storage group ACS routine could then be written to assign a pool storage group to data sets with that generic device type. Again, the site's storage administrator will need to establish a non-VIO generic device type and alter the storage group ACS routine.

Note: DFSORT's dynamic allocation uses a primary allocation of 0 and non-zero secondary extents. In this way, space is only used when the data set is extended. If the attempts to extend the data sets fail or the required space can still not be obtained, DFSORT may do one of two things:

delete and then reallocate a dynamically allocated work data set using a non-zero primary allocation to force selection of a volume with enough free space to satisfy the request or
retry the allocation using a device type matching the unit type of the original allocation (for example, 3390) in an effort to allocate the required space in a volume from another pool storage group. This behavior, though rare, should be taken into account when designing ACS routines that make assignments based solely on device type.

There might be other cases as well where the site's ACS routines unintentionally alter DFSORT performance or data set allocation. Be aware of this, and if you encounter problems, consult with your storage administrator to work out a joint solution.

Software that reduces disk space allocations should not be allowed to reduce DFSORT work data set space. DFSORT's dynamic allocation function calculates the optimal work space for each sort application, adjusts the allocated work space as needed, and terminates if the required space is not available. Software that reduces DFSORT's disk work data set allocations may cause a sort application to fail after processing a portion of the input records. To avoid this situation, you should take the appropriate steps to have such software exclude the following ddnames from those eligible for space reductions: SORTWK*, STATWK*, DATAWK*, DAnnWK*, STnnWK* and SWnnWK*. For example, if you are using Tivoli Allocation Optimizer, you should create a rule definition that excludes these ddnames from primary and secondary space reduction, or if you are using DFSMS data classes, you should not assign those ddnames to a DFSMS data class that uses the Space Constraint Relief feature.