HCL Workload Automation, Version 9.4

Updating SMF parameters

Updating SMF parameters is necessary to activate the exits used by the agent for z/OS for event tracking.

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 the agent for z/OS for 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:
Job-end and step-end exit.
Job initiation exit.
Record write exit.
The agent for z/OS uses the following SMF record types:
For all job tracking
For all job tracking
only for EDWA with SRREAD=YES
only for EDWA with VSAM data sets
HCL Workload Automation distributed - Agent for z/OS requires more SMF records to be collected if you install the SMF IEFU83 exit with SRREAD set to YES on the EELEXIT 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 EELU831 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 EELEXIT 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*/
  • 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 only if you run also IBM Workload Scheduler for z/OS in the same system. If you run only the agent for z/OS, the following line is of no use:

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. Consider using 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:
you would add this to get the equivalent processing in PROGnn:
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).