Terminology differences
This chapter provides a description of some of the terminology you are likely to encounter during the rest of this book. We focus in particular on cases where the same term is used in JES2 and JES3 but with different meanings.
2.1 JES3 terminology
In JES3 terminology, a processor is defined as a hardware unit that contains software to interpret and process instructions. Figure 2-1 shows a typical JES3 complex.
Figure 2-1 JES3 complex showing three LPARs
This complex is described as follows:
Global processor The processor that controls job scheduling and device allocation for a complex of processors. See also local processor.
Local processor In a complex of processors under control of JES3, a processor connected to the global main by JESXCF services, for which JES3 performs centralized job input, job scheduling, and job output services by the global main.
Main A processor named by a JES3 MAINPROC initialization statement, on which jobs can execute; represents a single instance of MVS. The two types of mains are global main, and local main.
Global main The global main controls job scheduling and device allocation for a complex of JES3 processors. Each local main in the complex exists under control of the JES3 global main and is connected to the global main by JESXCF services. The JES3 on the global main can perform centralized job input, job scheduling, and job output services. Only the global main performs scheduling functions, although scheduled work executes on the local mains.
Local main In a complex of processors under control of JES3, a processor connected to the global main by JESXCF services, for which JES3 performs centralized job input, job scheduling, and job output services by the global main.
|
Note: The JES3 global is the system where JES3 executes and schedules work to the JES3 locals. The JES3 address on the locals is there for the possibility that the global might fail and a DSI process can be used to make any of the locals the new global. Of course, a local can take over the global function when it is decided to switch the global for any wanted reason.
|
2.2 Different use of terms
Because of the long and somewhat independent histories of JES2 and JES3, there are some situations where the use of terminology might cause some confusion when moving from one JES to the other. There are some cases where the same term is used to mean different things. And other cases where two different terms are used to describe what might be the same thing.
This section brings all these cases together into one place, and will help avoid confusion as you read the remainder of this book.
2.2.1 Non-specific JES2 and JES3 references
Often it is useful to refer to JES2 and JES3 in ways that are non-specific. There are a number of ways that this is done:
JES This is a non-specific reference to a JES. It is used when speaking of concepts that apply to both JESs. For example, “Each z/OS image must have a JES subsystem to process jobs.”
JES-neutral There are functions that perform the same in both 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.
JES-agnostic Much like JES neutral, this is something that uses JES2 service in a way that does not care about the type of JES you are running. For example, “One of the goals in preparing for a migration to JES2 is to make your JCL JES-agnostic.”
2.2.2 Collections of JESes
Both JES3 and JES2 have the concept of a collection of JES address spaces that share a single work queue. However, the terms used to refer to the collection varies with the JES:
Complex This is the term that JES3 uses to refer to its collection of a single JES3 Global and up to 31 Locals that share a single JES3 work queue.
MAS Multi-Access SPOOL: This is the term that JES2 uses to refer to the collection of up to 32 JES2 address spaces that share a single JES2 work queue.
JESplex JES complex: This is a JES-agnostic term coined to refer to either a JES2 MAS or a JES3 complex. You can also modify this with the type of JES such as a JES2 JESplex.
The term used to refer to one of the JES address spaces in the collection also differs by JES:
Member JES2 address spaces in a MAS are referred to as members of the MAS. This is also the term 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 with a name of your choice, but the name is limited to 4 characters.
System JES3 address spaces in a complex are often just referred to as systems. This terminology was developed because there is only one JES3 address space per z/OS image.
Main Another name for a member of a JES3 complex. This can be a Local or a Global.
In JES3, the name of a JES3 Global or Local can be up to 8 characters long.
2.2.3 JES startup processing
Operationally, there are two ways to start JES2. You can specify PARM=COLD or PARM=WARM (the default). A cold start will clear all JES2 SPOOL and checkpoint data areas (delete all jobs) and like 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 will do different processing.
Regardless of the type of start, JES2 always reads its parameters from the members pointed to on the HASPPARM DD statements when it is starting. It then compares the information found in the parms with the information it gets 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, informing you that the parameter was ignored.
The types of start that JES2 can perform are as follows:
Cold start This start occurs when you specify PARM=COLD when JES2 is started. The JES2 spool will be cleared of all contents. This type of start requires that all the members of the MAS are stopped. On the system that is performing the cold start, you either must perform an IPL, or you can completely stop JES2 and then start it up again, specifying that it will perform a cold start. Given that all work on the system must be stopped before you do this, there is little difference between stopping and restarting JES2 to do the cold start, and IPLing that system.
Warm start (single 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 have been associated with this member from a previous instance will be reset (marked as no longer actively being processed).
Quick start (single system) This start occurs when you specify PARM=WARM when JES2 is started. This is the same as a warm start except that no work is associated with this member from a previous instance. This occurs if the member:
•Was shut down cleanly via a $P JES2 command, or,
•Is starting after an all member warm start or a cold start, or,
•Has had its work reset by a $E MEMBER command or via the AUTOEMEM process
Warm start (MAS-wide) 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. Like 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 at this time. In addition, certain operating parameters can only be reset on this type of start.
Hot 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 has occurred. Like all other warm starts, the checkpoint is read in and processed. Work in the job queue that is associated with processes that were terminated when the JES2 address space was ABENDed are reset, but work associated with active address spaces (running jobs, internal readers, and so on) is not reset. That work continues normal processing.
JES3 uses similar terminology, but the impact can be different. For JES3, the start type is set in the response to message IAT3011:
Cold start 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.
Warm start 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. Like a cold start, a JES3 warm start also requires that every z/OS in the JES3 complex is IPLed.
Hot start During a hot start, the initialization stream is not read. Instead, the configuration information is read from control blocks stored in the spool. A JES3 hot start does not require that z/OS be IPLed. If a system is IPLed and then JES3 hot starts, job processing will resume. Job processing can continue across a JES3 hot start if the system is not IPLed.
Hot start with refresh Hot start with refresh is similar to a hot start except that the initialization stream is re-read. This allows for initialization deck statements to be altered without requiring a warm or cold start and the associated complex-wide IPL.
Restart with analysis Hot and warm JES3 restarts allow for an additional “analysis” option to be specified. When analysis is requested, additional verification is performed for jobs on the job queue and invalid jobs can be purged.
Warm start with replace This start performs the same function as a warm start. In addition, it allows you to replace a spool data set.
2.2.4 JES parameter statements
Both JESs have parameter statements that define objects to JES and set operating parameters. These are referred to as:
Inish deck JES3 initialization steam. This is read when JES3 first initializes on a system and on a hot start with refresh.
Init deck JES2 initialization stream. This 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.
2.2.5 SYSOUT processors
Both JESs support sending SYSOUT from SPOOL to physical or logical devices for processing. These are referred to as:
Writer 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.
Printer 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.
2.2.6 Remote workstations
A remote work station that connects to JES is referred to as:
RJP Remote Job Processing (RJP) in JES3
RJE Remote Job Entry (RJE) in JES2
2.2.7 JES threads
Both JESs have a main task that is shared by multiple threads or processes. There are also externals that control the number of particular types of these threads in both JESs. The names for these threads are:
DSP 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, in conjunction with FCT entries, provide the basis for JES3 subsystem multitasking.
FCT 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-do. 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 reside permanently in the FCT chain, and some are added and removed only as needed.
PCE JES2 processor control element. This is a control block that represents a thread or process 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 via commands (such as $ADD PRINTER). Exit code or installation load modules can also define and create PCEs as part of their processing.
2.2.8 Multiple JES2 images
JES2 supports running multiple instances of JES2 running on a single z/OS. The additional instances can be in a separate MAS to the primary JES2, or they can be in the same MAS as the primary JES2. There are a number of reasons why you might want to have more than one JES2 instance. Some common examples are:
•To test new functions on a production system, but separate from the production MAS.
•To offload functions such as NJE or printing from the primary member to a secondary.
•To provide easy access to a secondary MAS on a production image.
There have been numerous terms used when describing this concept. They include:
Primary JES This refers to the JES that is the primary subsystem on a particular z/OS image. There is only one primary JES.
JES2 can run as either a primary or a secondary JES. JES3 can only run as a primary.
Secondary JES This refers to a JES2 subsystem that is not the primary JES2 subsystem. There can be many secondary subsystems on a z/OS image. These are always JES2 subsystems since JES3 does not support running as a secondary subsystem.
PolyJES This refers to the process of running multiple JES instances on a single z/OS.
Alternate JES This is another name for a secondary JES2 subsystem. Alternate is often used when there are more than two JES instances on a single z/OS image. For example, “This system has three JES2 address spaces; one primary and two alternates.”
2.2.9 JES initialization statements
Because JES2 and JES3 provide fundamentally the same function (batch job handling), and they both depend on a set of initialization statements to define the configuration to them, it is not surprising that JES2 and JES3 will have initialization statements that are similar. In fact, in some cases they use identical keywords. Sometimes these keywords have the same meaning, and other times they have subtly different meanings. See 7.3, “Initialization statements” on page 101.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.