In the August/September 2014 issue of Enterprise Tech Journal, we provided an introduction to one of the most important components of z/OS—the System Management Facilities (SMF) component. Two of the key parts of MVS that write records to SMF are the job scheduling system and the master scheduler. SMF records are written as address spaces are created, executed and terminated. In this article, we’ll describe the life of an address space and when user exits are called and SMF records are written. Future articles will include more detail on SMF parameters, recommendations on SMF file creation and usage, and details about the most important record types.
There are several points during the life of an address space when a user may access the address space information and SMF records using SMF exits. In this section, we’ll describe the exits, and how they are used.
The SMFPRMxx parmlib member provides directions to SMF as to which records should be collected and written to a data set or logstream. Two of the SMFPRMxx keywords that specify the type of records that you want to collect are SYS and SUBSYS. One of the subparameters of these two keywords is EXITS(…). In this subparameter, you code the name of the exits that are to be invoked for the entire system or for certain subsystems. User exits are usually written by the systems programmer, although some are provided as samples by IBM or other vendors and others are offered by other users at no charge.
All of the SMF exits are shown in Figure 1, and are described below in the life of a job/ TSO user/started task/APPC process. You can specify which exits are to be invoked for all records on the SYS parameter or by subsystem on the SUBSYS parameter of SMFPRMxx. Valid IBM subsystems are JES2 or JES3 (for batch jobs), TSO (for TSO logons), STC (for started tasks) and ASCH (for APPC/MVS processes). Further information about exits can be found in the IBM z/OS MVS System Management Facilities (SMF) manual, or the IBM z/OS MVS Installation Exits manual.
Exits are primarily used to provide security, an audit trail or additional reporting. For the added function, you would expect some overhead. The overhead directly depends on the programming ability and efficiency of the exit programmer. Remember, these exits are called for every job, TSO user and started task, so they all need to be written extremely efficiently.
The CPU time used by executing exits will show up in various places in the job’s CPU times. It might show up in the TCB time, the SRB time or the initiator CPU time. An inefficient exit is difficult to identify because the CPU times are distributed across all of the jobs.