Multi-sysplex
configuration with JESplex matching sysplex
Invoking the WLM query
service at the tracker rather than at
the controller level allows for support of multiple Sysplex handled
by one controller (macro range is Sysplex-wide). Multi-sysplex configuration:
JESplex
matching sysplex shows
this type of configuration.
Figure 1. Multi-sysplex configuration:
JESplex
matching sysplex
In this configuration,
it is important that the controller is told
from which Sysplex the tracker event communicating the availability
of the scheduling environment comes from, so that the operations waiting
for that scheduling environment can be submitted again. To do so,
use the SYSPLEXID (nn) parameter,
where nn can be an integer from 1 to
9999. The default is 1. This parameter applies both to trackers and
controllers.
A scheduling environment named
DB2x is defined both in Sysplex
1 and in Sysplex 2 and initially it is unavailable in both Sysplexes:
You submit a job with SCHENV=DB2x on tracker T3 of system
C, Sysplex
1.
Tracker T3 finds that the DB2x scheduling environment is
not available
and sends an IJ4 event, Submit failed, to the controller, with a record
of the putting scheduling environment name and of the sysplex ID.
The controller places the operation in status READY, WAITING FOR
SE and stores both the scheduling environment name (DB2x) and the
Sysplex ID (1).
DB2x becomes available on Sysplex 2. Tracker
T5 of Sysplex 2 warns
the controller by sending an event.
The controller checks
the operation in status READY, WAITING FOR
SE against the scheduling environment name (DB2x) and the sysplex
ID (2) and finds they do not match.
DB2x becomes available
on tracker T4 of system D, Sysplex 1.
Tracker T4 warns the controller by sending an event.
The controller
checks the operation in status READY, WAITING FOR
SE against the scheduling environment name (DB2x) and the sysplex
ID (1) and finds that they do match. The operation is resubmitted.