Defining subsystems

When you define the subsystem names of the Tivoli Workload Scheduler for z/OS controllers and trackers, consider the following:

• The Subsystem/STC name of Tivoli Workload Scheduler for z/OS controllers is unique within the PLEX. If two different controllers (regardless of their location) are configured to track work on the same z/OS® system, they must have different Subsystem/STC names.
• Because subsystem names on a given LPAR must be unique, and because all Tivoli Workload Scheduler for z/OS trackers and controllers started tasks must have the same name as their associated subsystems, all started tasks on any given LPAR must have unique names. That is, inside an MVS™ image, controllers and trackers must have unique Subsystem/STC names.
• Trackers running on different LPARs but connected to the same controller can have the same Subsystem/STC name. In this case, system variables like &SYSNAME can be used with the condition that each tracker uses different Tivoli Workload Scheduler for z/OS data sets. The tracker name cannot be the same as the name of a controller.

You must define the name of every new Tivoli Workload Scheduler for z/OS subsystem in the active subsystem-name-table member of SYS1.PARMLIB. Install at least two Tivoli Workload Scheduler for z/OS controlling systems, one for testing and one for your production environment.

To define the subsystems, update the active IEFSSNnn member in SYS1.PARMLIB. Include records as in the following example:

Subsystem definition record
SUBSYS SUBNAME(subsystem name) INITRTN(module name) INITPARM ('maxecsa,suffix')

subsystem name

The name assigned to a Tivoli Workload Scheduler for z/OS subsystem. The name must be from 2 to 4 characters. All the subsystem names, as defined in the SYS1.PARMLIB member IEFSSNnn, must be unique within a GRS complex with the exception of a standby controller. Also, the subsystem names of the controllers must be unique within your OPCplex/OPC network, both local and remote systems. Tivoli Workload Scheduler for z/OS requires the started task name or jobname used for a Tivoli Workload Scheduler for z/OS address space to exactly match the name of the associated subsystem.

module name

The name of the subsystem initialization module, EQQINITJ.

maxecsa

Defines the maximum amount of extended common service area (ECSA) that is used to queue job-tracking events. The value is expressed in kilobytes (1 KB equals 1024 bytes). The default is 4, which means that a maximum of 4 KB (4096 bytes) of ECSA storage is needed to queue job-tracking events. The maximum value allowed for MAXECSA is 2816.

suffix

The module name suffix for the EQQSSCM module that EQQINITJ loads into common storage. EQQSSCM is the subsystem communication module. The suffix must be a single character. Because the name of the module shipped with Tivoli Workload Scheduler for z/OS is EQQINITJ, specify a suffix value of J. If you do not provide a suffix, EQQINITJ attempts to load module name EQQSSCMJ. You can also specify a subsystem communication module name in the SSCMNAME keyword of the OPCOPTS initialization statement to load an updated version of the module before a scheduled IPL. For details, see Tivoli® Workload Scheduler for z/OS: Customization and Tuning.

Updating the z/OS link-library definition provides more information about EQQSSCM modules.

This example illustrates a record you can include in the SYS1.PARMLIB IEFSSNnn member:

/*Subsystem definition example*/
SUBSYS SUBNAME(OPCA) INITRTN(EQQINITJ) INITPARM ('100,J')

The record defines an Tivoli Workload Scheduler for z/OS subsystem called OPCA. This represents a tracker. Its initialization module is EQQINITJ. The amount of ECSA that is allocated, 101104 bytes, is enough for 1136 job-tracking events. Because suffix value J is specified, EQQINITJ loads module EQQSSCMJ.

Calculating MAXECSA values

Tivoli Workload Scheduler for z/OS allocates ECSA storage for job-tracking events in blocks of 1424 bytes. Each block is equivalent to 16 events. Table 22 gives examples of the storage needed for, the storage actually allocated, and the events accommodated for several maxecsa values. The number of events created for each job or started task in your environment is influenced by the definitions in the EWTROPTS initialization statement. Every job or started task creates a minimum of six events. If the job or started task generates output and PRINTEVENTS(ALL) or PRINTEVENTS(END) is specified, an event is created when each output group is purged. If STEPEVENTS(ALL) is specified, an event is created for every step in the job or started task.

If you want to calculate values that are not shown in Table 22 for a given MAXECSA value, use this method:

• Space requested = MAXECSA * 1024
• Blocks = space requested / 1424 (round down to a whole number)
• Space allocated = blocks * 1424
• Events accommodated = blocks * 16