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, EQQINIT1.
- 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 EQQINIT1 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 EQQINIT1, specify a suffix value of 1. If you do not provide a suffix, EQQINIT1 attempts to load module name EQQSSCM1. 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.
For more information about the EQQSSCM modules, Updating the z/OS link-library definition.
The following example illustrates a record that you can include in the SYS1.PARMLIB IEFSSNnn member. The record defines an HCL Workload Automation for Z subsystem called OPCA. This represents a tracker. Its initialization module is EQQINIT1. The amount of ECSA that is allocated, 101104 bytes, is enough for 1136 job-tracking events. Because suffix value 1 is specified, EQQINIT1 loads module EQQSSCM1.
/*Subsystem definition example*/
SUBSYS SUBNAME(OPCA) INITRTN(EQQINIT1) INITPARM ('100,1')
setssi delete,s=XXXX,force
To add a new subsystem, issue
the following
command:setssi add,s=XXXX,i=EQQINITX,p='100,1'