This chapter describes some of the terminology you are likely to encounter in the rest of this IBM Redbooks publication. We focus in particular on cases where the same term is used in JES2 and JES3, but with different meanings.

This chapter includes the following topics:

This term is a non-specific reference to a JES. It is used to refer to concepts that apply to both JESs. For example, “Each z/OS image must have a JES subsystem to process jobs.”

Some functions work the same in JES2 and JES3. These functions are often referred to as JES neutral. For example, security processing is performed by the security product in a way that is JES-neutral.

Much like JES neutral, this term applies to something that uses JES2 service in a way that is unaffected by the type of JES that you are running. For example, “One of the goals in preparing for a migration to JES2 is to make your JCL JES-agnostic.”

JES2 and JES3 feature the concept of a collection of JES address spaces that share a single work queue. However, the following terms that are used to refer to the collection varies with the JES that is referenced:

A Multi-Access SPOOL, this term is used by JES2 to refer to the collection of up to 32 JES2 address spaces that share a single JES2 work queue.

JES3 uses this term to refer to its collection of a single JES3 Global and up to 31 Locals that share a single JES3 work queue.

A JES complex is a JES-neutral term that refers to a JES2 MAS or a JES3 complex. You can also modify this term with the type of JES, such as a JES2 JESplex.

The term that you use to refer to one of the JES address spaces in the collection also differs by JES, as shown in the following examples:

A JES2 address spaces in a MAS are referred to as members of the MAS. This term is also used to refer to members of a JESplex.

In JES2, the member name defaults to the SMF ID of that system. You can override that name with a name of your choice, but the name is limited to four characters.

You can have multiple JES2 instances in a single MVS image (poly-JES). The term poly-JES refers to the concurrent operation of multiple copies of JES2.

z/OS 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.

JES3 address spaces in a complex are often referred to as systems. This terminology was developed because only one JES3 address space per z/OS image is available.

This term is another name for a member of a JES3 complex. This member can be a Local or a Global.

In JES3, the name of a JES3 Global or Local can be up to eight characters long.

JES2 supports up to three consecutive releases of JES2 that are running in the same MAS. JES2 enforces this rule and ships service to previous releases so that they can coexist with the newer releases.

JES2 also supports a more liberal migration policy. This migration policy covers migrating from one release of JES2 to a new release with a warm start.

Operationally, JES2 can be started by using one of two methods. You can specify PARM=COLD or PARM=WARM (the default). A cold start clears all JES2 SPOOL and checkpoint data areas (delete all jobs) and as with a JES3 cold start, is rarely done. Warm starts are the normal way to start JES2. How JES2 processes a warm start depends on the environment JES2 discovers during initialization. Depending on the environment, a JES2 warm start performs different processing.

Regardless of the type of start, JES2 always reads its parameters from the members that are pointed to on the HASPPARM DD statements or the default PARMLIB concatenation when it is starting. When reading from default PARMLIB concatenation, JES2 uses HASjesx as member name, where jesx is the subsystem name that is associated with it. It then compares the information that is found in the parameters with the information it receives from the checkpoint and from the other members of the MAS. If it encounters a parameter that requires a more disruptive type of start, it might issue an HASP442 message, which informs you that the parameter was ignored.

JES2 can perform the following types of starts:

This start occurs when you specify PARM=COLD when JES2 is started. The JES2 spool is cleared of all contents. This type of start requires that all the members of the MAS are stopped.

Given that all work on the system must be stopped before this start is performed, little difference exists between stopping and restarting JES2 to perform the cold start and IPLing that system.

This start occurs when you specify PARM=WARM when JES2 is started and the starting JES2 member is joining a MAS with other active members. The JES2 checkpoint is read in and processed. Any work that might be associated with this member from a previous instance is reset (marked as no longer actively being processed).

This start occurs when you specify PARM=WARM when JES2 is started. This process is the same as a warm start except that no work is associated with this member from a previous instance. This process occurs if the member:

This start occurs when you specify PARM=WARM when JES2 is started and the starting member is the first (only) active member of the MAS. As with all other warm starts, the checkpoint is read in and processed. If any entry in the work queue indicates it is active, it is reset then. In addition, certain operating parameters can be reset only on this type of start.

This start occurs when you specify PARM=WARM when JES2 is started and a previous instance of the JES2 address space had ABENDed and no intervening IPL occurred. As with all other warm starts, the checkpoint is read in and processed.

Work in the job queue that is associated with processes that were ended when the JES2 address space was ABENDed are reset. However, work that is associated with active address spaces (running jobs, internal readers, and so on) is not reset. That work continues normal processing.

 

JES3 uses the following similar terminology, but the effect can be different. For JES3, the start type is set in the response to message IAT3011:

During a cold start, the initialization deck is read to determine the configuration. The SPOOL is initialized, and any jobs that were in the system are lost. A JES3 cold start requires that every z/OS in the JES3 complex is IPLed.

A warm start also requires an MVS IPL before it is allowed. The configuration is determined from the initialization stream. Most job processing resumes after this less intrusive restart. As with a cold start, a JES3 warm start also requires that every z/OS in the JES3 complex is IPLed.

During a hot start, the initialization stream is not read. Instead, the configuration information is read from control blocks that are stored in the spool. A JES3 hot start does not require that you IPL z/OS. If a system is IPLed and then JES3 hot starts, job processing resumes. Job processing can continue across a JES3 hot start if the system is not IPLed.

Hot start with refresh is similar to a hot start except that the initialization stream is reread. This process allows for initialization deck statements to be altered without requiring a warm or cold start and the associated complex-wide IPL.

Hot and warm JES3 restarts allow for an extra analysis option to be specified. When analysis is requested, more verification is performed for jobs on the job queue and invalid jobs can be purged.

This start performs the same function as a warm start. In addition, it allows you to replace a spool data set.

Both JESes include the following parameter statements that define objects to JES and set operating parameters:

JES2 initialization stream. This parameter is read in on every start of a JES2 address space. The format of statements in the JES2 init deck is the same as the corresponding operator command and the display command for the statement.

JES3 initialization steam. This parameter is read when JES3 first initializes on a system and on a hot start with refresh.

Both JESes support sending SYSOUT from SPOOL to physical or logical devices for processing. The following processors are referenced:

In JES2, a printer (JES-controlled or FSS-managed) is referred to as a printer. Applications that use SAPI are referred to as SAPI applications or SAPI threads. SYSOUT is commonly referred to as being placed on the print queue or the ready queue.

In JES3, a printer (JES-controlled or FSS-managed) or an application that uses the SYSOUT API (SAPI) is referred to as a writer. SYSOUT is commonly referred to as being placed on the writer queue.

A remote work station that connects to JES is referred to as:

Both JESes include a main task that is shared by multiple threads or processes. Externals also control the number of particular types of the following threads in both JESes:

JES2 processor control element. This control block represents a thread or process that is running under the JES2 main task. Each PCE performs a function (such as execution services), processes a job phase (such as the purge phase), or manages a device (such as a printer).

Some PCEs are created at initialization based on keywords on PCEDEF or other internal constants. Others can be created with commands (such as $ADD PRINTER). Exit code or installation load modules can also define and create PCEs as part of their processing.

JES3 dynamic support program. A DSP represents code that performs a small piece of job processing. Most JES3 job processing is performed by IBM written DSPs. These units of work, along with FCT entries, provide the basis for JES3 subsystem multitasking.

JES3 function control table. The JES3 main task processing scans a priority-ordered chain of FCT entries, looking for any FCT entries that represent active work to be done. Each FCT entry points to a DSP that is called to perform the work. Because FCT entries reference DSPs, the two terms are sometimes used interchangeably. Multiple FCTs that reference the same DSP can be inserted into the DSP chain. Some FCT entries are permanently stored in the FCT chain, and some are added and removed only as needed.

JES2 supports running multiple instances of JES2 that are running on a single z/OS. The extra instances can be in a separate MAS to the primary JES2, or they can be in the same MAS as the primary JES2. You might want to have more than one JES2 instance for the following reasons:

The following terms are used to describe this concept:

This term refers to the JES that is the primary subsystem on a particular z/OS image. Only one primary JES is available.

JES2 can run as a primary or secondary JES. JES3 can only run as a primary.

This term refers to a JES2 subsystem that is not the primary JES subsystem. Many secondary subsystems can be on a z/OS image. JES2 subsystems always are available because JES3 does not support running as a secondary subsystem.

This term refers to the process of running multiple JES instances on a single z/OS.

This term is another name for a secondary JES2 subsystem. Alternate is often used when more than two JES instances are used on a single z/OS image. For example, “This system has three JES2 address spaces; one primary and two alternates.”

JES2 and JES3 fundamentally provide the same function: batch job handling. They both depend on a set of initialization statements to define the configuration to them. Therefore, it is not surprising that JES2 and JES3 include initialization statements that are similar. In some cases, they use identical keywords. At times, these keywords have the same meaning; other times, they have subtly different meanings.