Multi-sysplex configuration with JESplex not matching sysplex

Multi-sysplex configuration: multiple JESplex shows a configuration where there are multiple JESplex within a single Sysplex.
Figure 1. Multi-sysplex configuration: multiple JESplex

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

According to IBM® recommendations, the best configuration is when the JESplex (JES2 MAS or JES3 Complex) and the Sysplex match. Nevertheless, it is possible to define more JES complexes (JES2 or JES3) within a Sysplex. In this situation, a job submitted in a JES complex cannot be routed by WLM to another JES complex, regardless of the output of the IWMSEQRY service.
Note: If you use virtual workstations with the WLM SCHENV interface, all the virtual destinations must be in the same sysplex and JESplex.
In the configuration shown in Multiple JES within a Sysplex, suppose there is a scheduling environment named DB2x. This scheduling environment is available on system D only. When the IWMSEQRY service is invoked from system A, the returned output indicates that DB2x is available in the Sysplex, overlooking the existence of the MAS 1 boundary. This is a problem: if a job requires DB2x, and it is submitted on system A, it will hang indefinitely in the JES input queue.
Figure 2. Multiple JES within a Sysplex

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

From a WLM point of view, this works as designed. To support this type of configuration, you must use the initial parameter statement OPCOPTS JESPLEX. that informs trackers of the identity of the multiple JESplex. The JESPLEX (List of system names) parameter provides the system names within the JESplex where the tracker belongs.

In the example shown in Multiple JES within a Sysplex, if TA, TB, TC, and TD are the trackers installed on MVS™ images A, B, C, and D respectively, the OPCOPTS JESPLEX parameter for each of the trackers must be as shown in JESPLEX parameters for the trackers:
Table 1. JESPLEX parameters for the trackers
Tracker name JESPLEX parameter
TA JESPLEX (A, B)
TB JESPLEX (A, B)
TC JESPLEX (C, D)
TD JESPLEX (C, D)

When the job is submitted on system A, tracker TA first checks the response of the WLM query if DB2x is available with its own JESplex list (A and B). For this reason, tracker TA understands that DB2x is not available in its own JESplex and therefore does not submit the job.

However, this is a static definition, therefore if you change configuration you have to stop the tracker, update the parameter, and restart the tracker. This problem can be avoided by supporting multiple JESplex in the same Sysplex, without involving the trackers but only following a best practice approach to define and use scheduling environments.

For example, consider each MAS as a resource. If you have MAS 1 and MAS 2, define:
MAS1
Required in ON state on MAS 1, in OFF state on MAS 2
MAS2
Required in OFF state on MAS 1, in ON state on MAS 2
This corresponds to the following: 
                        ....System A      System B      System C      System D
Resource State    MAS 1     ON            ON            OFF           OFF     
                  MAS 2     OFF           OFF           ON            ON
Thus, proceed as follows:
  1. Associate MAS 1 with all the scheduling environments for jobs to be submitted on MAS 1
  2. Associate MAS 2 with all the scheduling environments for jobs to be submitted on MAS 2
The following scenario, based on the configuration of Multi-sysplex configuration: multiple JESplex, shows how to define a scheduling environment without using the OPCOPTS JESPLEX parameter. To define the scheduling environment, apply the following rules:
  • Assign a letter to each JESplex in the configuration. For example, in Multi-sysplex configuration: multiple JESplex SYSPLEX 1 JES MAS 1 can be identified with X, SYSPLEX 1 JES MAS 2 can be identified with Y, and JES3 GLOBAL with Z.
  • Use the same name for the same resource throughout all MVS™ images. For example, DB2ACT should indicate, when set to ON, that the DB2® application is active on a specific image.
  • Define for each JESplex the MASx resource, where x is the letter associated to the JESplex. For example, resources MASX, MASY, and MASZ are to be defined as follows:
    Table 2. The MAS resources and their associated JESplex
    Resource SYSPLEX 1 System A SYSPLEX 1 System B SYSPLEX 1 System C SYSPLEX 1 System D SYSPLEX 2 System A SYSPLEX 2 System B SYSPLEX 2 System C
    MASX ON ON OFF OFF OFF OFF OFF
    MASY OFF OFF ON ON OFF OFF OFF
    MASZ OFF OFF OFF OFF ON ON ON
  • If a job requires that application DB2® be active, define 3 different scheduling environments so that they can be associated with the job depending on where the job is run (either MASX, MASY, or MASZ). For example:
    XSEDB2, for the job to run on MASX
    • Resource DB2ACT must be ON
    • Resource MASX must be ON
    YSEDB2, for the job to run on MASY
    • Resource DB2ACT must be ON
    • Resource MASY must be ON
    ZSEDB2, for the job to run on MASZ
    • Resource DB2ACT must be ON
    • Resource MASZ must be ON
  • Suppose that job XMYJOB is to be run on MASX with DB2® active. You must associate it with scheduling environment XSEDB2. Suppose you submit this job on MASX system A and the resource status is the following:
    Table 3. The MAS resources and their associated JESplex
    Resource SYSPLEX 1 System A SYSPLEX 1 System B SYSPLEX 1 System C SYSPLEX 1 System D SYSPLEX 1 System A SYSPLEX 1 System B SYSPLEX 1 System C
    MASX ON ON OFF OFF OFF OFF OFF
    MASY OFF OFF ON ON OFF OFF OFF
    MASZ OFF OFF OFF OFF ON ON ON
    DB2ACT OFF OFF OFF ON ON ON ON

When the tracker invokes the IWMSEQRY macro, XSEDB2 shows to be unavailable (because the status of DB2ACT is OFF) without having had to define the OPCOPTS JESPLEX parameter.