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

The graphic a configuration of an end-to-end with fault tolerance capabilities environment with both TCP/IP and APPC connections.

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.

The following scenario, based on Multi-sysplex configuration: JESplex matching sysplex, helps explain how SYSPLEXID is used.

A scheduling environment named DB2x is defined both in Sysplex 1 and in Sysplex 2 and initially it is unavailable in both Sysplexes:
  1. You submit a job with SCHENV=DB2x on tracker T3 of system C, Sysplex 1.
  2. 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.
  3. The controller places the operation in status READY, WAITING FOR SE and stores both the scheduling environment name (DB2x) and the Sysplex ID (1).
  4. DB2x becomes available on Sysplex 2. Tracker T5 of Sysplex 2 warns the controller by sending an event.
  5. 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.
  6. DB2x becomes available on tracker T4 of system D, Sysplex 1. Tracker T4 warns the controller by sending an event.
  7. 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.