Poly-JES

The term “poly-JES” refers to the concurrent operation of multiple copies of JES2. MVS™ allows more than one JES2 subsystem to operate at a time, if one subsystem is designated as the primary subsystem and others are identified as secondary subsystems. Secondary JES2s can be useful in testing user modifications while the primary JES2 is being used for production.

You might also find a secondary JES2 system to be useful when you need to test a new initialization data set, that is as an "init-deck checker" before running that data set on your production system.

You should replace a few specifications in the initialization deck so that the secondary JES2 does not conflict with the production JES2.

CKPTDEF - use different data set names or volumes
SPOOLDEF - use different volumes
CONDEF - use a different CONCHAR so that you can communicate with the secondary JES2

Certain operational considerations and restrictions apply to the secondary JES2:

You can start primary and secondary subsystems in any order.
Started tasks (STCs) can be directed to either a primary or secondary JES. However, when you identify a subsystem as a secondary, you cannot run started tasks (STCs) under that secondary unless you have initialized the primary at least once during this IPL. Attempting to run started tasks on a secondary without starting a primary at some time during this IPL can cause JES2 to become hung, forcing an installation to re-IPL.
Time-sharing users (TSUs) can only interface with the primary JES.
The MVS I/O attention table can only be associated with the primary JES. Therefore, secondary JESs cannot receive the “unsolicited interrupt” required to support pause-mode for print and punch devices and “hot readers” (that is, readers started by the physical start button without the $S RDR(n) JES2 command).
The MVS log console (SYSLOG) can only be associated with the primary JES.
Secondary subsystems are started individually rather than automatically during IPL using the IEFSSNxx parmlib member.
If the primary and secondary JESs are in the same MAS, a job restarted by automatic restart management will have affinity to both the primary and the secondary JESs. A job can run in the primary and rerun in the secondary, if there are initiators on both JESs capable of selecting the job. If you don't want jobs to have affinity to both JESs, you should segregate the job classes between the primary and the secondary JESs.

When running more than one JES2 at a time, it is necessary to assign (by use of the CONCHAR= parameter on the CONDEF initialization statement) a unique operator command character to each JES2. If the secondary subsystem is not part of the same multi-access spool complex, each JES2 member requires both a unique spool data set (specified on the VOLUME= parameter of the SPOOLDEF initialization statement) and a unique checkpoint direct access device (specified on the CKPTn=(...,VOL=) parameter of the CKPTDEF initialization statement). Also, the keyword “JES2” must be used to stop whatever subsystem is running, regardless of the name on the START command; for example:

    S   JES2         START  JES2
    $P  JES2         STOP   JES2       (default CONCHAR)
    START  JSS4      START  JSS4
    /P  JES2         STOP   JSS4       (CONCHAR=/)

Many of the considerations for running a primary JES are also appropriate for running a secondary JES; note the following:

The subsystem support module required by the secondary subsystem, must be placed in either the link pack area (LPA) or the common service area (CSA). See Table 1, for more information.
Note:
1. It is recommended that a STEPLIB data set be used for the secondary subsystem if the subsystem support module is different than the one in use by the primary system.
2. When the same copies of the JES2 subsystem support modules are in use by both the primary and secondary subsystems, minimize your storage use by making sure that the JES2 subsystem support modules are loaded into LPA.
If the secondary subsystem is placed in a library other than SYS1.SHASLNKE or a LNKLST library, be sure to add that data set name as a member to the APF (authorized program facility) specification list in order to authorize it. (See z/OS MVS Initialization and Tuning Guide for a complete description of this procedure.)
If a name other than HASJES20 is used for the main module (this is not recommended) that name must be added to the program properties table such that the program runs in protect key 1 and is nonswappable.