Evaluating data set activity

SMF produces several records that contain information on data set activity. These records, which include types 4, 14, 15, 17, 18, 30, and 34 can help the installation to answer the following questions:

The following examples show different ways of evaluating problem-program data set activity from SMF records.

Multiple extents

By checking the “number of extents” field in the UCB section of SMF type 14 and 15 records, an installation can identify direct access data sets that have exceeded their primary allocation and have used secondary allocation. Although useful, secondary allocation might affect system performance and fragment the space on direct access volumes.

One reason to check for data sets that are going into multiple extents is to avoid an X37 abend in a production job the next time it runs. While the job may get the space it needs this time, the next allocation may be on a volume that only has enough space for the primary allocation. The attempt at secondary allocation will fail and waste resources in reruns.

Data set modifications

SMF generates a record each time a user:
  • Scratches a non-VSAM data set (type 17).
  • Renames a non-VSAM data set (type 18).
  • Updates a VSAM data set (type 60).
  • Defines a catalog entry for the integrated catalog facility (type 61).
  • Alters or renames a catalog entry for the integrated catalog facility (type 66).
  • Defines or alters a VSAM catalog entry (type 63).
  • Deletes a catalog entry for the integrated catalog facility (type 65).
  • Deletes a VSAM catalog entry (type 67).
  • Renames a VSAM catalog entry (type 68).

By sorting these records by job name or user ID, an installation can produce a report of the data sets that were defined, modified, or deleted by problem programs during a specified interval. Such a report might be useful in a backup situation, especially when critical data sets have been unintentionally altered or destroyed.

Open/close activity

SMF writes a type 14 or 15 record whenever a data set is closed or processed by EOV. The installation can determine how many times EOV closed or processed a given data set by counting the number of type 14 and 15 records. (For this kind of report, an installation might want to exclude any SMF records for programs such as sorts, where it is known in advance that the open/close activity is significant.)

Blocking factors

By examining the “block size” and “logical record length” fields recorded in the SMF type 14 and 15 records, an installation can identify those data sets that the system is processing with ineffective blocking factors. For instance, assume a data set having 10,000 records is processed unblocked with a logical record length of 80 using a 3380 device. An installation discovering such a data set through SMF might increase its block size to 6160 (77 records) to minimize I/O processing overhead and reduce direct access storage requirements.

Optional services

Although useful, some optional services might hinder system performance if not used appropriately. For example, the write validity check (OPTCD=W) service requires an additional disk rotation to reread the data written for each output block. Similarly, a data set that over uses the chained scheduling (OPTCD=C) service might monopolize the available time on a channel. An installation can use the SMF type 14 and 15 records to ensure that each application that uses an optional service is authorized or justified in using it.