Updating SMF parameters

The SMFPRMnn member defines parameters for the System Management Facilities (SMF). You must verify that the active SMF parameter member, SMFPRMnn, specifies that all SMF exits used by Tivoli Workload Scheduler for z/OS event tracking are activated, and that the required SMF records are being collected. If this is not the case, you must update the active SMF parameter member. Event tracking requires these SMF exits:

IEFUJI: Job initiation exit
IEFACTRT: Job-end and step-end exits
IEFU83: Record write exit. It is optional, and required only for data set triggering, automatic time change, and print event functions.

Tivoli Workload Scheduler for z/OS uses the following SMF record types:

6: For PRINT (A4 and B4) events, used only for tracking work on PRINT workstations
14: Only for data set triggering with SRREAD=YES
15: For data set triggering with SRREAD=YES or SRREAD=NO
18: Only if you want to monitor renaming data sets.
26: For all job tracking
30: For all job tracking
64: Only for data set triggering with VSAM data sets
90: Only if you want automatic daylight savings time change

Tivoli Workload Scheduler for z/OS requires more SMF records to be collected if you install the SMF IEFU83 exit with SRREAD set to YES on the EQQEXIT invocation. Specify this if you want special resource availability events automatically generated when a data set is closed after being opened for:

Read processing
Output processing
Either read or output processing

These SMF records are needed:

Type 14 records are required for non-VSAM data sets opened for INPUT or RDRBACK processing.
Type 15 records are required for non-VSAM data sets opened for output.
Type 64 records are required for VSAM data sets.
Type 90 records support daylight savings time automatically (optional).

You can specify that the SMF records used by the exit are not written to the SMF log. If your installation does not currently collect SMF records 14, 15, or 64, but you want resource availability events automatically generated, change the EQQU831 sample so that these records are not written to the SMF log.

To avoid data set triggering, and thus to improve performance, specify SRREAD=NO in the IEFU83 SMF exit on invocation of the EQQEXIT macro. The SRREAD=NO parameter prevents data set triggering for only SMF record type 14.

Active exits are defined by the EXITS parameter of the SYS and SUBSYS keywords. An example of these keywords is:

/*SYS and SUBSYS keywords*/
SYS(TYPE(6,14,15,18,26,30,60,62,64,90),EXITS(IEFU83,IEFACTRT,IEFUJI))
 SUBSYS(STC,EXITS(IEFUJI,IEFACTRT,IEFU83))
 SUBSYS(JESn,EXITS(IEFUJI,IEFACTRT,IEFU83))

Notes:

JESn is either JES2 or JES3. This parameter does not refer to JES itself, but to batch jobs handled by JES. So do not suppress exit invocation. Ensure that you do not specify TYPE6=NO and TYPE26=NO on the JOBCLASS and STCCLASS statements of the JES2 initialization parameters.
You might find it useful during installation to code two SMFPRMnn members, one with the exits active and the other with the exits inactive. You can then use the SET SMF=nn z/OS command to switch your current SMF parameters to the new member. By switching back, using the SET SMF=nn command, you avoid the need to re-IPL, if you encounter a problem.
Exits for SUBSYS STC are required by Tivoli Workload Scheduler for z/OS.

Use the PROGnn parmlib member to specify installation exits and control their use. Using PROGnn, you can associate multiple exit routines with installation exits at IPL, or while the system is running. IBM® recommends that you use PROGnn in addition to SMFPRMnn to specify exits, whether or not you want to take advantage of these functions.

The following example shows how you can specify SMF exits in a PROGxx parmlib member. If you specify this in SMFPRMnn:

  SYS(...EXITS(IEFU83,IEFACTRT,IEFUJI))

you would add this to get the equivalent processing in PROGnn:

  EXIT ADD EXITNAME(SYS.IEFU83) MODNAME(IEFU83)
  EXIT ADD EXITNAME(SYS.IEFACTRT) MODNAME(IEFACTRT)
  EXIT ADD EXITNAME(SYS.IEFUJI) MODNAME(IEFUJI)

When you associate new exit routines with SMF exits through PROGnn or the SETPROG command, you must use the following naming conventions:

For exits listed on the EXITS keyword of the SYS statement in SMFPRMnn, each exit will have the name SYS.xxxx (where xxxx is one of the exits listed).
For exits listed on the EXITS keyword of the SUBSYS statement of SMFPRMnn, each exit will have the name SYSzzzzz.xxxx (where zzzz is the name of the subsystem and xxxx is one of the exits listed).

If you define two members in SYS1.PARMLIB with two different names, for example, PROG03 in which there is the statement EXIT ADD EXITNAME(SYS.1 EFACTRT) MODNAME(EQQACTR1), you can switch to the version EQQACTR1 without re-ipling by issuing the command:/SET PROG=03

If you are using FTP, you must add the following statement to the SMFPRMxx member:

   SUBSYS(OMVS,EXITS(IEFUJI,IEFU83))

Also, these statements must be added to the PROGnn member, making sure that you replace MODNAME with the module name that was used when the exits were link-edited:

   EXIT ADD EXITNAME(SYSOMVS.IEFU83) MODNAME(EQQU831)
   EXIT ADD EXITNAME(SYSOMVS.IEFUJI) MODNAME(EQQUJI1)

For information on using PROGnn to control the use of exits and exit routines, see z/OS Initialization and Tuning Reference