Defining subsystems
- The Subsystem/STC name of HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 a z/OS 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 HCL Workload Automation for Z data sets. The tracker name cannot be the same as the name of a controller.
You must define the name of every new HCL Workload Automation for Z subsystem in the active subsystem-name-table member of SYS1.PARMLIB. Install at least two HCL Workload Automation for Z 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 an HCL Workload Automation for Z 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. HCL Workload Automation for Z requires the started task name or job name used for an HCL Workload Automation for Z address space to exactly match the name of the associated subsystem.
- module name
- The name of the subsystem initialization module, EQQINIT0.
- 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 EQQINIT0 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 HCL Workload Automation for Z is EQQINIT0, specify a suffix value of 0. If you do not provide a suffix, EQQINIT0 attempts to load module name EQQSSCM0. 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 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(EQQINIT0) INITPARM ('100,0')
The record defines an HCL Workload Automation for Z subsystem called OPCA. This represents a tracker. Its initialization module is EQQINIT0. The amount of ECSA that is allocated, 101104 bytes, is enough for 1136 job-tracking events. Because suffix value 0 is specified, EQQINIT0 loads module EQQSSCM0.