1.2.2 Multi-subsystem OperationsMultiple pairs of the Systemwalker Operation Manager Jobscheduler and Job Execution Control functions can be run simultaneously. Each pair is referred to as a "subsystem" and operations that run multiple subsystems are referred to as "multi-subsystem operations."
Up to 10 subsystems can run on a single machine
The following multi-subsystem operations are supported.
Operating multi-subsystems on a single machine
Operating multi-subsystems of schedule servers
Operating schedule servers and execution servers as subsystems
Each operation configuration is explained below.
Operating multi-subsystems on a single machine
The following figure illustrates multi-subsystem operations on a single machine.
If multi-subsystems operate on a single machine, subsystem 0 can be used for production system operations, subsystem 1 can be used for testing next month's data, and subsystem 2 can be used for testing new jobs, for example.
In this example, if jobs for test operations are actually executed, the resources for production system operations might be affected. If there is such a possibility, bypass execution of these jobs by disabling these jobs.
This makes it possible to test jobs that have been created without affecting production system operations.
Operating multi-subsystems of schedule servers
The following figure illustrates a configuration where multiple schedule servers alone are operated as subsystems.
Operating multiple subsystems consisting of only schedule servers makes it possible to perform test operations that link to network jobs, as shown in the following example.
Note
If the execution server is running one of the following versions of Systemwalker Operation Manager, it can receive jobs from only Subsystem 0:
Version V5.0L30 or before [Windows version]
Version V5.0 or before [UNIX version]
Job execution requests can be sent from only Subsystem 0. Refer to "A.5 Executable Range of Network Jobs" for details.
Information
The Zone function supported by Solaris 10 or later makes similar operations possible with a single server, as shown below.
This configuration operates multiple subsystems in the Global Zone for the job schedule server, and uses a Non-global Zone as a job execution server.
Systemwalker Operation Manager runs by regarding each zone as a single server. Even for multiple subsystem operations, network jobs can be submitted from a subsystem in a zone by assigning logical IP addresses to the zones and specifying logical port numbers for the multiple subsystems.
Operating schedule servers and execution servers as subsystems
The following figure illustrates a configuration where both schedule servers and execution servers are operated as multiple subsystems. Any desired subsystem can be operated as a schedule server or an execution server.
In the example in the following figure, Subsystem 1 on Server A and subsystem 1 on Server B are used as a schedule server in a cluster configuration, while subsystems 0 and 2 on Server A and subsystems 0 and 2 on Server B are used as execution servers.
In the example in the following figure, Subsystem 1 on Server A is used as a schedule server, while Subsystem 1 on Server B and Subsystem 1 on Server C are used as an execution server in a cluster configuration, and Subsystem 0 on Server B and Subsystem 0 on Server C are used as independent execution servers.
Operating schedule servers and execution servers as subsystems makes it possible to create separate job execution environments for each subsystem. For example, it is possible to set job multiplicity separately for each subsystem.
Note
If either the schedule server or the execution server is running V13.2.0 or earlier, or if the job to be executed is any of the following types, it is not possible to send a job execution request to any server:
Demand jobs (jobs submitted from a job folder or from a non-folder management jobs)
Jobs with Interstage attributes
JCL (Job Control Language) jobs
When sending a job request from a schedule server to an execution server, send the request to the same subsystem number as the subsystem number on the server making the request, as shown in the following diagram.
