Convergence of JES2 and JES3
This chapter provides information about functions and features that are available in JES3 that are provided by JES2. Also described is how this convergence processing is being adopted to make both products more compatible and transparent from a user viewpoint.
The chapter also covers the functionalities that are different between JES2 and JES3 and how they can be addressed when converting from JES3 to JES2.
This chapter includes the following topics:
3.1 JES2 to JES3 compatibility
Over time, the differences between JES2 and JES3 decreased. Although they have different processing mechanisms, they can perform the same actions from a user’s view point.
In the last releases of z/OS, you can see that these differences are becoming minimal, as shown in the following examples:
•JES2 now includes Job Execution Control (JEC), which performs functions that previously were available in JES3 DJC only.
•The use of SCHEDULE evolved.
•JES3 JECL support is enhanced in every new JES2 release.
•Disk reader and multi job NJE job stream support was added in z/OS 2.4.
Also, some JES3 functions, such as multi-system consoles, automatic tape sharing, dynamic initiators, and workload balancing, can be provided by the operating system and are available to JES2 installations.
The convergence between JES2 and JES3 is increasing and both products are performing similar functions (see Figure 3-1). The enhancements to JES2 that were introduced in each new release are making it easier to migrate from JES3 to JES2.
Figure 3-1 Convergence between JES2 and JES3
3.1.1 JES2 health monitor
The JES2 health monitor is a service that allows for the monitoring of the subsystem status. By monitoring the status of the subsystem, JES2 can identify situations when the subsystem is not behaving the way it is expected to behave. JES2 uses the data that is provided by the monitor to notify the operator to determine the causes of the problems within the susbsystem.
However, remember that the monitor is not a performance monitor; it can help you identify possible causes that affect the subsystem performance.
The health monitor automatically starts when JES2 is initialized and ends when JES2 ends.
The health monitor samples JES2 processing to collect data and provide information when JES2 is not responding to commands or the problems are not easy to diagnose. Such situations can be basic, as shown in the following examples:
•A command that is taking an unexpected amount of time to complete.
•A legitimate “bug” in JES2.
•An exit routine problem.
•Problems with checkpoint.
Other code running in the JES2 address space
z/OS Runtime Diagnostics provides JES2 diagnostic information to assist the system programmer in identifying symptoms that contribute to “sick, but not dead” behavior.
JES2-detected health exceptions are added as events in Runtime Diagnostics, which is started by using the F HZR,ANALYZE system command (see Figure 3-2).
Figure 3-2 Response of F HZR,ANALYZE command with JES2 event found
Information is gathered about the JES2 subsystem from the JES2 subsystem interface (SSI). Runtime Diagnostics analyzes the information that is received, determines a possible corrective action, and presents this action to the caller on the system console, the hardcopy log, and optionally, to a sequential data set.
Also, when Predictive Failure Analysis (PFA) detects a potential rate that is too low (for the PFA checks that support “too low” processing) and starts Runtime Diagnostics to determine whether events exist, JES2 Health Exception events are returned by PFA when they exist and causes PFA to issue an exception.
SMF record type 84 contains information that is collected by JES2 or JES3 monitors. In JES2, the information is collected by the JES2 health monitor. The records are generated by each JES2 subsystem address space at the top of every hour. The SMF record 84 subtype 21 tracks the resource usage by JES2, which is similar to existing subtype 4. The subtype 4 is the control block utilization section for JES3.
The JES3 Monitoring Facility (JMF) provides several reports that can be used by the system programmers or software support if any specific performance or tuning concerns exist in JES3. The JES3 monitoring facility collects data from the system to see how the installation uses its resources. This information can help detect many performance problems and help you to tune the installation.
A JES3 command *X JMF starts the facility that can produce a hardcopy report or SMF records.
3.1.2 JES initialization deck checker
In JES2, syntax checking on the initialization parameters data set can be performed by using the initialization deck syntax checker. This JES2 checker can run in batch, as a started task, or linked with no APF authorization requirements. The user under which it runs must read the initialization decks.
The JES2 initialization deck checker can be used in the following ways:
•CHECK start PARM value (for example, PARM=’warm,check’)
•Alternate entry point HASJESCK (for example, PGM=HASJESCK)
Also, JES2 tends to be more forgiving of syntax errors in the JES2 initialization statements, which provides the operator with an option to resolve many errors during initialization.
The JES3 initialization deck checker is used to validate the format of the JES3 initialization statements. This process is more of an issue in JES3 than in JES2 because of the complexity of the JES3 initialization deck, especially if MDS is used. The IATUTIS program takes input from the IODF and uses that input to validate the syntax of the initialization deck.
|
Note: This initialization deck checker is enabled by using a JCL to run the program IATUTIS.
|
For more information about how to use initialization deck checker, including the JCL that is used to run it, see 5.2.1, “Verifying the JES initialization deck” on page 95.
3.1.3 JES2 Health Check for Checkpoint Reconfiguration
Introduced in z/OS 2.4, JES2 Health Check for Checkpoint Reconfiguration is designed to identify problems with the checkpoint configuration that prevent JES2 from recovering from device errors automatically. The check generates reports and messages that are issued to the console that help to take the required actions to improve checkpoint settings to avoid potential outages.
The checker is can detect issues that might arise over time, such as the amount of space on the backup checkpoint volume is not enough to hold a backup checkpoint because it runs on intervals. The check is refreshed if the checkpoint settings are modified.
As part of the initialization processing, JES2 automatically adds the checker to the Health Check.
The checkpoint checker display is shown in Figure 3-3. The current status of the checker is the exception.
Figure 3-3 SDSF Health Checker Display
Figure 3-4 on page 28 shows the information that is provided by the checker highlighting the exceptions detected; an operator intervention was requested.
If you review the message, you see that if you maintain the current options, the JES2 automatic checkpoint recovery does not occur. The reason for this failure is that the operator intervention option was enabled. Therefore, if an I/O error occurs on an active checkpoint data set, an operator intervention is requested.
Figure 3-4 SDSF Display of JES2 Checker Exception
3.1.4 Job Execution Control
The JES2 Job Execution Control (JEC) provides z/OS native support (through the standard JCL) for a job scheduling scheme within JES2 that can be used by any z/OS user. One goal is to preserve the relationships between the steps of a multistep job when it is broken down into a group of single (or few) step jobs.
Another goal is to combine a set of jobs into a network of jobs with related dependencies. The principal entity that controls job execution within JEC is a job group. A job group is a set of specifications between a JOBGROUP and ENDGROUP statement. The group defines the execution sequencing of a group of jobs and the jobs that are submitted after the job group specification.
The JES3 Dependent Job Control (DJC) includes a function that is similar to the JES2 JEC. DJC was originally provided as a JES3 function for installations that required a basic batch job networking capability and found that the use of conditional JCL (which uses COND codes) was cumbersome.
Over the years, most installations found that they required a more robust batch planning, control, and monitoring capability with less manual intervention. Now, the use of batch scheduling products, such as IBM Tivoli Workload Scheduler, is prevalent.
3.1.5 Deadline scheduling
With z/OS 2.3, JES2 provides functions to hold jobs until a specified time and to make jobs more likely to start running by a specified time. JES2 adds support for the SCHEDULE JCL statement with parameters HOLDUNTL and STARTBY. Use HOLDUNTL to hold the job until the specified time. Use STARTBY to move the job forward in the queue (increasing its priority, if needed) to make it more likely to start by the specified time.
The STARTBY function is also known as deadline scheduling control. The system cannot guarantee that a job finishes its execution by a certain time because too many variables are beyond the control of the system.
The system also cannot guarantee that a job begins its execution by a certain time. However, the system can now take measures so that the job has a fair chance to be the first in line to begin its execution by a specified time.
By using the STARTBY keyword on the SCHEDULE statement, users can specify an approximate time in the future when they want the job to start.
The system manages the priority of the job so that, by a target time, the job is near the top of the relevant job class or service class queue. In a sense, this function provides a time-controlled alternative to traditional priority aging.
Deadline scheduling is a function in JES3 that gives an user the ability to submit a job at a certain priority level at a certain time or day. It was also intended for jobs that must run at a designated time or period (for example, weekly).
These functions worked without a scheduling package or manual operator intervention. However, these functions can be better handled and controlled by a batch scheduling product, such as IBM Tivoli Workload Scheduler for z/OS, including its features for critical path processing and Event Triggered Tracking.
As processing capacity increased over the years, users came to expect that their jobs run when they are submitted; therefore, this function is not as critical as it used to be. If the job includes specific resource dependencies or must run at a certain time for charge back reasons, that process can also be controlled by using different job classes.
|
Note: The use of DEADLINE scheduling does not guarantee that the job executes at the exact time that you want. Some installations might find this function manually intensive to replace.
|
3.1.6 Priority aging
Jobs are selected to run based on job class and the available initiators in that class, and based on a priority in that particular job class queue. Priority aging is used to help jobs that were submitted on a system with an insufficient number of initiators.
Periodically, as defined by the relevant parameter, if the job is still on the job queue, the priority of the job is increased. This process potentially gives the job a better chance of being selected by an initiator and was intended to ensure that low-priority jobs did not languish in the job queue forever, while higher priority jobs were continually selected ahead of them.
Both JESes feature mechanisms to increase the priority of a job in the input queue based on how long the job is there. Consider the following points:
•In JES2, the function can be controlled by:
– Specifying a priority on the /*PRIORITY JECL statement for JES2-managed initiators.
– The use of the PRTYHIGH=, PRTYLOW=, and PRTYRATE= keywords on the JOBDEF initialization statement.
•In JES3, the function can be controlled by using SAGER/SAGEL and MAGER/MAGEL keywords on the SELECT INIT statement in the initialization deck
However, many installations use WLM-managed initiators. Workload management can dynamically manage the number of batch initiator address spaces in a JES2 or JES3 environment. You can selectively turn over control of the batch initiator management to WLM for one or more job classes. WLM starts new initiators as needed to meet the performance goals of this work.
By specifying MODE=WLM on the JES2 JOBCLASS statement or the JES3 GROUP statement, you indicate that the initiators for the job class are WLM-managed. In this environment, the JES priority of the job is irrelevant after it is selected for processing. Before it is selected for processing, the JES priority can be changed, which might change the designated service class for that job.
3.1.7 Support to eight-character job class name
JES2 supports up to eight-character job class names, such as JES3. The keyword CLASS= on JCL JOB card accepts the eight-character job class. With this function, JES2 and JES3 have similar capabilities that are related to job selection and the job class characteristics that can be assigned to a job. Also, to avoid many 2 - 8 character job class names being associated with a single initiator or a device, you can create job class groups to manage these associations.
3.1.8 Disk Reader Support
With z/OS 2.4, JES2 provides function similar to the JES3 disk reader DSP. It allows copying of a member from a predefined concatenation of PDSs, PDSEs, and z/OS UNIX directories to an internal reader, passing the records in the member to JES2 input processing.
This feature is implemented using three constructs that were introduced in z/OS 2.4:
•SUBMITLIB: Defines the libraries where the source members is stored. These libraries can be concatenated.
•SUBMITRDR statement: Defines the default for the input device. It is similar to the INTRDR statement.
•$SUBMIT command: Reads the members and passes them to the input processing.
3.1.9 JES2 Multi Job NJE Job Streams
Starting with z/OS 2.4, JES2 NJE was updated to support multiple jobs in a single job stream. Before z/OS 2.4, JES2 allowed only job per NJE job stream. If a second job was encountered, all jobs in the stream fail.
With this support, you can send a set of jobs to a node and have them processed by input processing in the correct order.
3.1.10 JES2 //*ROUTE XEQ Support
With z/OS 2.3, the support for many JES3 JECL statements was introduced. z/OS 2.4 adds the support for the JES3 //*ROUTE XEQ JECL. The syntax rules are the same as JES3, but the alternative form /*ROUTE XEQ is not supported because of conflicts with the JES2 /*ROUTE XEQ statement.
3.2 JES2-only functions
Several functions and features are unique to JES2 or behave differently in JES3. In this section, we describe some of these functions.
3.2.1 Job correlator
The job correlator (JOBCORR) is a 64-byte token that uniquely identifies a job to JES. The JOBCORR value is composed of a 32-byte system portion, which ensures a unique value, and a 32-byte user portion, which helps identify the job to the system. The UJOBCORR parameter of the JOB card specifies this 32-byte user portion of the job correlator. This job correlator provides the following features:
•Provides a larger name space for jobs (in addition to classical job name).
•Helps relating jobs to output and other records.
•Provides a simple way for applications to determine the Job ID of a job that was submitted.
•Is available with the z/OSMF REST API.
The UJOBCORR value can be overridden when the job is submitted by using the appropriate JES2 exits.
The job correlator is used to identify the job in multiple interfaces, including:
•JES operator commands
•ENF messaging
•Subsystem interfaces such as extended status and SAPI
•SMF records
In the following example, the user portion of the job correlator is set to JMAN_COMPILE:
//TEST JOB 333,STEVE,UJOBCORR=’JMAN_COMPILE’
Later, this value is combined with the system portion of the correlator to form a job correlator similar to the following example:
J0000025NODE1...C910E4EC.......:JMAN_COMPILE
|<-system portion----------------------->||<-user portion--------------->
In JES3 environments, this UJOBCORR parameter is accepted but ignored.
3.2.2 SPOOL migration
SPOOL migration allows an installation to quickly move data off a SPOOL volume in a period of minutes, instead of the days that a drain command takes. The processing can be done with active address spaces still accessing the volume.
The goal of the command is to get the source data set moved to a new volume or merged onto an existing SPOOL volume. The internal representation of the volume remains after it is merged onto an existing volume and persists until all jobs that were using the volume are purged. The volume continues to be displayed in $D SPOOL commands and in the volume list of a $DJQ,SPOOL command. The status of the “remnant” volume becomes MAPPED.
The two forms of SPOOL migration are MOVE and MERGE. In a move migration, the JES2 takes one INACTIVE SPOOL volume and moves it to a new volume that is not part of the SPOOL configuration. If three SPOOL volumes are available before a move, the JES2 continues with three SPOOL volumes after the move.
For a move, the source volume must be INACTIVE (HALTED). A merge migration takes the data on a SPOOL volume (in any state) and merges in into contiguous space on a target volume. If a merge starts with three volumes before the merge, it ends up with two volumes after the merge.
The third volume is displayed, but it is not being used (it is considered mapped). Merge is the least restrictive process. Any source volume can be merged to an appropriate target volume.
3.2.3 Encrypting and compressing spool data sets
Customer-sensitive data must be handled carefully to meet the demands of a secure world. IBM introduced in z/OS 2.3 DFSMS the capability to encrypt MVS data sets with no change to the applications. This support did not address spool data sets that can also contain sensitive data. In z/OS 2.4, JES2 can encrypt spool data sets by using z System hardware without application changes.
The data sets that are encrypted are also compressed, which provides storage efficiency at the same time. With this function, you can encrypt in stream and sysout data sets that are on spool.
This function also provides the capability to compress spool data sets without encrypting them.
3.2.4 JES2 Policies
Many installations must customize their JES2 system to achieve their requirements. These customizations involve coding JES2 exits that use the Assembler language. It also requires detailed knowledge of JES2 processing flow and control blocks.
In z/OS 2.4, JES2 introduces JES2 policies, which are a way to customize JES2 processing without the need to code exits. It is an alternative method to customize JES2 processing. Creating policies does not require programming skills. Customers formulate the required customizing in high-level terms that are based on the job requirements and attributes. JES2 policies do not replace JES2 exits that are still supported.
Multiple types of JES2 policies are available; however, this support was introduced in z/OS 2.4 and the initial support contemplates only some policy types. Many more types will be supported in the future as the function evolves.
3.2.5 Instruction Execution Protection
Instruction Execution Protection (IEP) is a feature of the IBM z14® hardware. It allows storage to be allocate storage in a non-executable state. This feature helps to protect systems from errors, such as stack overflows and malicious attacks.
JES2 uses this feature by changing the default behavior of the $GETMAIN macro. The default behavior in z/OS 2.3 was EXECUTABLE=YES. With z/OS 2.4, the default is EXECUTABLE=NO. This default can change the way some code that is written by users or vendors behaves; when code attempts to run inside storage allocated with this service, a program check occurs.
By using this service, JES2 assists in keeping systems more secure. If you upgrade to z/OS 2.4 and you are running on hardware previous to z14, JES2 continues to function the way it does with previous releases.
3.2.6 z/OSMF asynchronous job notifications
The z/OS jobs REST interface provides a set of REST services that allow a HTTP client application to perform operations with batch jobs and receive synchronous job notifications on a z/OS system. Through the z/OS jobs REST interface services, an application can perform the following tasks:
•Obtain the status of a job
•List the jobs for an owner, prefix, or job ID
•List the spool files for a job
•Retrieve the contents of a job spool file
•Submit a job to run on z/OS
•Cancel a job
•Change the job class
•Delete a job (cancel a job and purge its output)
The z/OS jobs REST interface services can be started by any HTTP client application that is running on the z/OS local system or a remote system (z/OS or non-z/OS). The z/OS jobs REST interface services are described in IBM z/OS Management Facility Programming Guide.
You can use the asynchronous job notifications function of z/OSMF to allow your programs to be notified when submitted jobs complete. With this function, the program that submits the job through the z/OS jobs REST interface services PUT method specifies a URL when submitting the job. When the job ends, z/OSMF returns an HTTP message to the URL location, indicating the job completion status. The data returned is in the form of a JSON document.
The key requirement is that you must create a subscription to the Common Information Model (CIM) jobs indication provider for your system. Also, if the job notifications require a secure network connection, you must enable an SSL connection between the client application and the server, including the sharing of digital certificates.
3.3 JES3-only functions
In this section, we describe JES3 functions and features that are unique to JES3 and are not available in JES2. Most of these functions are directly related to the way JES3 manages jobs.
3.3.1 Data Set Name disposition conflict resolution
JES3 resolves Data Set Name (DSN) conflicts before running a job. Consider the following sequence of conditions:
1. A job is submitted and requests access to a data set that is inconsistent with another job that uses that data set.
2. The newly submitted job is not selected for execution until the data set is freed by the running job.
3. Meanwhile, the job is placed in the JES3 allocation queue.
For example, if the new job requests exclusive access to a data set (DISP=OLD or DISP=MOD), and that data set is in use by another job, the new job does not start running.
Operators can display the JES3 queues by entering an *I S command. If jobs are in the allocation queue, you can determine why they are in the queue by entering a form of the *I S A J=nnnn command.
During job execution, a job might request allocation of a data set that is in use. In this case, the behavior of the JESs is the same and you receive messages similar to the messages that are shown in Example 3-1.
Example 3-1 Messages issued for data set enqueue conflict
IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO jobname
IEF863I DSN = data.set.name jobname RC = 04 RSN = 00000000 FROM SERVICE ENQ
IEF099I JOB jobname WAITING FOR DATA SETS
In JES2, the data set needs of a job are not considered when JES2 decides whether a job is selected for execution. As a result, conflicting data set enqueue and the “waiting for data set” message can occur more often.
However, you can use the JCL parameter DSENQSHR on JOB statement with the DSENQSHR subparameter of JOBCLASS definition. These parameters control how the system manages changes in data set disposition between job steps. In this way, you reduce control from exclusive to shared, which allows access by other jobs.
3.3.2 Spool partitioning
The JES3 spool can be divided into partitions that can be assigned to job classes, SYSOUT classes, or by user exit decision that is based on specific job characteristics. These partitions reserve spool space for important jobs processes.
To JES2, the spool is considered as a large repository space to hold the job data (input stream, SYSIN, and SYSOUT data set). This space can be used for any user who is authorized to process jobs. The spool partitioning on JES2 can be used as a way to assign specific spool volumes by creating a mask for users and the number of volumes on the FENCE parameter of the SPOOLDEF statement.
For this reason, to implement spool partitioning process on JES2, use the exits 11 and 12 to identify and control the spool volumes that a job can use. For more information, see Appendix E, “SPOOL partitioning exits sample code” on page 233.
Also, JES2 features a new enhancement for reserved spool space that is called privileged space that can be used for recovery purposes.
3.3.3 Job class group
A job class group is a named set of resource assignment rules to be applied to a group of job classes. System programmers define job class groups on JES3 initialization statements. They establish a link between a job class group and a job class by specifying a job class group name when they define the job classes. The job class group definitions in the initialization deck provide information about the resources that can be used by the set of jobs that is running.
The definition of job class group in JES2 is used to avoid the association of many 2 - 8 character job class names with a single initiator or a device. Then, you can create job class groups to manage these associations. In a manner similar to placing NJE nodes in SUBNETs, job classes can be defined to a job class group. Consider the following points:
•A job class can be in one job class group only, or in no job class group.
•A job class group is created when the first job class is added to the group.
•A job class group is deleted when the last job class is removed from the group.
•Deleting a job class also deletes the job class from its job class group.
•The maximum number of job class groups is 512 (in which case each group contains one job class).
•Job class group names must be unique, must range 2 - 8 alphanumeric characters, and must not match any existing job class name.
3.3.4 Printer naming conventions usage
JES3 does not restrict printer naming conventions. However, you must follow conventions in JES2 in assigning names to your printers. As a result, printer names in JES3 might be more meaningful to a human, but are not acceptable in JES2.
You might circumvent this issue by using JES2 destination IDs that match your old printer names. This issue probably has more effect on the operators because they must become familiar with the new printer names.
However, the output in JES3 is routed to writers that are then processed by printers. In JES2, output is routed to destinations and then printers select output that is associated with one or more destinations.
3.3.5 Main Device Scheduling
Main Device Scheduling (MDS) does not have much effect because all DASD volumes are always mounted and the tape drives are mostly virtual units. Nonetheless, JES3 provides the MDS feature to verify that all the resources (devices, volumes, and data sets) that are needed by a job are available before that job is executed. MDS can be disabled at a system level by using SETUP=NONE. It can still be overridden in jobs that specify //*MAIN SETUP= in their JCL.
Pre-execution setup
Pre-execution setup (JOB setup) is the basic feature of JES3 for pre-allocation of all devices, including DASD and tapes. JOB setup reserves all devices and mounts all volumes that are needed by a job before job execution.
Job setup can be requested on a job-by-job basis by specifying SETUP=JOB on the //*MAIN statement or on the JES3 initialization statement STANDARDS. SETUP=JOB is the default setting for the STANDARDS statement. Also, the resources are reserved from a JES3 setup perspective only. No ENQs or RESERVEs are issued.
For more information about MDS, see the chapter that is titled, “Main Device Scheduling”, in ABCs of z/OS System Programming Volume 13, SG24-7717.
Job setup also performs data set awareness. It prevents an initiator from being assigned if data set allocation conflicts exist. For more information, see 3.3.1, “Data Set Name disposition conflict resolution” on page 34.
The data set awareness feature is significant benefit in JES3, especially if you limit the initiators to a group. The feature stops a job from using an initiator and then waiting for data sets.
High water mark setup
The high water mark setup feature reduces the number of resources that are reserved for a job. The feature determines the maximum (or high water mark) number of devices that are used by any step in the job.
Consider the tape-drive requirements for the following example job that features three steps:
•Step One: Two tape drives
•Step Two: Three tape drives
•Step Three: One tape drive
This job reserves (or allocates) a total of three tape drives for the job because the maximum number of tape drives that is used by the job is three.
Without the high water mark setup feature, JES3 might attempt to allocate the total of six devices for the job. This allocation likely is not what was intended because JES3 views those devices as being unavailable to other jobs. This issue might by especially important for a long-running job in which only the last step requires many drives.
JES2 does not provide functions that are equivalent to MDS. You must take action before any migration to JES2 to eliminate use of JES3’s MDS features. It is likely that if you do use MDS, it is only used for tape.
If you use tape virtualization, it is reasonable to assume that you have more virtual tape drives than you ever use at one time. Therefore, disabling MDS probably has no visible effect on job throughput. Nevertheless, it is prudent to make this change before the migration. That way, if it does cause a problem, you can re-enable MDS while you investigate ways to address the problem.
3.3.6 JES3 device control and device fencing
The original default was for JES3 to control device allocation, including tape and DASD. Device fencing (also known as device pooling) was used to isolate or reserve a certain set of devices for a certain set of jobs or groups. For example, device fencing might ensure that a certain group of jobs uses DASD at a remote location only.
For DASD device allocation, it is now recommended to remove all devices from JES3 management by removing their definition from the JES3 Inish deck. This feature was most commonly used for tape drive allocations. However, with the combination of SMS-managed tape and tape virtualization, this issue is now less of a concern. Many customers no longer use JES3 to control their tape allocations.
You might be using JES3 MDS to control where a specific job is executed. For example, you might have a volume that contains a product that is licensed to only one system at a time. In this case, you can vary the volume online by using an operator command to only one system in the JESPlex and JES3 directs the job to that specific system. You can use Scheduling Environment to achieve the same effect in JES2.
Similar to member affinity, a job might be assigned a scheduling environment to ensure that it executes on specific members in the MAS. Use the SCHENV= keyword parameter on the JOB statement, or use the $T Job JES2 command.
Scheduling environments are installation-defined, 16-character names that might be available on any of the z/OS systems in the sysplex, or on none of the systems. Use workload management to define the scheduling environments and make them available or unavailable on each system based on the ON or OFF state of their resources.
Defining SCHENV for JES2
To get the JES3 job execution control based on specific resources in JES2, you can use the WLM Scheduling Environment function. With Scheduling Environment, you can control job execution based on resources and direct work to specific z/OS images where these resources are available.
Consider the following example:
•You implemented the utilization of a DUMMY data set in JES3.
•You set DISP=OLD to serialize the execution of jobs (JES3 does not select a job if one of the resources that are required by the job is not available).
In this case, you can instead use Scheduling Environment in JES2 to accomplish the same objective.
The following example shows how to create, in JES2, the environment to perform the same serialization that JES3 does. We select JOBCLASS B to be the class that is used by the jobs to be serialized. We associate to this class the DD_DUMMY Scheduling Environment and restrict the number of WLM initiated initiators to one.
The following example uses only JES2 and WLM definitions. No special code or exits are required.
Figure 3-5 shows the WLM Definition Menu that is used to select the WLM definition that must be performed. In our case, we must define the Scheduling Environment. Select option 10 in the menu.
Figure 3-5 Accessing the WLM Definition Menu
After you select the Scheduling Environments option, a new panel is displayed with all Scheduling Environments that are defined in the WLM policy. From this panel, you can select any element from the list and use option 1=Create to create a new Scheduling Environment, as shown in Figure 3-6.
Figure 3-6 WLM panel to create a Scheduling Environment
After you create your Scheduling Environment (as shown in Figure 3-7), you must create a resource that is associated with this Scheduling Environment. In this example, the Resource Name that is defined features the same name as the Scheduling Environment.
Figure 3-7 Creating the DD_DUMMY Scheduling Environment with DD_DUMMY resource
The Schedule Environment DD_DUMMY is created, as shown in Example 3-8.
Figure 3-8 DD_DUMMY Scheduling Environment is created
After the Scheduling Environment is successfully created, you must save the new policy into the WLM couple data set so that it is activated by the operator, as shown on Figure 3-9.
Figure 3-9 Installing the new definition on WLM couple data set
The activation of the WLM policy is done by issuing the Vary WLM,POLICY= operator’s command from system console or SDSF panel, as shown in Figure 3-10.
Figure 3-10 Activating the new definitions to WLM
By using the SDSF SE - Scheduling Environment panel (see Figure 3-11), you can display all Scheduling Environments that are defined for this Sysplex, and in which systems the Scheduling Environment is available.
Figure 3-11 SDSF SE panel showing the defined Scheduling Environments
When the Scheduling Environment is defined or after an IPL, the resources are not available on any system in the sysplex and they must be activated. The initial status of the scheduling environments is shown in Figure 3-11.
You activate a resource that is associated to a Scheduling Environment by issuing the Modify WLM,RESOURCE= operator’s command, as shown the Figure 3-12.
Figure 3-12 Setting a resource that is associated to Scheduling Environment to ON
After the resource that is associated with the Scheduling Environment is activated on a system, it becomes available in that system. The jobs that are defined to that SCHENV can be selected by WLM to be executed in that z/OS image. The SDSF SE panel with the SCHENV=DD_DUMMY now available on system SC74 is shown in Figure 3-13.
Figure 3-13 SDSF SE panel displaying the Scheduling Environment available on system SC74
Consider a scenario in which you want to create an environment where only one job can be executed at a time. In addition to the Scheduling Environment creation, you must associate a specific job execution class to that Scheduling Environment (in our case, class B). You also must set the maximum number of jobs that can execute in the class to 1, as shown in Figure 3-14. The JOBCLASS(B) is set to MODE=WLM, SCHENV=DD_DUMMY and the XEQCOUNT=(MAXIMUM=1).
Figure 3-14 Results of command $DJOBCLASS(B) showing the class that is associated to SCHENV
You can also use the same approach to direct JOBs to a specific z/OS image (for accounting purposes) and this JOBs uses a specific volume. In JES3, you can vary that volume online to that system only.
In JES2, you can associate those JOBs to a specific Schedule Environment and activate the resources of that environment in one z/OS image only (as we did for DD_DUMMY). In this situation, the initiator that handles the class can have XEQCOUNT=(MAXIMUM=) greater than 1.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.