Sg248427 - A Guide To JES3 To JES2 Migration
Sg248427 - A Guide To JES3 To JES2 Migration
Sg248427 - A Guide To JES3 To JES2 Migration
Luiz Fadel
Lutz Kuehner
Ricardo Paranhos
Redbooks
International Technical Support Organization
November 2019
SG24-8427-01
Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.
This edition applies to version 2 release 4 of IBM z/OS (product number 5650-ZOS) and to all
subsequent releases and modifications until otherwise indicated in new editions.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Contents v
Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
This information was developed for products and services offered in the US. This material might be available
from IBM in other languages. However, you may be required to own a copy of the product or product version in
that language in order to access it.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user’s responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, MD-NC119, Armonk, NY 10504-1785, US
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without
incurring any obligation to you.
The performance data and client examples cited are presented for illustrative purposes only. Actual
performance results may vary depending on specific configurations and operating conditions.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
Statements regarding IBM’s future direction or intent are subject to change or withdrawal without notice, and
represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to actual people or business enterprises is entirely
coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are
provided “AS IS”, without warranty of any kind. IBM shall not be liable for any damages arising out of your use
of the sample programs.
The following terms are trademarks or registered trademarks of International Business Machines Corporation,
and might also be trademarks or registered trademarks in other countries.
CICS® IBM z14® System z®
Db2® MVS™ Tivoli®
GDPS® Parallel Sysplex® VTAM®
IBM® RACF® z Systems®
IBM Z® Redbooks® z/OS®
IBM z Systems® Redbooks (logo) ® z13®
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
This IBM® Redbooks® publication provides information to help clients that have JES3 and
want to migrate to JES2. It provides a comprehensive list of the differences between the two
job entry subsystems and provides information to help you determine the migration effort and
actions.
This book considers the features of JES2 as available on releases of IBM z/OS® V2R3 and
V2R4. It should be used with JES3 to JES2 Migration Considerations, SG24-8083.
Authors
This book was produced by a team of specialists from around the world working at the
International Technical Support Organization, Poughkeepsie Center.
Luiz Fadel is a consultant for Maffei Consultoria em Informatica Ltda. He retired from IBM in
2013 as an IBM Distinguished Engineer, responsible for supporting IBM System z® for the
Latin America region, part of the Growth Markets Unit. He joined IBM in 1969 and has
supported large systems since then, including working on two assignments with the
International Technical Support Organization (ITSO). He was a member of the zChampions
team and the co-author of several IBM Redbooks publications.
Lutz Kuehner is a Senior z/OS System Engineer at Credit Suisse in Switzerland. He has 33
years of experience in IBM z Systems®. Lutz has worked for 10 years in the IBM Z® Presales
support in Germany, developing and providing professional services for customers in the
financial market. In addition to co-authoring several IBM Redbooks publications since 2001,
he has been an official ITSO presenter at ITSO workshops.
Ricardo Paranhos is a Senior z/OS System Programmer at IBM Brazil. He has 30 years of
experience in IBM z Systems acting as Solution Architect for z/OS projects and z/OS support.
He holds a degree in Electrical Engineer and Bacherol of System Analysis. He is a member of
IBM Academic Initiative program since 2014. His areas of expertise include z/OS System
Performance and Capacity Planning, IBM Parallel Sysplex® environment, DFSMS, and
Legacy Modernization. He has developed some utilities for users that are available on the
CBTTAPE site.
Yves Colliard
YCOS GmbH Germany
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an email to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface xi
xii A Guide to JES3 to JES2 Migration
Part 1
In this part, we cover the information that you need to help plan and manage your own
migration.
Perhaps one of your first questions is: “Why would an enterprise want to convert to a different
job entry subsystem”? You might be considering such a move for the following reasons:
JES3 has few new functions; JES2 features many enhancements.
You might have both JES3 and JES2 and want to have consistent JCL and procedures
across all your z/OS systems.
Because more JES2 installations exist than JES3 installations, it might be easier in your
area to find personnel with JES2 experience.
It is possible that products you want to use do not support JES3.
Perhaps a certain product is better tested with JES2.
You might find that JES3 includes features that you no longer use.
New functions often appear in JES2 before they appear in JES3, and you want to remain
current in your product levels.
You performed a financial analysis and found that costs might be reduced by consolidating
systems and converting them to JES2.
You are working to improve your availability and JES2 appears to provide more flexibility to
make dynamic changes than JES3.
This book helps you identify what the migration effort entails. For some JES3 installations, the
migration might be relatively easy, but for others, it is time-consuming and complex. It
depends on the extent to which you use the capabilities that are unique to JES3.
Even if you are not considering migrating to JES2, it is a good idea to ensure that any new
applications or new jobs avoid the use of facilities that are unique to a particular Job Entry
Subsystem (JES).
Most enterprises take several years to deliberate over whether they perform the migration.
During that time, you might be creating many more issues that then must be addressed as
part of the migration.
In the opinion of the authors, it is a good investment of your time to put tools, documentation,
and education in place now to ensure that your users (including operators, production
schedulers, application developers, and system programmers) stop using mechanisms that
are unique to JES3. If you have JES2 and JES3 today, it is worth considering to stop using
mechanisms that are unique to any JES.
We highlight changes throughout this book that can be made now that will not affect current
operations under JES3, but that make the migration easier if you decide to go down that path.
As of the time of this writing, IBM announced its directions related to JES3 future. For more
information, see this web page.
This chapter presents arguments for technical professionals and managers about why JES2
is a better option than JES3 not only because of financial issues (JES3 requires another
license fee and JES2 does not), but because most JES3 customers successfully migrated to
JES2. It also shows that the migration process can be easy and low risk.
In the early days of JES2 and JES3, the differences between the two were more obvious than
they are today. JES3 was originally developed to assist installations that needed to manage
multiple IBM MVS™ images. However, JES2 is used by most z/OS customers and became
nearly a superset of JES3 functionality.
Today, JES3 functions, such as multi-system consoles, automatic tape sharing, dynamic
initiators, and workload balancing, can be provided by the operating system. Therefore, they
are available to installations that run JES2. This difference has left some JES3 installations
wondering whether the premium they pay in licensing fees to run JES3 is still worthwhile.
Also, with the challenges for the use of integrated technologies and digital transformation,
JES2 and JES3 must provide functionality, such as high availability, fault toleration, or digital
integration capabilities with new environments.
For this reason, when JES2 is configured as a Multi Access Spool (MAS, also called
JESPlex), all members can monitor and continue processing after one sysplex member fails.
A JES2 MAS and a JES3 JESPLEX must be entirely contained within one sysplex.
Since z/OS 2.3, the measurements and monitoring of JES2 key resources can be done and
made available to the user by using commands or reporting mechanisms. This feature can
help in reducing or eliminating resource exhaustion in JES2.
Reserved space can be set aside for use in recovering the environment when resources are
nearing exhaustion. Thresholds can be set and alerts issued well before resources are
exhausted and a possible outage occurs.
Any member can join or leave an MAS at any time without affecting other members. Every
MAS is defined as having 32 members, even if only one member exists. Members do not have
to be predefined before starting. A new member can define itself to a MAS as part of its
initialization.
One implication of this processing is that a single system environment does not exist in JES2.
Even when only one member is active, it is considered a single-member MAS. As such, JES2
processing is the same if one or multiple members are in a MAS.
JES2 and JES3 use a single main task to do most of the work that must be done in the JES
address space. In JES2, each member’s main task does the work that is needed by that
member. In JES3, one main task on the global must do the work that is needed by all
members of the JESPlex. This approach can become a bottleneck for processing.
JES2 uses the z/OS cross-system coupling (XCF) services for communicating JES2 member
status and other data among the JES2 XCF group members in a MAS configuration. Each
member of a JES2 MAS starts independently, joining the JESXCF XCF group and uses group
and member information from the initialization deck. This policy exists to inform any other
MAS members of its existence and to open a communication path to other members. All
members of a MAS must be contained within the same sysplex.
Members in the JESXCF group can communicate with each other by using z/OS XCF
services. For example, this communication allows a members of the group to obtain access to
the checkpoint data set lock and read the checkpoint into memory and process it.
Checkpointing is the periodic copying of a member’s in-storage job and output queues to the
checkpoint data set, which can be on a DASD volume or a coupling facility structure.
Checkpointing ensures that information about a member’s in-storage job and output queues
is not lost if the member loses access to these queues. Loss of access might result from
hardware or software errors. Because all members in a JES2 MAS configuration operate in a
loosely coupled manner, each member can select work from the same job and output
queues.
In a MAS environment, the checkpoint data set backs up the job and output queues and links
all members. It is the commonly accessible repository of member activity that allows each
member to communicate and be aware of the current workload.
The checkpoint data set contains a record of member values that describe the overall
configuration of the MAS environment and specific characteristics and information that
describes the status of each member. The checkpoint allows all members to access and
update (write to) the checkpoint data set. It also allows all members to refresh their in-storage
queues by reading from the checkpoint data set.
Because checkpoint is the JES2 component that contains the major JES2 data areas, it
requires short access times and specific capabilities for automatic recovery in case of failure.
Checkpoint reconfiguration
The checkpoint reconfiguration facility allows the dynamic redefinition of the checkpoint data
set definitions for the JES2 multi-access spool (MAS) configuration. The reconfiguration
allows the installation to perform the following tasks:
Replace a checkpoint data set.
Discontinue the use of a checkpoint data set.
Resume the use of a previously suspended checkpoint data set.
Start the use of a new checkpoint data set.
It also ensures that no data is lost if a checkpoint error occurs. Data is written from data in
memory and from the member that has the most recent CKPT, which ensures currency. For
CKPT on CF, you can use the XCF rebuild function to move from one CF to another. With
JES2 reconfiguration, you can move from CF to DASD or vice versa.
Also, the JES2 can automatically start a reformat reconfiguration function that is internally
triggered if a CKPT data error is detected. It reformats the CKPT with current checkpoint data
and does not change what data sets (structures) are being used.
The check runs by intervals and can detect issues that might arise over time, such as the
amount of space that is available on the backup checkpoint volume becoming insufficient to
hold a backup checkpoint. It is refreshed automatically when checkpoint settings are changed
by a $T CKPTDEF operator’s command or by the checkpoint reconfiguration dialogue.
Precisely because JES2 is an essential component for all z/OS processing, one of the most
unwanted situations is for the spool space to be exhausted. This condition affects all systems.
In z/OS 2.3, JES2 spool management can reserve spool space to deal with resource
exhaustion. Approximately 1% of spool space is reserved by JES2 for the following items:
Spool resources
Jobs queue elements (JQEs)
Job output elements (JOEs)
Block extension reuse tables (BERTs)
This “privileged space” is sufficient to allow a user to perform the following functions:
Log on to the system
Submit jobs
Resolve causes of exhaustion
With this emergency subsystem, a privileged TSO user ID can be logged on through
SUBSYS(xxxx) by using the TSO LOGON command. This user account removes the cause of
exhaustion, with no outage during the return to normal processing.
The initialization data set checker allows installations to verify their initialization data sets
without having to start a JES2 subsystem. The process can detect syntax errors in
initialization statements and problems with settings that might prevent JES2 from starting.
This initialization data set checker can avoid outages that are caused by JES2 initialization
failure because of initialization parameters errors. The initialization data set checker analyzes
to see whether current specifications are reasonable and no errors are found.
The initialization data set checker is useful to test some initialization exits that run during
JES2 initialization. The initialization data set checker loads all installation modules that are
specified by using a LOAD(module-name) initialization statement.
This approach allows exits to define and process any installation- or vendor-defined
initialization statements. Because the checker is not starting a JES2 subsystems, all modules
are loaded in private storage (even if the LOAD statement specifies common storage). The
normal JES2 initialization exits (0, 19, and 24) are called to perform any validation processing
that might be needed.
It is also intended to ease applications that can analyze JCL while it is being submitted and
break down the steps into separate, dependent jobs. This function helps users that are
running JES3 and JES2 by providing similar functions as the JES3 dependent job control
(DJC) in the JES2 environment.
The principal entity that controls job execution within JEC is a job group. A job group is
defined by the JOBGROUP JCL statement.
In some job scheduling software, these keywords can be set dynamically by the software
when the specified internal processing conditions are met. This software uses its own job
editor processing to change the sequence or name of scheduled jobs into a JOBGROUP.
By using this context, production teams can create complex job scheduling, such as calendar
dates, time spans, and conditions for job completion.
It is also possible to define how JES2 Input Processor handles JES3 JECL statements. If you
allow JES2 to process JES3 JECL, the conversion of JES3 job streams that use Dependent
Job Control (DJC) can be minimized or even avoided. JES2 Input Processing creates a
JOBGROUP and adds all jobs in the same NETID to this group.
Separating email processing by using these stages allows JES2 to accept email messages,
even if the environment does not allow immediate delivery of the email; for example, TCP/IP
services are not available or the email server is not accessible. In addition, this separation
helps to protect accepted email messages from system failure.
Most of JES2 EDS processing is performed in a separate address space. The name of the
address space uses the format <subsystem>EDS, where <subsystem> is a subsystem name
that is used by JES2. For example, if the subsystem name is JESA, the address space name
is JESAEDS.
The following main functions are provided by JES2 EDS address space:
Accepts email messages and saves on JES2 SPOOL.
Reads email messages from JES2 SPOOL and sends them to intended recipient.
JES2 EDS accepts email messages and stores them in the JES2 SPOOL on any JES2 MAS
member. No extra z/OS functions are required for that stage of email processing.
To deliver email messages, JES2 EDS relies on the services that are provided by z/OSMF.
The z/OSMF server does not have to be active on the same SYSPLEX member. All MAS
members can access the same z/OSMF server active anywhere in the SYSPLEX if
communication to the z/OSMF server is possible.
JES2 provides a basic level of security for some of these resources through initialization
statements. For example, each node in a network can be defined as having a certain level of
control over work at each of the other nodes in the system. This level of control can give one
operator limited control over each of the other nodes.
NJE encryption
Because the NJE connection is available over TCP/IP, most installations use this option
without any security mechanism as SSL or AT-TLS to encrypt the data that is transferred
between nodes.
SSL and TLS provide excellent security, from a TCP/IP standpoint. These protocols encrypt
data on unsecure links and ensure that the peer node at the other end of the connection is
who it claims to be from a TCP/IP standpoint.
However, from an NJE standpoint, you might need more security to ensure that the peer node
is who it claims to be. You can specify NODE and LINE parameters for connections, but these
passwords are exchanged in clear text in sign-on records. They might be compromised if they
are sent into an unsecure network.
With this option, the NJE traffic over TCP/IP connections can be secure and the data is
protected, including the use of a virtual private network between the NJE nodes.
The JES2 can encrypt a particular line (in which case everything that is sent on that line is
encrypted) or a particular transmission. End-to-end encryption is the process of encrypting a
telecommunication line. When you use TCP/IP for performing NJE, you can define a policy
agent for the network and exchange digital certificates between nodes that are in network.
SPOOL encryption
Starting with z/OS 2.4, JES2 includes a function to encrypt and compress spool data, which
improves security on sensitive information and reduces the storage requirements. The
compression also can improve the performance of managing the data.
The spool data is encrypted by using the z Systems hardware encryption through existing
policy management (without application changes to the programs) by defining a record in the
CKDS data set that can be identified and accessed by using a 64 character key label.
The JCL parameter DSKEYLBL or JESJOBS class profiles can be used to identify selective
SYSOUT and in-stream data sets to be encrypted. Data to be encrypted first is compressed,
which provides storage efficiency.
The use of passphrase for user authentication on a JCL JOB card is accepted by JES2 as an
extra security mechanism and compatibility between platforms. The keyword PASSWORD=
on job card supports pass phrase. Consider the following points:
If the data in the password field is 1 - 8 characters, it is considered as a password.
If the data in the password field is 9 - 100 characters, it is considered as a passphrase.
However, for a system that has multiple processors, noticeable differences exist in how JES2
exercises independent control over its job processing functions. Each JES2 processor
controls its own job input, job scheduling, and job output processing. In contrast, JES3
exercises centralized control over its processing functions through a single global JES3
processor.
SMF84 record
Record type 84 contains information that is collected by JES2 or JES3 monitors. This record
is intended to provide insights into what the subsystems are doing during the interval the
record represents.
In JES3, the information is collected by the JES3 monitoring facility (JMF). When JMF is
called with the SMF option selected, these records are generated for each JMF interval. SMF
records can be produced on the global and local processors.
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 (subtype 21) can be used for real-time management of JES2 memory
resource usage. The record provides information for the following areas:
The memory usage contains information about each memory section in the JES2 address
space.
The resource usage contains information about various resources JES2 manages.
The activation of this support can be done at two levels: first, it gives the ability to handle the
JES3 JECL syntax as JECL and not a comment; second, it gives control over how each JECL
statement is processed.
JES2 includes support for the primary (//*) and alternative (/*) prefix for JES3 JECL, except to
//*ROUTE XEQ that does not support the alternative /*ROUTE XEQ syntax because of
conflicts with the JES2 /*ROUTE XEQ statement.
This section brings all of these cases together to help avoid confusion as you read the
remainder of this book.
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.
Regardless of the type of start, JES2 always reads its parameters from the PDS 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.
Note: On the system that is performing the cold start, you must take one of the
following actions:
Perform an IPL.
Completely stop JES2 and then restart it and specify that it performs a cold start.
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.
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 be associated with this member from a previous instance
is 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 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:
– Was shut down cleanly by using a $P JES2 command
– Is starting after an all-member warm or cold start
– Had its work reset by using a $E MEMBER command or through 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. 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.
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 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.
Note: When working with a secondary subsystem, all start options are available and
affect only the secondary subsystem without any effect on the primary JES2
subsystem.
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.
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.
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.
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.
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.
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.
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.
The checkpoint checker display is shown in Figure 3-3. The current status of the checker is
the exception.
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.
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.
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).
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.
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
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.
With this support, you can send a set of jobs to a node and have them processed by input
processing in the correct order.
The UJOBCORR value can be overridden when the job is submitted by using the appropriate
JES2 exits.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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-7 Creating the DD_DUMMY Scheduling Environment with DD_DUMMY resource
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.
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-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.
This IBM Redbooks publication covers JES2 features that were included in JES2 that helps to
decrease these differences. For more information about JECL and JCL the differences
between the languages before z/OS V2.2, see JES3 to JES2 Migration Considerations,
SG24-8083.
JEC provides simple controls that can facilitate breaking down jobs into their constituent
parts. That is, taking a multistep job and breaking it into multiple separate but related jobs.
When these jobs are submitted, JES2 manages their execution in the correct order.
Also, by using JEC, you can define a set of two or more jobs for simultaneous execution.
These jobs run in parallel on the same z/OS image. This function helps users that are running
JES3 and JES2 by providing similar functions as the JES3 dependent job control (DJC) in the
JES2 environment.
The principal entity that controls job execution within JEC is a job group. A job group is
defined by a JOBGROUP JCL statement.
Note: The job group definition defines the dependencies between the jobs only. The
constituent jobs are defined separately by a traditional JCL statement.
The definition of a job group is static. Jobs cannot be added and dependencies cannot be
changed after the job group is defined.
A job group includes a job group logging job that is associated with it. This job is a special
type of job that acts as the front end for the job group. It serves the following purposes:
The JESJCLIN data set of the logging job includes statements that are used to define the
job group.
The job log data set (JESMSGLG) contains messages about important events that are
related to the jobs in the job group and to transitions in the job group state. For example, a
message is logged when the job group completes, when each job starts, completes, and
then is flushed.
The logging job is used as a front end for the job group by the commands that act on the
group (hold, cancel, and purge).
The logging job is used as a front end for the job group by the extended status subsystem
interface (SSI) and the job modify SSI. It is used for filtering, and so on.
After a job group is instantiated, jobs can then register to it through the SCHEDULE JCL
statement. Any JES2 batch job can be registered to a job group. These concepts are shown
in Example 4-1.
When this JCL is submitted, JES2 instantiates job group TESTE1 in the JES2 checkpoint. A
logging job with the name TESTE1 is also created. Notice that no jobs are registered to the
group at this point.
The SCHEDULE JCL statement is used to register (associate) jobs with the job group (see
Example 4-2).
The SCHEDULE JCL must follow the JOB statement before the first EXEC statement. A JCL
error is generated if it is misplaced.
After the JCL for a job with a SCHEDULE statement is successfully processed, the job is
registered to the job group that is named on the JOBGROUP keyword. Jobs that are defined
as part of a job group can be submitted in any order. However, you must submit them after the
JCL of the job group is processed and the job group definition is committed to the JES2
checkpoint.
The job group owns certain resources and is authenticated by using the same process as
normal batch jobs. This authentication includes checking profiles, such as the JESJOBS
SUBMIT profile.
When a batch job is submitted that is registered to a job group, a check is made while the job
is converting to validate the jobs access to the job group. If the user ID that owns the job
group is the same as the user ID that owns the batch job, no other validation is performed
(that is, no profiles are checked). If the user IDs are not the same, a check for authentication
is made.
For more information about JOBGROUPs examples, see Appendix D, “DJC conversion and
JEC examples” on page 225.
Use of JOBSET
JOBSET is a convenient method to define jobs with the same set of dependencies within a
JOBGROUP. In the example that is shown in Figure 4-1 on page 47, TEST3, TEST4, and
TEST5 share dependencies.
All references to the set are made by using the set name (SET1).
CONCURRENT statement
The CONCURRENT statement denotes that the following jobs must run simultaneously on
the same z/OS image:
The job that is specified by GJOB statement
One or more jobs that are listed in the NAME parameter of the CONCURRENT statement
The jobs that are associated in this manner comprise what is called a concurrent set.
It is important to understand the difference between the following aspects of job execution:
Parallelism that is provided by the CONCURRENT statement
Job-execution parallelism that is provided by the basic job group functionality
For example, consider jobs in a job group that do not have dependencies between them that
are defined by BEFORE and AFTER JCL statements. Such jobs can run in any order on any
z/OS image at the same time or at different times, depending on the operational state of z/OS
images. In contrast to that example, jobs in a concurrent set must run at the same time on the
same z/OS image.
JOBGROUP commands
Various operator commands can be used on the job group after the group is instantiated,
including the following examples:
$CG’MYGROUP’: Cancel a job group and all the jobs that are registered to it.
$PG’MYGROUP’: Purge a job group (if completed) and all jobs that are registered to it.
$HG’MYGROUP’: Hold a job group.
$AG’MYGROUP’: Release a job group.
$TG’MYGROUP’: Change attributes of a job group.
The example that is shown in Example 4-1 on page 45 is simple. The 10 new JCL statements
provide the base that can be used to model complex job relationships.
The job log data set for the logging job shows step-by-step information about the execution
flow of the jobs in the job group. Also, the JOBGROUP commands provide the control and
monitoring functions that are needed to maintain a smoothly running job group.
You can use these features on their own or together with the JEC to further enhance the job
scheduling capabilities of native work management on z/OS.
HOLDUNTL
HOLDUNTL keyword on the SCHEDULE statement tells the system that a job must be
placed in the held state at the submit time and be released at the specified time.
HOLDUNTL specifies the time in one of the following formats:
Interval notation: Some number of hours and minutes from the time the job was submitted
to the system. The syntax HOLDUNTL=’+03:20 means that job must be released 3 hours
and 20 minutes after the submission.
Point In Time Notation: Direct specification of the time and optionally date when a job must
be released. The syntax HOLDUNTL=('13:15',’01/08/2018’) means that job must be
released at 1:15 PM on Aug. 5, 2018.
STARTBY
By using the STARTBY keyword on the SCHEDULE statement, a user can specify an
approximate time in the future to start the job. The system manages the priority of the job so
that the job is near the top of the relevant job class or service class queue by the target time.
In a sense, this function provides a time-controlled alternative to traditional priority aging.
STARTBY syntax is identical to the syntax of the HOLDUNTL function. Target time can be
specified in one of the same two formats: Interval or point-in-time notation.
WITH
Another job scheduling function is provided by the WITH keyword of the SCHEDULE
statement. The WITH keyword indicates that a job must be selected for execution on the
same system where another job (a reference job) is active. Until a reference job becomes
active, the job that uses WITH function cannot be selected for execution.
A reference job does not have to be unique in the JESplex. If multiple jobs with the correct
name are active on different z/OS images, the system chooses one of them. The choice of a
z/OS image is unpredictable.
Two levels of activation for this support are provided. In the first level, the following command
enables the recognition of JES3 JECL syntax as JECL and not as a comment:
$T INPUTDEF,JES3JECL=PROCESS
This command tells JES2 that whenever a JES3 JECL statement is encountered, JES2
attempts to process it directly or by translating it into a JCL or a JES2 JECL statement.
However, if you issue the command $T INPUTDEF,JES3JECL=IGNORE, JES2 ignores all JES3
JECL statements. This option is the default.
The second level controls how each JECL statement is processed, as shown in the following
example:
$T JECLDEF,JES3=(MAIN=PROCESS,DATASET=PROCESS,ROUTE=PROCESS,….)
This function supports the primary (//*) and alternative (/*) prefix for JES3 JECL. However, /*
for NETACCT and ROUTE XEQ defaults to JES2 JECL.
INPUTDEF and JECLDEF feature single-member scope. Therefore, you can apply the same
definition to all MAS members to keep consistent behavior among MAS members.
Also, in a hot start, INPUTDEF and JECLDEF in the initialization deck including defaults
(IGNORE) are used unconditionally. This usage applies, even if you modified INPUTDEF or
JECLDEF by $T commands before JES2 restarts. Therefore, you must define these
statements explicitly in the initialization deck if you want to change the default value
(IGNORE).
Example 4-4 FAIL indicating that specific JES3 JECL statement is not processed
IEFC452I jobname - JOB NOT RUN - JCL ERROR
$HASP106 JOB DELETED BY JES2 OR CANCELLED BY OPERATOR BEFORE EXECUTION
HASP1130 JECL card xxxx encountered
Obsolete means that a warning message is issued (as shown in the following example) and
the keyword is ignored:
HASP1132 Obsolete keyword xxxx ignored
Not supported means that a warning message is issued (as shown in the following example)
and the keyword is ignored:
HASP1133 Unsupported keyword xxxx used
Not supported means that an error message is issued (as shown in the following example)
and the keyword is ignored:
HASP1133 Unsupported keyword xxxx used
Each //*FORMAT statement requires a //OUTPUT statement, which is placed just after the
JOB statement and before the first EXEC statement and created automatically by JES2 as
part of the //*FORMAT JECL processing. The name that is given the OUTPUT statements
uses the format JES2nnnn, where nnnn begins at 0000, as shown in Example 4-8.
Obsolete means that a warning message is issued (as shown in the following example) and
the keyword is ignored:
HASP1132 Obsolete keyword xxxx ignored
You see this message even when obsolete parameters are included with HASP1132.
For more information about DJC, see 6.6, “Transforming JES3 special functions” on
page 143.
PAUSE Not supported, ignored JCL error for JCL error for JCL error for JCL error for
if present //*PAUSE //*PAUSE //*PAUSE //*PAUSE
(IEFC607I)l (IEFC607Il ) (IEFC607Il ) (IEFC607Il )
The sample job specified three JES3 JECLs, as shown in Example 4-10 on page 53. In the
same example, you can see the result of the D GTZ,TRACKDATA command, which includes the
following displayed fields:
OWNER: The string IBMJES2. It identifies the JES2 subsystem as the source of the GTZ
record.
SOURCE: Identifies the JES2 module that identified the occurrence of a JES3 control
statement in the job stream (HASCINJR).
EVENTDATA: Set to zeros.
PROGRAM: Is *UNKNOWN.
PROGRAMOFFSET: Is zeros because JES2 provides no program-specific information.
EVENTDESC: A 46-character string in which JES2 provides information about the job
stream and the JES3 control statement usage within the job stream. The contents of
EVENTDESC by character position are listed in Table 4-2 on page 55.
1 A starting delimiter, which is the vertical bar character “|”, for the JES3 or JES2
JECL control statement usage indicators
2-18 Each character identifies whether a specific JES3 or JES2 JECL control statement
is used in the job stream; Not used (0), Used (1)
2 //*DATASET statement
3 //*FORMAT statement
4 //*MAIN statement
5 //*NET statement
6 //*NETACCT statement
7 //*OPERATOR statement
8 //*PAUSE statement
9 //*PROCESS statement
10 Blank character
11 //*ROUTE statement
13 /*JOBPARM statement
14 /*MESSAGE statement
15 /*OUTPUT statement
16 /*ROUTE statement
17 /*SETUP statement
18 /*XEQ statement
19 /*NETACC statement
20 /*NOTIFY statement
21 Blank character
22 /*XMIT statement
24 Blank character
25-34 JES2 device name for point of entry for the job stream
35 Blank character
44 Blank character
53 Blank character
When enabled, JES2 migrates JES3 //*NET JECL to JES2 JOBGROUPs, called a //*NET
JOBGROUP. Created JOBGROUPs are marked as including a //*NET statement origin that
allows runtime processing to emulate the behavior of JES3 //*NET. However, runtime
behavior differs from standard JOBGROUPs. JOBGROUP name is the NETID= as specified
on the //*NET statement. Name space is shared with traditional JOBGROUPs.
//*NET JOBGROUPs are built dynamically as jobs with //*NET statements are processed
during INPUT phase. For JEC JOBGROUPs, the entire network exists before any jobs are
“registered” to it. The intent of this support is to emulate JES3 //*NET behavior as closely as
possible.
HOLD counts are maintained by the //*NET JOBGROUP. Commands to modify HOLD counts
are supported.
Provided commands are similar to the corresponding JES3 commands. Runtime behavior for
//*NET JOBGROUPs is tailored to emulate JES3 //*NET behavior as much as possible.
Substantial runtime differences exist with traditional JOBGROUP behavior. No requirement
exists that dictates that a target RELEASE= job exist when a parent job runs. This condition is
the same for NETREL= network or target job.
The owner of the logging job is the same as the job that triggered its creation. Jobs registering
(connecting) to the job group must pass a security check. The profile for the job groups you
want to protect must have the same user ID as the logging job or READ access to the
JESJOBS entity by using the following format:
GROUPREG.nodename.groupname.userid
//*NET dependencies are now initialized as undefined when they are created. Jobs in a
//*NET JOBGROUP can run out of order. A job can run whenever the HOLD count reaches
zero (by using a command or definition). That is, job execution is not fully controlled by
dependencies. //*NET JOBGROUPs have no concept of a concurrent set of jobs.
Note: MYNET is the NETID name (that is, - //*NET NETID=MYNET).Dependencies are
created from the //*NET RELEASE=(jobname[,jobname]...) clause.
Although another job released NET2 of JOBD, NET2 of JOBD is not yet entered to JES2.
New job information (STATJQ) //*NET subsection is added (STATNETI), which includes the
following //*NET statement keyword information:
Original HOLD count value (STNEOHLD)
NETREL= NETID name (STNENRID)
NETREL= JOB name (STNENRJB)
NORMAL= value (STNENORM)
ABNORMAL= value (STNEABNR)
ABCMP= value (STNEABCM)
NRCMP= value (STNENRCM)
OPHOLD= value (STNEPHLD)
Also, HOLD count filter is added (STATHCFV). This option allows filtering on current HOLD
counts =, >, <, >=, <=, != to STATHCFV. See fields STATSHCE, STATSHCL, and STATSHCG
for their dependencies on STATHCFV.
For more information, see Appendix F, “Alternative conversion programs” on page 263.
The syntax rules used by JES2 are the same as JES3, as shown in the following example:
//*ROUTE XEQ dest[.vmguestid]
JES2 does not support the alternative /*ROUTE XEQ syntax that is used by JES3 because of
conflicts with the JES2 /*ROUTE XEQ syntax.
The //*ROUTE XEQ statement is used to send the following input stream to a network node
where the job is then run. JES2 stops transmitting the input stream records when it finds one
of the following conditions:
A second JOB statement after the //*ROUTE XEQ statement.
The input stream runs out of records.
JES2 converts the NJB to JOB statement before transmitting the stream. Transmission of the
input stream is stopped by the JOB statement JOBXEQ75. Job JOBXEQ80 is read and run
by the system at node WTSCPLX8 (see Example 4-14). Job JOBXEQ75 is run at SC75
system of WTSCPLX7 node.
Example 4-14 JOB using //*ROUTE XEQ JECL submitted from a TSO/E
//JOBXEQ74 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//*ROUTE XEQ WTSCPLX8
//JOBXEQ80 NJB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//OUTPUT OUTPUT DEST=WTSCPLX7
//*
/*JOBPARM S=SC80
//*
//STEP01 EXEC PGM=IEFBR14
//*
//JOBXEQ75 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
/*JOBPARM S=SC75
//*
//STEP01 EXEC PGM=IEFBR14
Example 4-15, Example 4-16 on page 61, and Example 4-17 on page 61 show the messages
that are issued by the process of JOB by using the //*ROUTE XEQ.
Example 4-15 Messages from SC74 system processing the submitted job in Example 4-14
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '10.11.58 JOB02052 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
Example 4-17 Messages from SC80 system processing the received job JOBXEQ80
$HASP373 JOBXEQ80 STARTED - INIT 1 - CLASS B - SYS SC80
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ80 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ80 ENDED - RC=0000
$HASP309 INIT 1 INACTIVE ******** C=ABC
$HASP530 JOBXEQ80 ON L9.ST1 65 RECORDS
$HASP534 L9.ST1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654AE99)
Example 4-18 JOB using //*ROUTE XEQ JECL submitted by a $SUBMIT Command
//JOBXEQ74 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//*ROUTE XEQ WTSCPLX1
//JOBXEQ75 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=IEFBR14
//*
//JOBXEQ76 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
To submit the job that is shown in Example 4-18, the following command was issued at the
operator’s console:
$SUBMIT,MEMBER=JCLROUTE,DDNAME=SUBLIB00
This command calls the JES2 Disk Reader function to submit the job from a data set or an
z/OS UNIX directory. The related messages from z/OS OPERLOG are shown in
Example 4-19.
Example 4-19 Sample of $SUBMIT command issued to start a JOB with //*ROUTE XEQ JECL
$SUBMIT,MEMBER=JCLROUTE,DDNAME=SUBLIB00
$HASP000 OK
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM $SUBMIT
JCLROUTE
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '10.49.56 JOB02054 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
WTSCPLX8',LOGON,USER=(LPRES3)
$HASP100 JOBXEQ75 ON INTRDR ITSO REDBOOKS FROM $SUBMIT
JCLROUTE
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP524 L9.JT1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654B715)
$HASP540 JOBXEQ80 ON L9.SR1 FROM *UNKNOWN AT WTSCPLX8 65 RECORDS
ICH70001I LPRES3 LAST ACCESS AT 10:31:44 ON WEDNESDAY, JUNE 26, 2019
$HASP373 JOBXEQ75 STARTED - WLM INIT - SRVCLASS DFLT_MG - SYS SC75
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ75 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ75 ENDED - RC=0000
SE '10.49.56 JOB02054 $HASP122 JOBXEQ80 (JOB02054 FROM WTSCPLX7)
RECEIVED AT WTSCPLX8',LOGON,USER=(LPRES3)
SE '10.49.56 JOB02055 $HASP165 JOBXEQ75 ENDED AT WTSCPLX7 - JOBRC=0000
',LOGON,USER=(LPRES3)
In Example 4-18 on page 61, the job JOBXEQ74 is used only to tell JES2 to transmit the
subsequent job stream to WTSCPLX8 until the JOBXEQ75 JOB statement. The job
JOBXEQ75 is processed locally.
The system SC80 messages when processing the job JOBXEQ80 that is transmitted by a
//*ROUTE XEQ JECL statement on JOBXEQ74 job submitted by using the $SUBMIT
command is shown in Example 4-20.
Example 4-20 Messages from SC80 system processing the transmitted job
$HASP100 JOBXEQ80 ON L9.JR1 ITSO REDBOOKS FROM *UNKNOWN
AT WTSCPLX7
$HASP373 JOBXEQ80 STARTED - INIT 1 - CLASS B - SYS SC80
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ80 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ80 ENDED - RC=0000
$HASP309 INIT 1 INACTIVE ******** C=ABC
$HASP530 JOBXEQ80 ON L9.ST1 65 RECORDS
Error messages
The following error messages can be issued by JES2 when processing the //*ROUTE XEQ
JECL statement:
$HASP6175 JOBXEQ74: Job to be transmitted has no records
$HASP6176 JOBXEQ74: Expected JOB/NJB statement not found after //*ROUTE XEQ
$HASP6177 JOBXEQ74: Encountered //*
This statement, combined with the PENCRYPT parameter, provides the same functions as
the JES3 PWCNTL parameter on the NJERMT statement. The JES2 settings to match the
JES3 PWCNTL specifications are listed in Table 4-3.
SENDCLR NO NO
SENDENC NO YES
The command that is issued to set the JES3_LOCAL_CHK parameter to node WTSCPLX8 to
activate the local check of password on submitter job by using the //*ROUTE XEQ JECL
statement is shown in Example 4-21.
If the password is incorrect in the JOB card of the submitting job, the job fails. An error
message is issued that states that the user ID or password cannot be verified. The target JOB
is no transmitted. A verification failed occurrence on JOBXEQ74 that was used to transmit a
job by using the //*ROUTE XEQ JECL card is shown in Example 4-22.
However, when the JES3_LOCAL_CHK parameter is set to NO, as shown in Example 4-23,
even if an incorrect password is coded in the JOB card, this password is not validated in the
submitting system and the target job is transmitted.
The messages that are issued for the job that is submitted from SC74 system on WTSCPLX7
with a user ID and an incorrect password that were coded in the JOB card is shown in
Example 4-24. No password validation is done by the submitter node and the job is
successfully transmitted to the destination node.
Example 4-24 Job submitted using the //*ROUTE XEQ with JES3_LOCAL_CHK set to NO
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '11.51.50 JOB02061 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
WTSCPLX8',LOGON,USER=(LPRES3)
$HASP524 L9.JT1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654C4EC)
However, the user ID that is used to submit the job is not propagated to the destination node.
For this reason, the resulting job does not include a user ID that is associated to it and a
security violation occurs because the user ID cannot be found in the destination node.
The Example 4-25 show the JOBLOG for the submitted job in the destination node.
Example 4-25 Job with Security Error on receiving node without user ID
J E S 2 J O B L O G -- S Y S T E M S C 8 1 -- N O D E W T S C P L X 8
However, JES2 provides the privileged support function that assists the system programmer
in the resolution of critical JES2 resource shortage conditions. This function reserves a
certain amount of critical resources for privileged job (STC, TSU, and JOB) use. This
reserved resources can then be used by privileged jobs to diagnose and correct resources
shortages. Privileged jobs enter the system by using an emergency subsystem.
A small percentage of SPOOL, jobs, output elements, and BERTs are set aside for privileged
jobs. This approach assures that you have enough resources to log on, perform analysis,
submit jobs, and resolve the root cause of resource exhaustion. Privileged resources can be
used by privileged jobs, STCs, and TSO logons only.
When you successfully activate the function, the following message is displayed:
$HASP1401 Privilege Resource Support activated for -- <resource type>
You receive one message for each of the resources; however, if the activation for the specific
resource fails, the following message is displayed:
$HASP1403 Privilege Resource Support could not be activated for <resource type>
This failure occurs when the free elements of the resource are smaller than the minimum
number required (see Table 4-4). The required free element numbers come from the default
setting or from the small environment.
The required free elements for each resource in default environment are listed in Table 4-4.
However, these requirements might be too large for small environments. In this case, you can
run the following command to activate a “small environment,” which has smaller requirements:
$T LIMITS,PRIV=ON,SMALLENV=ON
The required free elements for each resource in a small environment are listed in Table 4-5.
JOEs 600 60 60
JQEs 100 10 10
You can show the current LIMITS status in the default environment, as shown in
Example 4-26.
You also can display the current LIMITS status in a small environment, as shown in
Example 4-27.
If you are verifying parameters on a warm start, you must run the checker within a SYSPLEX
with an active member of the MAS. The checker uses XCF messaging to extract information
from the active MAS member to achieve the following goals:
Verify that the parameters are valid on a warm start
Perform more analysis of resource usage
For more information about the JES2 initialization data set checker, see Chapter 5.2.1,
“Verifying the JES initialization deck” on page 95.
With this function, JES2 automatically writes SMF 84 records for resource monitoring, if you
do not disable the recording for SMF 84 in IFASMFxx.
Because no official formatting program exists for SMF 84 subtype 21, you must develop your
own formatting program, depending on your requirements. For more information about a
sample program to format SMF 84 subtype 21, see Appendix C, “Sample SMF84 Report
program” on page 203. Although you can use this code as a starting point, you must
thoroughly test the final code that you deploy.
Example 4-28 Sample syslog to add and display eight characters job class
$ADD JOBCLASS(NEWADD),ACTIVE=YES
$HASP837 JOBCLASS(NEWADD) 200
$HASP837 JOBCLASS(NEWADD) ACTIVE=YES,GROUP=,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$TI(49),CLASS=(NEWADD)
$HASP892 INIT(49) 202
$HASP892 INIT(49) STATUS=INACTIVE,CLASS=(NEWADD),NAME=49,
$HASP892 ASID=0066
You can specify the eight-character JOB CLASS, as shown in Example 4-29.
As shown in Example 4-30, two job classes are defined, each belonging to one job class
group.
Example 4-30 Sample SYSLOG to add and display job class group
$ADD JOBCLASS(TEST1),ACTIVE=YES,GROUP=GRP1
$HASP837 JOBCLASS(TEST1) 853
$HASP837 JOBCLASS(TEST1) ACTIVE=YES,GROUP=GRP1,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$ADD JOBCLASS(TEST2),ACTIVE=YES,GROUP=GRP1
$HASP837 JOBCLASS(TEST2) 918
$HASP837 JOBCLASS(TEST2) ACTIVE=YES,GROUP=GRP1,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$DCLASSGRP(GRP1)
$HASP816 CLASSGRP(GRP1) TEST2,TEST1
-------------------------------------------------------------------------------
$TI(50),CLASS=(GRP1)
$HASP892 INIT(50) 254
$HASP892 INIT(50) STATUS=INACTIVE,CLASS=(GRP1),NAME=50,
$HASP892 ASID=0065
A job class group facilitates selecting on job classes. Initiators and Offload Job Transmitters
can specify 1 - 36 single character job classes or 1 - 8 multi- (or single-) character job classes
or job class groups.
You can specify a job class name that is included in a job class group in the CLASS
parameter of a JOB statement, as shown in Example 4-31. You cannot specify a job class
group name directly in the CLASS parameter of a JOB statement.
Example 4-31 Sample JCLs to specify job class included job class group
//JOBA JOB MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,CLASS=TEST1
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
When an initiator that is assigned to a job class group selects a job for execution, it does so in
a round-robin fashion. When a job is selected, the classes are rotated so the next selection
starts with the next job class in the group.
For example, assume that you have ten jobs that specify CLASS=TEST1, and other ten jobs
that specify CLASS=TEST2 in the job queue. In this example, TEST1 and TEST2 are
included in a job class group GRP1. As a result, the initiator that GRP1 is assigned to select
TEST1 jobs and TEST2 jobs in round-robin fashion.
The following updates were made to the CLASS= parameter in the command and
initialization statement:
CLASS=ABCD: Implies single-character job classes A, B, C, and D.
CLASS=(ABCD): Implies four-character job class or job class group ABCD.
INTERPRET specifies when JES2 calls the z/OS interpreter to process a job.
With this option, the z/OS interpreter is called at the end of conversion processing. The use of
this option includes the following benefits:
Earlier detection of JCL errors that are detected by the MVS interpreter. This function
allows errors to be detected, even if the job never runs f(TYPRUN=HOLD).
Processing of JESDS OUTPUT statements to control data set attributes, even if the job
never runs.
INTERPRET=JES also means that the converter and interpreter run in a JES2CI address
space that is separated from a JES2 address space. Therefore, SYSZTIOT ENQ contention
can be avoided between a spool offloaded allocation delay in JES2 address space and
conversion JCL allocation in JES2CI address space. It is a best practice to use
INTERPRET=JES.
INIT specifies to call the interpreter when the job is selected for execution by an initiator.
Starting the interpreter in the initiator is the traditional JES2 processing method. This
behavior is the default.
However, in the JES2 default environment where JEBDEF INTERPRET=INIT, the job is held
until released, as shown in Example 4-33. Therefore, timing for JCL error detection is much
earlier in JES3.
However, with JOBDEF INTERPRET=JES enabled, you can detect JCL errors in the early
interpreter phase, as does JES3.
Also, specifying INTERPRET=JES causes EXIT 60 to be driven instead of EXIT 6. If you use
EXIT 6, you might need to also provide similar function in EXIT 60 before setting
INTERPRET=JES.
You specify a date and time when a job can be released, as shown in Example 4-34. The job
is released on 16:30 on Jun. 12 2019 in this example.
Example 4-34 Sample JCL to specify HOLDUNTIL for specific date and time
//JOBZ JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID
// REGION=0M
//SCHED SCHEDULE HOLDUNTL=('16:30','2019/163')
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
Another option is to specify how long the job must be held, as shown in Example 4-35. The
job is released after 30 minutes from the job submission in this example.
Until a job is released, $DJ shows the status as shown in Example 4-36.
However, JES does not ensure that the job is selected at the specified time. The ability of the
job to be selected depends on the system environment, system affinity, availability of
initiators, and availability of resources, among other factors.
You specify a date and time when a job starts as shown in Example 4-37. In this example, the
target date and time are 16:30, June 12, 2018.
Example 4-37 Sample JCL to specify STARTBY for specific date and time
//JOBX JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//SCHED SCHEDULE STARTBY=('16:30','2018/163')
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
Another option is to specify how long a job waits for selection, as shown in Example 4-38. The
target time the job should be selected is after 30 minutes from job submission in this case.
This function is not enabled by default. It must be enabled by using the following command:
$TJOBCLASS(c),PROMO_RATE=nn
Where nn specifies how many positions a job can be moved up the execution queue in one
STARTBY aging cycle (1 minute=fixed value). The default value PROMO_RATE=0 means
that the STARTBY function is disabled for the job class. You can also set this value in the
PROMO_RATE parameter on JOBCLASS initialization statement.
Use the WITH parameter to specify that the job must be run on the same system where
another reference job is active. If the WITH parameter is used, the job is not eligible for
execution until the reference job is active. In addition, the job can be run only on the same
system where the reference job is active.
Jobs having a WITH specification can be submitted before or after the reference job is started
or submitted. However, it is a best practice to submit a job after the reference job is started
because the reverse sequence causes extra processor overhead.
The sample JCL that is shown in Example 4-39 specifies that JOBB must be run in the
system where JOBA is running.
If the referenced job (JOBA) is not yet active, the referencing job (JOBB) waits for execution,
as shown in Example 4-40. When JOBA starts, JOBB automatically starts on the system
JOBA is running.
Example 4-40 Sample display for the job waiting for reference job active
$DJ9543
$HASP890 JOB(JOBB) 605
$HASP890 JOB(JOBB) STATUS=(AWAITING EXECUTION),CLASS=A,
$HASP890 PRIORITY=8,SYSAFF=(ANY),HOLD=(NONE),
$HASP890 WITH=JOBA
In a JES3 environment, it is easy to implement this functionality by using only JES3 Inish
deck definitions, as shown in Example 4-41, Example 4-42, and Example 4-43. Only related
parameters are described in these examples. The “SPECIAL” spool partition, which consists
of SPOOL4, is reserved for CLASS=B and MSGCLASS=Y:
Define spool partitions, as shown in Example 4-41.
Assign each spool space to a defined spool partition, as shown in Example 4-42.
However, JES2 does not have the same capabilities as JES3. Therefore, you must manage
JES2 spool with some combination of JES2 functions.
SPOOL fencing
Standard JES2 processing allows all jobs to allocate track groups on all available spool
volumes. Spool partitioning is a facility that is provided within JES2 that permits the specific
identification of spool volumes from which a particular job or job class can allocate track
groups. This facility is also referred to as spool fencing.
JES2 fences a job to an installation-defined number of volumes. In this form of fencing, the
job starts with a zero spool partitioning mask work area. As the job allocates spool space,
each volume that is used corresponds to a bit set in the mask. The job is forced to use
volumes listed in the mask only. Minimum fencing is defined as setting the volume limit to “1”.
You also can implement SPOOL partitioning based on, for example, JOBCLASSes or
JOBNAMEs, similar to JES3. The SPOOLDEF initialization statements and two installation
exits, Exit 11 and Exit 12, provide methods for accessing and setting the spool partitioning
mask work area.
It is a best practice to use JES2 standard functions to manage JES2 spools instead of JES3
spool partitioning simulation by JES2 EXITs. This practice ensures future maintainability.
SPOOL affinity
JES2 also processes your fencing requirements based on the system affinity to those
volumes.
Each spool volume includes masks of systems that can allocate space on that volume. Jobs
are limited to the spool volumes associated with a system. You assign spool volumes to
particular systems by using the $T SPOOL command, as shown in Example 4-44. (No
initialization options are available to perform this task.)
Privileged space
This function is described in 1.3.2, “JES2 resiliency” on page 6.
Reserved volumes
You can allocate JES2 spool volumes with the option RESERVED=Yes, which marks the
spool volume as reserved for special processing and no new allocations are allowed. The
RESERVED=No option clears the reserved attribute.
This function allows JCL to be submitted to JES2 from a concatenation without having to log
on to TSO, submit a job, or run a started task.
To support this functionality on JES2, a logical concatenation of PDSs, PDSEs, and z/OS
UNIX directories is used as source of members. Commands also are available that can be
used to read the member and copy it to the internal reader.
SUBMITLIB(ddname) DD(n)=(DSName=name,[VOLser=volume,UNIT=unit])
DD(n)=(PATH=pathname)
CONDitional|UNCONDitional
Figure 4-2 SUBMITLIB statement syntax:
These concatenated lists can be defined by the JES2 initialization data set deck or added
dynamically by using the $ADD SUBMITLIB command.
Also, the $ADD, $DEL, $T, and $D commands are available on JES2 to manage SUBMITLIB
concatenation.
If a file system path is specified, files in the path must be with 1 - 8 character file names that
conform to standard PDS member names and can be accessed by using the
FILEDATA=TEXT allocation option (see Example 4-45).
Example 4-45 Sample of $ADD SUBMITLIB command used to define a new SUBMITLIB to JES2
$ADD SUBMITLIB(SUBLIB00),DD(01)=(DSNAME=SYS1.JES2.SUBMTLIB)
IEF196I IEF237I 9788 ALLOCATED TO $SB00006
$HASP736 SUBMITLIB(SUBLIB00) 393
Unlike PROCLIB processing, JES2 opens and closes the SUBMITLIB concatenations for
every $SUBMIT command. This ability reduces the risk of errors when data sets in the
concatenation are compressed (see Example 4-46).
Example 4-46 Sample of $T SUBMIT command used to add a PATH to an existent concatenation
$T SUBMITLIB(SUBLIB00),DD(02)=(PATH='/u/jes2/submitlib/sublib00')
IEF196I IEF237I 9788 ALLOCATED TO $SB00010
IEF196I IGD103I SMS UNIX FILE ALLOCATED TO DDNAME SYS00006
IEF196I IEF285I SYS1.JES2.SUBMTLIB KEPT
IEF196I IEF285I VOL SER NOS= BH5CAT.
$HASP736 SUBMITLIB(SUBLIB00) 426
$HASP736 SUBMITLIB(SUBLIB00)
$HASP736 DD(1)=(DSNAME=SYS1.JES2.SUBMTLIB,
$HASP736 VOLSER=BH5CAT),
$HASP736 DD(2)=(PATH=/u/jes2/submitlib/subli
$HASP736 b00)
Example 4-48 Sample of $DEL SUBMITLIB command used to remove a SUBMITLIB concatenation
$DEL SUBMITLIB(SUBLIB00)
IEF196I IEF285I SYS1.JES2.SUBMTLIB KEPT
IEF196I IEF285I VOL SER NOS= BH5CAT.
The DD_DEFAULT subparameter specifies the default SUBMITLIB concatenation that is used
by the $SUBMIT command (see Figure 4-3).
SUBMITRDR AUTH=(DEVICE=YES|NO,JOB=YES|NO,SYSTEM=YES|NO)
CLASS=jobclass,DD_DEFAULT=ddname,HOLD=YES|NO,
PRTYINC=nn,PRTYLIM=nn,SYSAFF=(affinity_list),
TRACE=YES|NO
Figure 4-3 SUBMITRDR statement syntax
Default attributes for the submit reader can be specified on the SUBMITRDR statement.
Security for data that is passed over the submit reader is based on the issuer of the $SUBMIT
command. If a user identity exists that is associated with the issuer of the command, that user
is considered the submitter of the data stream. Commands and jobs are processed as if the
originator of the command issued the commands or submitted the jobs.
Only one $SUBMIT command can be active on a member at a time. A second $SUBMIT
command, while the first is still active, fails with a $HASP149 message, which indicates that a
previous command is still active.
The existence of the default SUBMITLIB DD name is checked at the time that the $SUBMIT
command is sued. If it does not exist, the $SUBMIT command fails with a $HASP665 message,
which indicates that the SUBMITLIB was not found.
The use of the $SUBMIT command queues the processing to a subtask in the JES2 address
space. The processing occurs asynchronous to the JES2 command processor. Error
messages that are related to the member not being found or any other errors occur after the
command processing completes.
Error messages that are associated with the submit command (such as the member not
being found or an error reading the member) are routed back to the originating console.
$SUBMIT DDname=name,MEMBER=member,HOLD=YES|NO
Figure 4-4 $SUBMIT command syntax
This property is enforced on existing nodes that are receiving jobs from a JES3 migrated
environment that support multiple jobs that are received from an NJE node and JES2 not.
This support removes the restriction of only one job allowed by NJE submission.
This feature is supported on JES2 base code and does not require any external change on
current JES2 environment.
If you want to run the jobs in destination node following a specific order, you can create a
package by using the JOBGROUP definition and it is grouped JOBs into one NJE
transmission unit. With the definition that is shown in Example 4-49, the JOBGROUP is
processed first, and therefore exists on the receiving node before the grouped JOBs are
processed.
In summary, packaging all JOBs and JOBGROUPs in a single /*XMIT unit is easier to
understand and can eliminate potential NJE transmission timing issues.
Example 4-49 Sample of job using Multi-Job NJE Stream with JOBGROUP definition
//JOBXMITG JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
/*XMIT WTSCPLX7 DLM=ENDXMIT
//*
//*-------------------------------------------------------------
//* JOBGROUP XMJG0001 : JOBXMITA --> JOBXMITB
//*-------------------------------------------------------------
//XMJG0001 JOBGROUP
//*
//JOBXMITB GJOB
// AFTER NAME=JOBXMITA,WHEN=(RC=0)
//*
//JOBXMITA GJOB
//*
//XMJG0001 ENDGROUP
//*------- JOB : JOBXMITA --------------------------------------
//JOBXMITA JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
// SCHEDULE JOBGROUP=XMJG0001
//STEP1 EXEC PGM=IEFBR14
//*------- JOB : JOBXMITB --------------------------------------
Studying your JES2 initialization statements and mapping them to their JES3 equivalent
(where possible) provides you with a valuable insight to how many changes you must make
when migrating from JES3 to JES2.
The started procedures for JES2 and JES3 are also described.
Each JES2 member can read jobs from local and remote card readers, select jobs for
processing, print, and punch results on local and remote output devices, and communicate
with the operator. Each JES2 member in a Sysplex operates independently of the other JES2
members.
The JES2 members share a common job queue and a common output queue, which are on
the checkpoint data sets. These common queues enable each JES2 member to share in
processing the installation’s workload. Jobs can run on whatever system is available and print
or punch output on whatever system has an available device with the proper requirements.
A JES3 JESplex consists of a Global system and zero or more Local systems. The Global
system is the first system to perform a cold or warm start following a JESplex-wide IPL.
During a cold or warm start, the Global system reads the initialization deck. When
initialization of the Global is complete, any other systems in the JESplex might start JES3 as
locals.
JES3 on a Local system communicates with the Global through XCF. A Local system never
accesses the JES3 initialization deck. Instead, it obtains the information that it needs about
the configuration by reading the checkpoint data set. It uses the information in the checkpoint
to start communication with the Global system.
The JES3 Global function can be moved to a Local system during a planned or unplanned
outage by performing a Dynamic System Interchange (DSI). The initialization deck is not read
during a DSI. Instead, JES3 uses its checkpoint data set to bring the JESplex back to normal
function.
The following examples include initialization parameters that are used by JES3 and the
equivalent that is used during JES2 initialization. Based on these examples, a new JES2
environment can be built that is based on previous JES3 definitions. The statements were
coded based on a current JES3 environment and tested by using the JES2 initialization deck
checker process.
CKPTDEF CKPT1=(STR=JES2_CKPT1,INUSE=YES),
CKPT2=(STR=JES2_CKPT2,INUSE=YES),
NEWCKPT1=(DSN=SYS1.JESCKPT1,VOL=JESSP1),
NEWCKPT2=(DSN=SYS1.JESCKPT2,VOL=JESSP2)
JSAM JES3 definitions and the equivalent JES2 definitions are shown in Example 5-3.
JES3 standards definitions and the JES2 statements that are used to cover most of these
standards are shown in Example 5-4. For some standards, no JES2 equivalent statement is
available.
Example 5-4 JES3 standards definitions and the JES2 corresponding statements
/*
***********************************************************************
* STANDARDS FOR JES3 *
***********************************************************************
STANDARDS,CICNT=(10,4),LINES=(150000,W),PRTY=6,SETUP=THWS,CARDS=(200), X
STCPMID=02,TSOPMID=03,TSOPROC=01,BYTES=(999999,W),PAGES=(1000,W), X
FAILURE=CANCEL,MAXJOBST=3200,THWSSEP=PREFER
*
***********************************************************************
* Z/OS CONVERTER PARAMETERS *
***********************************************************************
CIPARM,PARM=(40600300050031E00011X),PARMID=01,REGION=5M
CIPARM,PARM=(40600600050031E00011X),PARMID=02,REGION=5M
CIPARM,PARM=(40600300050031E00011Z),PARMID=03,REGION=5M
*/
/*********************************************************************/
/* JES2 DEFINITIONS FOR STANDARDS AND CONVERTER PARAMETERS */
/*********************************************************************/
ESTLNCT NUM=150,INT=100000,OPT=0
ESTPUN NUM=200,INT=10,OPT=0
ESTPAGE NUM=1000,INT=1000,OPT=0
ESTBYTE NUM=1000,INT=100,OPT=0
JOBCLASS(STC) BLP=YES,COMMAND=DISPLAY,MSGCLASS=X,MSGLEVEL=(1,1),
PROCLIB=00,REGION=5M,SWA=ABOVE,TIME=(60,0)
JOBCLASS(TSU) BLP=YES,COMMAND=DISPLAY,LOG=NO,MSGCLASS=Z,MSGLEVEL=(1,1),
PROCLIB=01,REGION=5M,SWA=ABOVE,TIME=(30,0)
JOBDEF JOBNUM=32767,PRTYHIGH=14,PRTYJECL=YES,PRTYJOB=YES,PRTYLOW=6,
PRTYRATE=48,RANGE=1-32767
The main processors definition in the JES3 environment with the equivalent JES2 member
definition to identify the JES2 MAS members are shown in Example 5-5.
JES3 definitions to specify the job classes and the job class groups with the equivalent JES2
Jobclass definition are shown in Example 5-6.
Example 5-6 JES3 job execution classes and groups with the JES2 definition to job classes
/*
***********************************************************************
* SELECT, GROUP AND CLASS DEFINITION *
***********************************************************************
*
SELECT,NAME=SEL74, X
SBAR=10,SAGER=03,SAGEL=14,LSTOR=32000, X
GROUP=(GRA,10)
*
SELECT,NAME=SEL75, X
SBAR=10,SAGER=03,SAGEL=14, X
GROUP=(GRB,30)
*
SELECT,NAME=DUMMY
JES3 output processing definitions and the equivalent JES2 definitions that use the
OUTCLASS statements are shown in Example 5-7.
Example 5-7 JES3 sysout definitions and the equivalent JES2 output classes
/*
***********************************************************************
* OUTPUT SERVICE DEFAULT AND STANDARDS *
***********************************************************************
OUTSERV,TRAIN=ANY,WC=(P),WS=(D,T,F,C,CL,U,P,L), X
FORMS=STD,CDSTOCK=STD, X
CB=N,OUTLIM=16777215,OUTSVFCT=5,EXTOSENUM=NO
*
***********************************************************************
* JES3 SYSOUT DEFINITION *
***********************************************************************
SYSOUT,CLASS=A,OVFL=OFF
SYSOUT,CLASS=M,OVFL=OFF,HOLD=TSO,TYPE=(PRINT),SPART=SPOOL2S
SYSOUT,CLASS=X,COPIES=0,HOLD=EXTWTR
SYSOUT,CLASS=Y,OVFL=OFF
SYSOUT,CLASS=Z,OVFL=OFF,HOLD=EXTWTR
*/
/*********************************************************************/
/* JES2 SYSOUT DEFINITION */
/*********************************************************************/
OUTDEF JOENUM=6000,DSLIMIT=10M,STDFORM=STD
OUTCLASS(A)
OUTCLASS(M) OUTDISP=HOLD
OUTCLASS(X) OUTDISP=HOLD
OUTCLASS(Y)
JES3 and JES2 console definition and the command prefix are shown in Example 5-8.
Example 5-8 JES3 and JES2 definitions to console and command prefix
/*
***********************************************************************
* CONSOLE SERVICE STANDARDS : *
***********************************************************************
CONSTD,SYN=($),GLOBMPF=NO,DLOG=ON
*/
/*********************************************************************/
/* JES2 CONSOLE DEFINITION */
/*********************************************************************/
CONDEF CONCHAR=$,BUFNUM=200,CMDNUM=1000,SCOPE=SYSTEM
JES3 FSS printers definitions and the same JES2 definitions are shown in Example 5-9.
Example 5-9 JES3 FSS printers definition and the equivalent JES2 definitions
/*
***********************************************************************
* JES3 FSS DEFINITIONS *
***********************************************************************
FSSDEF,TYPE=WTR,FSSNAME=FSSPRT1,PNAME=PSFPRT1, X
SYSTEM=(SC74,SC75)
FSSDEF,TYPE=WTR,FSSNAME=FSSPRT2,PNAME=PSFPRT2, X
SYSTEM=(SC74,SC75)
FSSDEF,TYPE=WTR,FSSNAME=FSSPRT3,PNAME=PSFPRT3, X
SYSTEM=(SC74,SC75)
*/
/*********************************************************************/
/* JES2 FSS PRINTER DEFINITION */
/*********************************************************************/
FSSDEF(FSSPRT1) PROC=PSFPRT1
FSSDEF(FSSPRT2) PROC=PSFPRT2
FSSDEF(FSSPRT3) PROC=PSFPRT3
JES3 printer definitions and the corresponding JES2 initialization statements are shown in
Example 5-10.
PRT(1) CLASS=A,FSS=FSSPRT1,MODE=FSS,PRESELCT=YES,
START=NO,TRKCELL=YES,WS=(Q,R)
The statements that are used by JES3 to define remote printer RJP are called RMT10. The
equivalent JES2 definition that is used for RJE processing is shown in Example 5-11.
R(10).PR(1) CCTL=YES,CKPTLINE=66,CKPTPAGE=10,CLASS=1,START=NO,
SEPDS=YES,PRWIDTH=255,SELECT=PRINT1,ROUTECDE=(LOCAL,R10),
WS=(W,R,Q,PMD,LIM/T,C,P)
R(10).PR(2) CCTL=YES,CKPTLINE=66,CKPTPAGE=10,CLASS=1,START=NO,
SEPDS=YES,PRWIDTH=255,SELECT=PRINT2,ROUTECDE=(LOCAL,R10),
WS=(W,R,Q,PMD,LIM/T,C,P)
R(10).PU(1) SELECT=PUNCH1,LRECL=80,SEP=NO
R(10).RD(1)
The basic JES3 NJE definitions and the JES2 APPL definitions that are used by JES2 to
configure an NJE environment are shown in Example 5-12.
NJEDEF DELAY=300,HDRBUF=(LIMIT=100,WARN=80),
JRNUM=1,JTNUM=1,SRNUM=7,STNUM=7,LINENUM=5,MAILMSG=YES,
MAXHOP=0,NODENUM=999,OWNNODE=1,PATH=1,CONNECT=(YES,1),
RESTMAX=0,RESTNODE=100,RESTTOL=0,TIMETOL=0
LOGON(1) APPLID=SC74NJE
NODE(1) NAME=WTSCPLX7,PATHMGR=YES,SUBNET=MYJES
Other JES2 parameters that are required to complete the JES2 initialization configuration are
shown in Example 5-13.
Example 5-13 JES2 extra parameters that are used by JES2 initialization
/*********************************************************************/
/* ADDITIONAL JES2 DEFINITIONS */
/*********************************************************************/
/*********************************************************************/
/* TWS JES2 EXITS DEFINITIONS WITH TWO DIFFERENT WAY */
/*********************************************************************/
EXIT(11) ENABLE,ROUTINES=(JES2X011)
LOAD(JES2X011)
EXIT(12) ROU=(JES2X012),STATUS=ENABLED
LOAD(JES2X012)
/*********************************************************************/
/* JES2 INITIATORS DEFINITION */
/*********************************************************************/
INITDEF PARTNUM=30
INIT(01) CLASS=ABCDE,START=NO
INIT(02) CLASS=ABCDE,START=NO
INIT(03) CLASS=ABCDE,START=NO
INIT(04) CLASS=ABCDE,START=NO
INIT(05) CLASS=ABCDE,START=NO
INIT(06) CLASS=ABCDE,START=NO
INIT(07) CLASS=ABCDE,START=NO
INIT(08) CLASS=ABCDE,START=NO
INIT(09) CLASS=ABCDE,START=NO
INIT(10) CLASS=ABCDE,START=NO
INIT(11) CLASS=ABCDE,START=NO
INIT(12) CLASS=ABCDE,START=NO
INIT(13) CLASS=ABCDE,START=NO
INIT(14) CLASS=ABCDE,START=NO
INIT(15) CLASS=ABCDE,START=NO
INIT(16) CLASS=ABCDE,START=NO
INIT(17) CLASS=ABCDE,START=NO
INIT(18) CLASS=ABCDE,START=NO
INIT(19) CLASS=ABCDE,START=NO
INIT(20) CLASS=ABCDE,START=NO
INIT(21) CLASS=ABCDE,START=NO
INIT(22) CLASS=ABCDE,START=NO
INIT(23) CLASS=ABCDE,START=NO
INIT(24) CLASS=ABCDE,START=NO
INIT(25) CLASS=ABCDE,START=NO
OFF(1).JT CLASS=,CREATOR=,DISP=DELETE,HOLD=,
JOBNAME=,NOTIFY=NO,ROUTECDE=(),START=NO,SYSAFF=(),
VOLUME=(),WS=(CLASS/)
OFF(1).SR BURST=,CREATOR=,FCB=,FLASH=,FORMS=,HOLD=,JOBNAME=,
MOD=(BURST=,FCB=,FLASH=,FORMS=,HOLD=,OUTDISP=,PRMODE=,
QUEUE=,ROUTECDE=,UCS=,WRITER=),
NOTIFY=NO,PRMODE=(),QUEUE=,ROUTECDE=(),START=YES,UCS=,
WRITER=,WS=(/)
OFF(1).ST BURST=,CREATOR=,DISP=DELETE,FCB=,FLASH=,FORMS=,HOLD=,
JOBNAME=,LIMIT=(0-*),NOTIFY=NO,PLIM=(0-*),PRMODE=(),
QUEUE=,ROUTECDE=(),START=YES,UCS=,VOLUME=(),WRITER=,WS=(/)
/*********************************************************************/
/* JES2 DISK READER DEFINITION */
/*********************************************************************/
SUBMITLIB(SLTEST) DD(01)=(DSNAME=SYS1.JES2.SUBLIB.TEST),UNCONDITIONAL
SUBMITLIB(SLPROD) DD(01)=(DSNAME=SYS1.JES2.SUBLIB.PROD),UNCONDITIONAL
SUBMITRDR AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),
CLASS=A,DD_DEFAULT=SLTEST,HOLD=NO,
PRTYINC=01,PRTYLIM=08,
TRACE=NO
/*********************************************************************/
/* JES2 POLICY LIBRARY DEFINTIONS */
/*********************************************************************/
PLCYLIB(PLCYLIB00),DD(01)=(DSNAME=SYS1.JES2.PLCYLIB),UNCONDITIONAL
The JES3 initialization stream checker is processed by the IATUTIS program that allows the
system programmer to verify that the deck has no errors before a scheduled restart. The
initialization stream checker also detects most syntax errors and some logical errors in the
initialization stream.
Installations that still have disk or tape DEVICE statements might use option 2.4 in the HCD
ISPF panels to create members that are then pointed to by the STG1CODE DD statement in
the checker job. The initialization deck checker then verifies that the DEVICE statements
agree with the devices in the HCD.
As with the JES3 initialization stream checker, JES2 initialization data set checker allows
installations to verify their initialization data sets without having to start a JES2 subsystem.
The process can detect syntax errors in initialization statements and problems with settings
that might prevent JES2 from starting. The checks can verify that the statements are valid for
a cold start or a warm start.
If parameters are verified for a warm start, you must run the checker within a SYSPLEX with
an MAS active member. The checker uses XCF messaging to extract information from the
active MAS member to verify whether the parameters are valid on a warm start and to
perform more analysis of resource usage. A sample JCL to run the JES2 initialization data set
checker as a batch job is shown in Example 5-16.
Example 5-16 Sample JCL to run the JES2 initialization deck checker as a batch job
//INITJ2CK JOB (),’PROGRAMMER NAME’,CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//HASCHECK EXEC PGM=HASJESCK,PARM=’LIST’
//HASPLIST DD SYSOUT=*
//HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(J2DFAULT)
//
PRTYINC=01,PRTYLIM=08,TRACE=NO
Example 5-18 Sample HASPLIST Pages 4 and 5: Initialization parameters and diagnostic report
1 JES2 parameter library listing 2019.176 PAGE 5
-DIAGNOSTIC INFO $HASP442 INITIALIZATION STATEMENTS CONFLICTING WITH SAVED VALUES FOLLOW:
DIAGNOSTIC WARNING $HASP496 OUTDEF JOENUM=6000 SAVED VALUE OF 10000 WILL BE USED
DIAGNOSTIC WARNING $HASP496 CKPTSPAC BERTNUM=4600 SAVED VALUE OF 2100 WILL BE USED
DIAGNOSTIC INFO $HASP537 THE CURRENT CHECKPOINT USES 722 4K
RECORDS
JQEs TYPE ACTIVE COMPLETE JOEs TYPE COUNT TGs TYPE COUNT INUSE
-------- --------- --------- -------- --------- -------- ----------- -----------
BATCH 1 1,134 WORK 4,022 DEFINED 40,167 20,305
STC 107 335 CHAR 14 ACTIVE 40,017 20,395
TSU 2 14 INDEX 0 FREE 19,622
JOBGROUP 0 12 FREE 5,964
INTERNAL 11
FREE 1,384
BERTs TYPE COUNT CB COUNT ZJCs TYPE COUNT Jobnum Description Value
-------- --------- --------- -------- --------- ------------ ---------
INTERNAL 34 4 JOBGROUP 9 Low Range 1
JQE 265 254 DEP JOB 28 High Range 9,999
CAT 144 48 DEPENDNT 24 In Use 1,616
WSCQ 8 2 FREE 939
DJBQ 0 0
JOE 6 6
DAS 0 0
GRP 2 2
FREE 1,641
Recommendations:
Error Summary:
Type Count
-------------------------- -------
Warnings 2
Init statement errors 0
Validation errors 0
Read/OPEN errors 0
Configuration errors 0
Exit requested termination 0
-------------------------- -------
Total error count
2
After the initialization statements are processed, the processing attempts to access the
runtime data. If the runtime data is available, the normal verification processing of initialization
the initialization statements against the runtime data is performed.
After normal initialization processing completes, several reports are generated. The first
report is the data set read report (see Example 5-17 on page 97). This report lists the
initialization data sets that were read and the number of records that are processed from each
data set.
A section of the report is reserved to provide recommendations for minimum settings for
several resources. This value is based on reviewing the current usage ration of resources per
job and projecting what is needed if the job limit is reached.
The summary report returns information about the JES2 instance that was verified. It includes
the JES2 member name, node name, and XCF group name that is derived from the
initialization data sets.
At the end of the report, the error summary provides a summary of any errors that are found
during processing.
The JES3 procedure points to a single member of a PDS, which can be overridden by
replying M=xx to the IAT3012 message. INCLUDE statements can be used in the initialization
deck to separate groups of statements into separate PDS members, if wanted.
JES2 can concatenate two or more members on the HASPPARM DD statement. Optionally,
INCLUDE statements can be added to initialization deck data sets. As shown in
Example 5-21, member JES2IN00 contains common statements and member JES2INxx
contains z/OS image-specific statements. z/OS image-specific statements typically include
devices, such as channel-attached printers, that can be physically attached to one z/OS
image only.
System programmers must ensure all of the data sets that are referenced in the JES2
procedure are available or JES2 fails with a JCL error.
The PROCLIB defined dynamic PROCLIB statements are shown in Example 5-22.
Dynamic proclibs can be added, modified, or removed by using the $ADD PROCLIB, $T PROCLIB
or $DEL PROCLIB commands.
The JES3IN DD statement on the JES3 procedure points to a single PDS member. The
operator can select a different member by replying M=xx to the IAT3012 message.
JES3 supports INCLUDE statements so that the system programmer can break up the
initialization deck into multiple members. For example, multiple members can be used to
isolate statements that change frequently, such as DEVICE statements for printers or
NJERMT statements, from the more critical parts of the deck.
JES3 supports the use of system symbols in its initialization statement, as does JES2.
However, the Global system is the only system that reads the initialization statements in
JES3, compared to JES2 where every system reads the initialization members. As a result,
the use of system symbols in the initialization deck is less likely in a JES3 environment than in
a JES2 environment.
A series of DYNALLOC statements for PROCLIBs in the JES3 initialization deck is shown in
Example 5-24.
By using the definitions that are shown in Example 5-24, jobs that are submitted by the
finance users can use their dedicated PROCLIB by specifying PROC=FI on the //*MAIN JECL
statement in their jobs.
If a JESplex uses TCP/IP to drive NJE connections, one or more network server address
spaces are started. A JES2 network server is named jesxSnnn where jesx is the name of the
owning JES2 address space and nnn is the subscript on the NETSERV(nnn) statement.
For example, the first network server on a subsystem names JES2 is JES2S001. A JES3
network server can have any name, although a common name is JES3S001. A network
server must be defined to the security product as a started task. IBM recommends the use of
a common name pattern for network servers so that only one security profile is needed.
Both JESs can have one or more writer functional subsystems (FSSs) defined. These FSSs
work the same way under JES3 and JES2.
An FSS can drive multiple printers. When a writer is called (JES3) or started (JES2), the
system checks to see whether the appropriate FSS is running. If it is not, the system starts it
automatically. An FSS cannot be started by using an operator command. The FSS ends
automatically when the last printer it is driving is shut down.
The JES3 start issues WTORs to determine the start type, and selects the initialization deck
for a hot start with refresh, warm starts, or cold starts.
Any automation routines that manage JES3 startup, shutdown, failures, or restarts must be
changed to address JES2 messages and commands.
Many automation routines key on JES3 initialization message IAT3100. These routines must
be changed to JES2 message $HASP492.
To create an installation-written exit routine, JES2 control structures and JES2 internal
processing knowledge and good programming skills are required. These exit routines must be
checked whenever a change is introduced in a JES2 control block or internal function.
The JES2 policies provide an alternative way to customize JES2 processing without requiring
in-depth programming knowledge, JES2 internal control structures, or an understanding of
the JES2 internal processing logic.
At a conceptual level, each JES2 policy definition describes a condition that is a logical
expression that determines whether this policy is applicable at a specific point in JES2
processing to a specific JES2 object, and one or more actions that must be performed if the
condition is satisfied.
A JES2 policy definition is imported into JES2 by a JES2 command and the policy becomes
available for JES2 processing.
JSON names must be coded exactly as specified. They are case-sensitive and do not allow
leading or trailing blanks. However, character values that are entered for the JSON names in
a policy definition are not case-sensitive and can contain any number of trailing or leading
blanks for readability, except for character literal strings that are delimited by single quotation
marks (apostrophes).
Attention: When coding a policy, it must be created in EBCDIC encoding by using the
code page 1047 only. If not, an error as shown in the following example can occur during
the import processing:
$POLICY IMPORT,PLCYLIB=POLICY00,MEMBER=JCONVERT
$HASP1600 POLICY IMPORT request accepted.
$HASP1630 JSON parser reported error 00000109, reason code 100. 030
Unexpected token parsing JSON value at offset 338.
$HASP1631 Location of error:. 031
" "definitions" : {"condition" : "Substr(JobNa"
.............................*.............................
$HASP1602 IMPORT request for policy *UNKNOWN failed.
“policyName” : “ policy-name” Defines a 16-character policy name. Policy name must be unique.
The policy-name must start with an alphabetic character and must
contain only alphanumeric characters (standard JCL rules).
“policyType” : “ policy-type “ Defines a 16-character policy type and must contain one of the
supported values. The policy-type determines a set of JES2 objects
and their attributes that can be used in the policy and the phase of
JES2 processing when this policy is considered. The policy-type
also determines the supported syntax of the rest of the policy
definition.
JobConversion A policy with type JobConversion takes effect at the end of the job
conversion phase and after all of the JCL for the job is processed.
CancelJob Applying this action, the current job that is being processed is canceled. This
action does not require any other JSON names.
HoldJob Applying this action places the current job in the hold status. This action does not
require any other JSON names.
Leave Applying this action leaves the current policy entirely. Processing resumes on the
next Policy in the concatenation.
LogMessage Applying this action sends a message to syslog only. This action does not change
any job attributes. This action requires the following JSON name to describe the
message to be sent:
“message” : “expression”
ModifyJob Applying this action assigns new value to a specific job attribute. This action
requires the following JSON names to describe the action:
“attribute” : “attribute-name”a
“value” : “expression”b
SendMessage Applying this action sends a message to operator. This action does not change any
job attributes. This action requires the following JSON name to describe the
message to be sent:
“message” : “expression”
a. The value of this JSON name is a character string with the name of the JES2 job attribute to be
modified.
b. The value of this JSON name is a character string with an expression that defines new value
for the attribute that is specified in the “attribute”. The result of this expression must be a value
of the same data type as the JES2 job attribute to which it applies.
For a policy to be processed by JES2, it must be in a PDS r UNIX PATH and then imported
and enabled by JES2.
To run these functions, more commands are available that are specific to manage the
policies.
The $ADD POLICYLIB command ensures only that the data sets specified can be allocated. It
does not ensure that they exist or can be opened and are usable.
Example 5-25 shows sample output from a $ADD PLCYLIB command that was used to add the
POLICY00 POLICYLIB concatenation to JES2.
Example 5-26 shows sample output of the $T PLCYLIB command that was used to add a
UNIX PATH to the existent POLICY00 POLICYLIB concatenation.
Example 5-27 shows sample output from a $D PLCYLIB command that was used to display
information about the existing POLICY00 POLICYLIB concatenation.
At the import process by JES2, the policy-name that is used on policyName JSON name is
set to imported policy. On further commands to manage the policy, the policyName that is
associated with the policy must be used.
Example 5-28 shows a sample output of the $POLICY IMPORT command that was used to
import and enable the JES2 Policy type JobConversion named JCONVERT. This policy was
coded in a UNIX path that was concatenated to PLCYLIB POLICY00.
Example 5-28 Sample of $POLICY IMPORT command used to import the JES2 Policy JCONVERT
$POLICY IMPORT,PLCYLIB=POLICY00,MEMBER=JCONVERT
$HASP1600 POLICY IMPORT request accepted.
$HASP1603 Validation of policy JCONVERT type JobConversion is 115
complete.
$HASP1611 Policy JCONVERT type JobConversion saved in the JES2 116
checkpoint.
$HASP1614 Policy JCONVERT type JobConversion added to runtime 117
repository.
$HASP1601 IMPORT policy JCONVERT request complete.
If the policy import command that is used to import the policy was not coded to include the
ENABLE subparameter, the policy is imported in enabled state and is immediately available
for JES2 processing. This option is the default option to ENABLE subparameter.
Example 5-29 Sample of $POLICY ENABLE command used to enable the JES2 Policy JCONVERT
$POLICY ENABLE,NAME=JCONVERT
$HASP1601 ENABLE policy JCONVERT request complete.
This command does not remove policy from JES2 configuration, but JES2 does not use this
policy until it is enabled again by the $POLICY ENABLE command
Example 5-30 shows sample output of the $POLICY DISABLE command that is used to disable
the JES2 Policy JCONVERT.
Example 5-30 Sample of $POLICY DISABLE command issued to disable a JES2 Policy
$POLICY DISABLE,NAME=JCONVERT
$HASP1623 Policy JCONVERT type JobConversion disabled.
$HASP1601 DISABLE policy JCONVERT request complete.
Example 5-31 shows sample output of the $POLICY DELETE command that is used to remove
the JES2 Policy JCONVERT from JES2.
Example 5-31 Sample of $POLICY DELETE command used to remove a JES2 policy
$POLICY DELETE,NAME=JCONVERT
$HASP1616 Policy JCONVERT type JobConversion deleted.
$HASP1601 DELETE policy JCONVERT request complete.
The policy was coded by using EBCDIC 1047 code page in a UNIX path.
Example 5-33 shows the sample JCL that was used to validate the processing of JES2 Policy
JCONVERT created.
Example 5-33 Sample JCL used to test the JES2 Policy JCONVERT
//#REDJES2 JOB (),'ITSO REDBOOKS',CLASS=A,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=IEFBR14
Example 5-34 shows the messages that are issued to Operator’s Console during the
processing of a job that is selected by the JES2 policy and complementary exits 11 and 12
that are installed to manage the spool partitioning processing. For more information about
exits 11 and 12, see Appendix E, “SPOOL partitioning exits sample code” on page 233.
Example 5-34 Messages issued to OPERLOG during Job processing and by JES2 Policy JCONVERT
$EXT1108I JOBCLASS A ALLOWED TO USE SPOOL PARTITION BY JOB #REDJES2
ON SYSID SC74
IEF196I $EXT1108I JOBCLASS A ALLOWED TO USE SPOOL PARTITION BY JOB
IEF196I #REDJES2 ON SYSID SC74
$EXT1101I JOB #REDJES2 SELECTED TO USE SPOOL PARTITION ON SYSID SC74
IEF196I $EXT1101I JOB #REDJES2 SELECTED TO USE SPOOL PARTITION ON
SYSID
IEF196I SC74
$EXT1103I VOLUME BH5SP1 ADDED TO JOB #REDJES2 AS OVRFLOW SPOOL VOLUME
IEF196I $EXT1103I VOLUME BH5SP1 ADDED TO JOB #REDJES2 AS OVRFLOW SPOOL
IEF196I VOLUME
$HASP100 #REDJES2 ON INTRDR ITSO REDBOOKS FROM TSU01402
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
PLCY001I Job #REDJES2 now have priority 15 and Affinity to (SC74)
Detachment JES3 Exits Identify all used JES3 exits We recommend starting the
Identify all used PSF printing removal of JES3 exits as soon as
exits possible.
Create migration strategy
(removal or transformation to
exits)
Create needed JES2 exits
Changes for JCL/JECL Convert production JCL Try to align your production JCL to
Provide tool to convert user JCL work with both JES versions. This
alignment can be done as soon as
possible and features no
dependencies.
Security changes Add JES2 security profiles to The RACF permissions that are
RACF defined for JES2 should match to
Assign permissions to profiles that being made or exist for
stakeholders SDSF/EJES.
Add SDSF/EJES profiles to
RACF
Add profile definitions for
changed printer names
System automation Analyze JES3 automation that This task can take some time
is in place because you must review all
Setup new JES2 automation automation points that you defined
for JES3. Then, you must decide
whether this task must be
transferred to a JES2 solution.
JES printing Analyze printing environment Consider some extra time to create
Code new JES2 print exits JES2 exits and conduct printing
Adjust procedures for printing tests. We faced some unplanned
that uses JES3 commands issues that needed to be sorted.
JES2 setup Define JES2 setup according to This task can be done during
your company defaults normal system operation time.
Calculate needed storage and JES2 can be run in parallel to JES3
request DASD for all systems as secondary subsystem. You
Request all other resources that should calculate some time to
you need (HLQ, RACF, and define all the standards you need
STC) for the JES2.
Request TCP/IP and firewall
settings for NJE
Start JES2 on all environments
to verify the function
General things to do Provide education material These tasks are an important part
Conduct education sessions of the project. To get the most
Quit your JES3 license possible acceptance for the project
from all stakeholders, you should
conduct information session at the
earliest point in the start process.
You also should frequently update
stakeholders.
Most of the tasks that are listed in Table 6-1 on page 114 can run in parallel and have almost
no dependencies to each other.
The sysplex environment contains the classic structure from sandbox sysplex over test
sysplexes to the production sysplex. The entire migration was done in approximately six
months.
Print Engineering P rint Control Tool for JES3 spool handling Hand over of software res ponsibility to Print Engineering
Analyze of and support by development of new Pr int Control Tool
Print Operating Changed JES c apabilities specific educa tion sessions will be offered
O ther JES Commands & Messages specific educa tion sessions will be offered
Sl ightly differ ent SDSF panels Hands on Trai ning
New Printer Control Tool Hands on Trai ning
Batch Design & Sl ightly differ ent SDSF panels Hands on trai ning
Scheduling JES2 has a minimally different process ing logic A presentation of relevant differences will be publ ished and distributed as a
Management and other Job Entry Contr ol statements guideline for future JCL development
Application JCL (eg. for EoD) with very few Analysis of ex isting JCL and development of migra tion tool
JES3 control s tatements Ex isting JCL will be migrated by projec t team in every environment before JES2 is
ac tivated. Not e: Modified JCL can run under JES3 as well as JES2
JCL must be c oded according to JES2 s yntax and rules after JES2 activation
Perhaps priva te JCL with JES3 statements A tool for migration and instructions for its usage will be provi ded by the project
After the stakeholders are identified, you assign all the necessary tasks to them and publish a
final date of completion to bring the project to success. An example of tasks that must be
done by every stakeholder is shown in Figure 6-2.
CAS Confir mation “rea dy for production” of Change Man & other tools
Batch Hosting Confir mation “rea dy for production” of all relevant tools
Job Entry Control Language is distinct from job control language (JCL), it instructs the operating system
how to run the job:
− For JES2 JECL statements start with / , for JES3 they start with / / , except for remote / SIGNON
Job Control and / SIGNOFF commands.
− Note: JES2 can handle almost all of your JES3 JECL statements. Examples:
/ / *MAIN … and / / *FORMAT … statements will be honored by JES2
/ / *MAIN CLASS=… will be honored too and replace the Job Class coming from JCL JOB statement
Third-party products
Almost every customer is using third-party software on their mainframes. All of this software
must be checked for the JES2 compatibility and adjusted so that it is compatible, if necessary.
For this task, contact the software vendor as soon as possible for written proof of
compatibility.
CONTROL-M
If you use CONTROL-M instead of Tivoli Workload Scheduler for controlling your BATCH
processing, you must tell CONTROL-M that it must operate with JES2. A portion of the
IOAPARM data set of CONTROL-M with the JES3 definitions is shown in Example 6-1.
EJES
The most common third-party product for JES3 users is EJES. To enable JES2 support in
EJES, you can APPLY the EJES$ENV USERMOD that is included with the product. The
following USERMODs are suitable for JES2 and JES3 products:
EJES$ENV USERMOD for the EJES environment for JES2 and JES3
EJES$EN2 USERMOD for the EJES environment for JES2 only
EJES$EN3 USERMOD for the EJES environment for JES3 only
This job installs the USERMOD that generates the system environment tables. EJES$ENV is
used when support for JES2 and JES3 is being generated. The EJES$ENV job can be useful
during migration to support both JES versions. After the final deactivation of JES3, you can
update your SMP/E environment to use EJES$EN2 only.
In sysplex installations, EJES is using a so-called Coordination Address Space (CAS) server
to exchange data between all systems within a sysplex. This CAS needs a global data set
(see Example 6-3), which is shared by all EJES participants under JES3.
Attention: You must plan and adjust your EJES/SDSF security definitions because of
added, changed, or deleted panels or fields that can be typed over in panels. These
modified settings must be in line with your JES2 security settings.
ACF2
The customer installation was protected by ACF2 instead of RACF during migration to JES2.
To establish the JES2 support in ACF2, you must activate several exit routines according to
the ACF2 installation guide. The requested ACF2 user exits that must be loaded in JES2 are
shown in Example 6-5.
ThruPut Manager
In the customer environment, a case study for using Compuware ThruPut Manager was
conducted at the time of migration. ThruPut Manager can help automatically and intelligently
optimize your batch processing by balancing workload and improving batch throughput.
/*-------------------------------------------------------------------*/
/* Load JES2 Exits requested by ThruPut Manager */
/* and set default initialization parameter using TMPARM */
/*-------------------------------------------------------------------*/
LOADMOD(DTMJ2MV7) STORAGE=PVT /* LOAD MAIN TASK EXIT MODULE */
LOADMOD(DTMJ2SV7) STORAGE=CSA /* LOAD SSSM EXIT MODULE */
EXIT(2) ROUTINE=(DTMJ2X02,ACFEXIT2),STATUS=ENABLED,TRACE=NO
EXIT(4) ROUTINE=(DTMJ2X04,ACFEXIT4),STATUS=ENABLED,TRACE=NO
EXIT(5) ROUTINE=(DTMJ2X05),STATUS=ENABLED,TRACE=NO
EXIT(7) ROUTINE=(DTMJ2X07),STATUS=ENABLED,TRACE=NO
EXIT(8) ROUTINE=(DTMJ2X08),STATUS=ENABLED,TRACE=NO
EXIT(10) ROUTINE=(DTMJ2X10),STATUS=ENABLED,TRACE=NO
EXIT(14) ROUTINE=(DTMJ2X14),STATUS=ENABLED,TRACE=NO
EXIT(19) ROUTINE=(DTMJ2X19),STATUS=ENABLED,TRACE=NO
EXIT(24) ROUTINE=(DTMJ2X24,ACFEXT24),STATUS=ENABLED,TRACE=NO
EXIT(49) ROUTINE=(DTMJ2X49),STATUS=ENABLED,TRACE=NO
EXIT(51) ROUTINE=(DTMJ2X51),STATUS=ENABLED,TRACE=NO
EXIT(52) ROUTINE=(DTMJ2X52,ACFEXT52),STATUS=ENABLED,TRACE=NO
EXIT(54) ROUTINE=(DTMJ2X54,ACFEXT54),STATUS=ENABLED,TRACE=NO
TMPARM COMCHAR=/, /* TM COMMUNICATION CHARACTER */
TYPHOLD, /* TYPRUN=HOLD JOBS 1ST ANALYZED THEN HELD*/
TYPSCAN, /* TYPRUN=SCAN JOBS 1ST ANALYZED THEN HELD*/
CUSTOM=(UM0035), /* RETAIN PRE-TM EXECUTION CLASS IN SMF30 */
OPTIONS=(OFF(DCS)), /* DISABLE DATASET CONTENTION SERVICES */
TMINITS=(3,12,,2) /* 3X100 $$TM DYNAMIC INITS MAX PER LPAR */
/* 12 HRS OR 1000 JOBS BEFORE INIT RECYCLE*/
/* 2X DYNAMIC ANALYZERS INITS PER 100 JOBS*/
Figure 6-4 Sample JES2 TM initialization
Attention: All JES2 exits must be compiled and linked with the JES2 version that is
running.
All JES2 exits have one thing in common: The exits must be compiled or linked with the same
JES2 version they plan to use. A mismatched JES2 stops initialization (see Figure 6-5).
Consider moving these z/OS level-dependent modules to a separate library and concatenate
them in front of the Thruput manager base load library DTMLINK.
Thruput Manager must work correctly to separate job classes. Some examples from a
customer’s installation are shown in Figure 6-6. The Jobclass names can vary in other
installations.
JOBCLASS(TMA,TMG,TMO) COMMAND=IGNORE,
MSGCLASS=E, /* DEFAULT MESSAGE CLASS */
MODE=JES /* JES INIT'S */
Figure 6-6 Jobclasses for Thruput manager
After restarting JES2 with the new exits and jobclass definitions, you must complete the initial
configuration. The Thruput manager initial commands that are used to configure the basic
jobclass selection are shown in Example 6-6.
The response of Thruput manager after defining all jobclasses is shown in Figure 6-7. The
jobclasses can vary in your environment.
$MJ,TM,CLASS,D
DTM3233I TM CLASS LIST 039
Analysis............ TMA
Deferred............ None
Selectable.......... TMA,TMG,TMO
Exempt.............. A,M,M1,P0,P1,P2,P3,S0,S1,S2
On_Demand........... TMO
Production_Services. None
General_Services.... TMG
Default............. None
$MJ,START
Figure 6-7 TM setup verification
After these steps are completed, you now can start Thruput Manager in your system.
If you cannot send more systems to a sysplex, consider starting JES2 as a secondary
subsystem and keep JES3 as the primary, as shown in Figure 6-10.
Matching these components avoids problems after the migration process in many other areas
that use fixed nodes or system names.
PARMLIB
JES2 is controlled in its configuration by a standard PARMIB member. To reduce the efforts
for future maintenance, we recommend placing all common parameters in one member. All
other system-specific control statements should be placed in a second PARMLIB member. If
you consider operating with a JES2 printer, we recommend placing all of the printer
definitions in a third PARMLIB member.
Hint: If you are moving most of the JES2 configuration statements to a common PARMLIB
member, use system symbols.
CKPTDEF NEWCKPT1=(DSNAME=JES2#A.&SYSNODE..&JESENV.0.CKPT1NEW,
VOLSER=SYA411)
CKPTDEF CKPT2=(DSNAME=JES2#A.&SYSNODE..&JESENV.0.CKPT2,
VOLSER=SYA410,INUSE=YES)
CKPTDEF NEWCKPT2=(DSNAME=JES2#A.&SYSNODE..&JESENV.0.CKPT2NEW,
In comparison to earlier releases of JES2, you can now use compression for any output class
in your installation to lower SPOOL space. In Figure 6-9 on page 123, you see that
compression is enabled for all JES2 output classes.
PROCLIB
The guidelines that we applied to the PARMLIB can be used for the PROCLIB definition. The
JES2 start procedure was made flexible to address many needs. An example is shown in
Example 6-9.
P You specify the wanted start mode of JES2. The default is a JES2 warm start if
no parameter is passed. P=COLD proceeds a JES2 cold start.
R This option allows you to start JES2 automatically without showing you a
$HASP400 ENTER REQUESTS message. If pass R=REQ to the start
procedure, JES2 prompts the message and waits for replies.
M With this parameter, the type of primary JES2 parmlib member that should be
used for this start can be controlled. In our example, you pass a suffix to the
procedure that concatenated the JES2 parameter member that is called
JES2Pxx to the final member name.
JE This parameter controls the type of JES2 you want to use. In this case study, we
used two different configurations: One for test purposes and the other for
production. This parameter also can be controlled by an external system
symbol.
JO With this parameter, you can activate a type of logging of all parameters that are
passed to JES2 during start and store them in a separate data set or GDG.
RZ This parameter can be used for allocating system-specific data sets (logs)
during start.
The parameters that are listed in Table 6-2 are recommendations to demonstrate the flexibility
of JES2. They can be changed or extended based on customers needs.
Initiators
The calculation for the new JES2 initiators is based on the system layout under JES3.
Attention: If you plan the JES3 migration from a version of z/OS before V2R1, consider
upgrading your system to at least z/OS V2R1 level first. With this release, JES2 supports
eight-character job classes instead of one-character as in releases that are older than
V2R1.
In Example 6-7 on page 124, we define 200 initiators per system by default. This amount is
much higher than needed. This high number of initiators is used so that spare initiators can be
defined in case more are needed. As shown in Example 6-7 on page 124, initiators 101 - 200
are defined with the START=NO option.
Checkpoint
A single resource is available in JES2 that is called CHECKPOINT. This resource is used to
share relevant JES2 information across all participating JES2 MAS members in the sysplex.
Each of the participating JES2 members has a dedicated, defined time to access the
checkpoint.
Attention: The JES2 checkpoint is a sensitive resource and requires careful handling. If it
is not set properly, it can cause serious problems later. Also, we recommend placing the
backup for CKPT1 on DASD instead of using an alternative CF structure.
Have a backup for CKPT1 and CKPT2 available. For safety reasons, the backup for both
CKPT1 and CKPT2 should be allocated on separate DASD volumes other than the primary
CKPT1 and CKPT2. The resulting checkpoint definition that is based on the configuration is
shown in Example 6-10.
$HASP829 NEWCKPT1=(DSNAME=JES2#A.RZ4.P0.CKPT1NEW,
$HASP829 VOLSER=SYA412),
$HASP829 NEWCKPT2=(DSNAME=JES2#A.RZ4.P0.CKPT2NEW,
$HASP829 VOLSER=SYA411),MODE=DUPLEX,DUPLEX=ON,LOGSIZE=1,
$HASP829 VERSIONS=(STATUS=ACTIVE,NUMBER=50,WARN=80,MAXFAIL=0,
$HASP829 NUMFAIL=0,VERSFREE=50,MAXUSED=2),RECONFIG=NO,
$HASP829 VOLATILE=(>
SPOOL
The JES2 SPOOL should be placed on dedicated volumes to avoid any ENQ or RESERVES
from others to that data sets or DASD. The SPOOL size depends on your environment and
should also include a reserve space. In our experience, the SPOOL space usage between
JES2 and JES3 is approximately the same; however, under JES2, we used double the
SPOOL space size as we did under JES3. The SPOOL values are compared in Table 6-3.
Number of DASD 31 8
Note: We did not see any performance issue when the number of SPOOL volumes was
decreased compared to the JES3 setup.
The SPOOL definitions are set according to the IBM recommendations, as shown in
Example 6-12.
NJE
The NJE setup was copied from the previous JES3 setup. All node names remain the same to
be compatible with all your applications that use node names. No other actions are needed
here, except if your are planning to transfer spool data sets during migration from JES3 to
JES2.
Attention: In comparison to JES3, every JES2 instance features its own NJE NETSRV.
Therefore, more than one NETSRV is active in a sysplex at the same time. This
configuration caused misleading messages to appear on the console.
It is recommended to control the JES2 NETSRV with your system automation. You must be
sure that only one NETSRV server is active at the same time in the sysplex. The system
automation should control the JES2 NETSRV by using the $SNET and $SNETSRV1 commands.
With this cold start, all checkpoint data sets and your SPOOL are initialized and cleared. This
task can be done under JES3 as primary subsystem by configuring JES2 as a secondary
subsystem in your system. An example of a JES2 cold start is shown in Example 6-13.
Information: In customers’ environments, a JES2 cold start with eight 3390-54 volumes
that are defined for SPOOL took almost 9 minutes to complete.
It is suggested to provide a general education session for stakeholders that can include the
following topics:
JES2 overview: JES3 differences:
– JES2 overview: Multi-access Spool
– JES3 overview: Complex
– JES2: Data sets
– JES3: Data sets
– JES2: Control
– JES3: Control
JES2 start and control:
– Multi-access Spool: XCF
– JES2 initialization
– JES2 procedure
– JES2 control START: COLD
– JES2 control START: WARM
– JES2 warm start types
– JES2 address spaces
– JES2 control stop
– Poly/Secondary JES2
– JES2 functions: JES3 migration
– What JES2 does
– What JES3 does
– JES2: JES3 differences
JES2: A job life:
– Job phases
– Input: Submit
– Conversion
– Conversion and interpretation
– Waiting on conversion: TYPRUN=JCLHOLD
– JCL error: TYPRUN=HOLD
The basic education session is held at the beginning of the migration project and often is
repeated shortly before the migration starts. As the same time, the following special education
sessions can be added for your subject matter experts:
System Engineering z/OS:
– How JES2 works
– Dealing with SPOOL and checkpoint
– Checkpoint reconfiguration
– How to do performance analyses
– Restart and recovery
Operators:
– JES2 startup and shutdown
– Most important JES2 commands for operation
Print operators:
– Most important JES2 commands for printing
– Dealing with printers
– Managing JES2 output
Important: All newly created JES2 exits must be on the same software level, such as the
destination JES2 level.
The execution environments for JES2 exits are listed in Table 6-4.
1 JES2 Main task Included in the module HASJES20. It is loaded into a private area of
JES2 and run under the control of JES2 (in HASPNUC). Use the JES2
macro $WAIT instead of the MVS WAIT macro. JES2 Dispatcher
controls all processing within the main task environment. MVS WAITs
only in JES2 exits 0, 19, 24, and 26 (according to the IBM manual).
2 JES2 Sub task Run in the private area of JES2 address space but run asynchronously
with the JES2 main task, WAIT, and POST operation and system-wide
MVS Services are available.
Many JES2 main task data areas are directly addressable, but users
of these resources must understand when and where serialization of
these resources is relevant.
3 User Environment In common storage and run in the users address space. System-wide
MVS Services are available. The environment is more complex and
includes many integrity, synchronization, locking, and cross-address
space communications considerations.
JES2 can install or activate a maximum of 256 exits. EXIT 1 - EXIT 60 are provided by IBM,
although the samples do not always correspond to what is expected as good examples.
The exits have their own macros (usually $xxx) and these macros can cause problems when
used with MVS macros. In exit 6, we wanted to use the Macro TCB. A collision occurred
because parts of the TCB macro are used in the JES2 macros, which did not display the
HLASM during the assembly. Instead, it stopped the assembly without writing out any
warning.
The JES2 control blocks, which are described in the JES2 Data Areas manuals, are a good
way to access important data. In the JES2 exits, for example, the JOBNAME can be found by
using the field JCTJNAME, which completely replaces the variant to be run by using MVS
control blocks.
The exits can also change data in the control blocks or pass data on to the following exits; for
example, JCTXMASK in the JCT, which can be changed by each exit (for example, EXIT 52).
We attempted to avoid a GETMAIN or STORAGE OBTAIN in all our previously programmed
exits because this configuration seemed to us to be a considerable burden for the systems
with the expected exit calls.
Because the exits need many registers (GPR or GR) for addressing JES2 control blocks, one
should have more than 16 registers available for programming.
In programs that do not run in AMODE 64, the right part of the registers (bit 32 - 63) can be
moved to the left part (bit 0 - 31) with the OP instructions SLLG or SRLG to save the registers.
We used this kind of register storage several times in exits 52, 54, and 6.
Attention: Because exits are also used with the TSO Logon, it might be impossible to
perform a logon in the TSO in certain situations.
When programming the exits, they almost always are called in supervisor status and run in
key 0 or key 1, depending on the environment. Key 0 and supervisor status can lead to
problems if errors occur (some common storage areas are overwritten unintentionally).
Hint: The exits should be defined as a user modification so that they can be imported by
way of SMP/E.
IATUD05 DSP II/ INQUIRE INITS No carry over; function does not
exit under JES2
Many of these exits belong to JES3 unique functions and do not feature anything to migrate
(see Example 6-16).
Attention: JSON names are case-sensitive and must be entered exactly as defined.
{ "policyName": "CONVPOL11",
"policyVersion": 1,
"policyType": " JobConversion ",
"definitions":
[
{ "condition" : " JobHasAffinity('SC74') ",
"actions" :
[
{ "action" : " modifyJob ",
"attribute" : " SYSAFF ",
"value" : " listAdd(sysaff, 'SC75') "
},
{ "action" : " SendMessage ",
"message" : " 'New job affinity is ' || string(SYSAFF) "
}
]
}
]
}
After importing and activating these policies into JES2, all jobs that are running through the
converter are checked for system affinity to system SC74 (in this case).
If a system affinity to system SC74 is detected, the incoming job is modified in terms of
changing the system affinity to system SC75. A separate message also is displayed that
informs the customer that this particular job was modified by JES2.
At the time of this writing, only policytype JobConversion is available for use.
IATUX45 HASX23A Exit is needed to pass JES2 information to the FSS routine.
APSUX01 APSUX01 PSF Header exit that must be created according to your
requirements.
APSUX02 APSUX02 PSF Trailer JES2 exit that must be created according to your
requirements.
APSUX03 APSUX03 PSF Header JES2 exit that must be created according to your
requirements.
APSUX06 APSUX06 PSF Message exit that must be created if you must change PSF
messages before they are sent to console.
Information: Most of these functions, such as DJC and MDS, can be disabled before the
JES3 migration is started. Doing so makes the migration more agile and less prone to
error.
Success or failure of one job can result in execution, holding, or cancellation of other jobs.
This function is intended to implement some dependencies while running jobs. If possible, all
of those jobs should be moved in your professional BATCH scheduling system before
migrating JES3.
To identify those job candidates in your system, we suggest scanning your OPERLOG or
DLOG for the last year for such messages, as shown in the following example:
IAT6160 JOB NET xxxx NOW ENTERING SYSTEM
IAT6100 (JOB25676) JOB xxx (JOBxxxxx),PRTY=01,ID=LUTZ NET-ID=xx SUB=JOB25494
The professional BATCH scheduling system is sometimes not useful or flexible, especially for
engineering jobs. Since z/OS V2R2, the user can use the new JES2 job group function (see
Example 6-15 on page 144).
As shown in Example 6-15, four jobs that are defined in a JES2 job group that is named
LUTZ. Each of the participating jobs in that job group must be defined by a JCL GJOB
statement and (optionally) a condition.
After submitting the group of jobs, you should see the successfully registered messages from
JES2, as shown in Example 6-16.
Based on Example 6-15, we show you the same logic in Figure 6-14 on page 145.
Yes
RC=0 A710JOBB
No
A710JOBD
Yes
RC=4 A710JOBC
No
End of Jobgroup
Figure 6-14 Visual example of the job flow
Upon completion, you should see messages similar to the example that is shown in
Example 6-17. This example shows the start of job A710JOBA and its end with RC=0000.
This issue caused two results: First, the A710JOBC is canceled because of the mismatch of
the return code; second, A710JOBB was released. After A710JOBB was finished, A710JOBd
is released.
After migrating all your jobs by using DJC, you should disable that function in your JES3
environment to prevent the future usage.
DEADLINE
To identify those job candidates for DEADLINE scheduling in your system, we suggest
scanning your OPERLOG or DLOG for the last year for such messages, as shown in the
following example:
IAT7401 DEADLINE DSP UNABLE TO COMPLETE FAILURE PROCESSING AFTER ABEND
IAT7405 INVALID COMMAND TO DEADLINE
IAT7410 DEADLINED JOBS ARE STILL IN THE SYSTEM.
IAT7415 JOB jobname (id) HAS INVALID DEADLINE TYPE(t), DEADLINE ENTRY NOT UPDATED.
IAT7420 START DEADLINE COMMAND ACCEPTED
IAT7425 JOB - IS PAST ITS DEADLINE
IAT7430 ALGORITHM - t - RUNNING FOR JOB jobname (id)
IAT7440 ERROR READING DEADLINE QUEUE, ALL ENTRIES LOST
IAT7445 ERROR READING DEADLINE QUEUE, UNDETERMINED NUMBER OF ENTRIES LOST
IAT7450 JOB jobname (id) PURGED
IAT7451 JOB jobname (id) IN PURGE WITH UNPROCESSED INTRDR JOBS, REPLY WAIT OR
CONTINUE
IAT7452 INCORRECT REPLY
IAT7455 OSE PURGE ERROR FOR JOB jobname (id)
If the investigation is complete, analyze the output and extract job names and the assigned
user ID of that job. Now, you can address the need of transforming those jobs straight to the
affected users by using the jobs user ID.
The professional BATCH scheduling system is sometimes not useful or flexible, especially for
engineering jobs. Because many installations in the field use JES3 DEADLINE scheduling to
release jobs in a timely manner, a replacement for DEADLINE under JES2 is needed.
JES2 provides a basic equivalent to the JES3 DEADLINE function. The JES2 SCHEDULE
function can be used in several ways to release jobs for a certain time or date.
Important: We offer you a free of charge REXX-based tool that runs as a server in a
sysplex and replaces the JES3 DEADLINE Function. Your JCL DEADLINE user can
continue to run with its JES3 DEADLINE card and run unchanged under JES2.
A JES2 JCL that uses the new SCHEDULE function is shown in Example 6-18.
You can code a certain date and time when a job is intended to run, or you can code a
displacement time. If the assigned time is past the current day, it runs on the next day.
Consider the following points:
The first SCHEDULE holds the job until 05/28/2018 12:50. After passing that time stamp, it
is released by JES2. JES2 attempts in parallel to run by the latest 13:00 at the same day
by increasing its priority, if needed.
The second SCHEDULE holds the job until 05/28/2018 12:40. After passing that time
stamp, it is released by JES2. JES2 does not try any other action to promote the job.
Based on the system utilization, it cannot be guaranteed that the job is running then.
The third SCHEDULE releases the job 1 hour later than the job was submitted to the
system.
Restriction: The new JES2 DEADLINE support replaces most of the JES3 DEADLINE
functions. As of this writing, it is not possible to use the cycle function for jobs. Therefore,
the WEEKLY, MONTHLY, and YEARLY options are not yet available. You can disable MAIN
DEADLINE processing under JES2 by setting up JECLDEF JES3=(MAIN=IGNORE).
If you use tape virtualization, it is reasonable to assume that you have more virtual tape drives
than you use at one time; therefore, disabling MDS likely has no visible effect on job
throughput. Even so, it is prudent to make this change before the migration so that if it does
cause a problem, you can re-enable MDS while you investigate ways to address the problem.
Important: If you use MDS to control the order of running jobs or control job
dependencies, JES2 does not provide an equivalent function. You must eliminate its use
before you migrate to JES2.
Attention: All of the *I S JES3 commands no longer work when SETUP=NONE is in place
in your JES3 configuration. You should remove these commands from system automation
and user-written REXX programs.
With this change, jobs are no longer checked in advance for all resources that they need.
Therefore, jobs start, such as under JES2, and obtain data set allocation at the time they
needed.
Disk reader
The disk reader function submits JCL from a PDS to the internal reader by using a JES3
command. Many parameters are available to control the set of submitted jobs.
Information: The disk reader facility (DR) is enabled by placing a //JES3DRDS DD card in
the JES3 PROC or by specifying DYNALLOC,DDN=JES3DRDS,DSN=dsn in the JES3
inish deck. It is started by using the *X DR M= command, so a search in SYSLOG might be
required to determine whether this facility is being used.
Starting with z/OS V2R4, you can use the new diskreader support that is provided by IBM.
This support is similar to the JES3 diskreader support. To enable the support, add two
statements in your JES2 initialization member (see Example 6-19).
SUBMITLIB(SLTEST) DD(01)=(DSNAME=LUTZ.SUBLIB.TEST),UNCONDITIONAL
SUBMITLIB(SLPROD) DD(01)=(DSNAME=LUTZ.SUBLIB.PROD),UNCONDITIONAL
SUBMITRDR AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),
CLASS=A,DD_DEFAULT=SLTEST,HOLD=NO,
PRTYINC=01,PRTYLIM=08,
TRACE=NO
You add all regular z/OS data sets you want to be used for the JES2 diskreader. The
SUBMITLIB statement follows the known PROCLIB initialization statement. Optionally, you
also can code a UNIX System Services path that points to a directory that contains JCL.
Note: You can use more than one SUBMITLIB statements in your JES2 initialization
member to separate test and production data sets. They must have different DD names.
The functions that are listed in Table 6-8 are rarely used in customer environments and
should not affect a JES2 migration project.
JES3 DLOG
The JES3 DLOG function must be removed before you migrate to JES2. JES2 operates only
with the z/OS OPERLOG function. Therefore, start the migration from DLOG to OPERLOG
as soon as possible.
The equivalent of starting a JES2 printer by using the OPERLOG function is shown in
Example 6-22.
The main differences that you see is the message header of both examples. Different
information is available and in another location inside the message header. For example, the
time is in another location, uses another format, and includes more information in OPERLOG
than in DLOG.
Important: Before you can migrate DLOG to OPERLOG, you must analyze which tools or
custom-made programs that use DLOG must be converted to OPERLOG capabilities.
Information: The intention of migrating our jobs was to align the JCL and JECL in a way
that works with both JES versions.
Before you begin, inspect your production JCL data sets for the occurrence of JES3 JECL
cards. For more information about all possible JES3 JECLs, see Chapter 4, “JES2 functions
to help migration” on page 43.
The next step can find a replacement of that JES3 JECL. In the most current release of z/OS,
most of the JES3 JECL statements are honored and processed, if needed. Therefore, JES3
JECLs do not need to be converted to their JES2 equivalent (if they exist).
The support levels for JES3 JECLs are listed in Table 6-9.
Not supported An error message is generated and the job is given a JCL ERROR.
The most current support of JES3 JECL cards in your JCL is listed in Table 6-10.
BYTES Supported
CARDS
CLASS
HOLD
JOURNAL
LINES
ORG
PAGES
PROC
SYSTEM
USER
DEVPOOL, Obsolete
DEVRELSE
RELSCHCT/RS
If you use JES3 JECL statements in your JCL that do not include an equivalent under JES2,
these statements must be changed manually. To give users of such JES3 functions the ability
to convert their JCL to a JES2 conforming JCL, we provide a sample REXX executable that
addresses this need (for more information, see Appendix A, “Sample JES3 exit to analyze
JECL usage” on page 195). This sample code demonstrates how to convert such functions in
JCL and must be adjusted based on your needs.
Attention: At this point, unusual converted JCL and JECL were observed. Therefore, it is
recommended that your system is closely monitored after migration. For more information,
see 6.12, “Hints and tips” on page 172.
The REXX program transforms the JECL in the same way as the professional program that
we used for the production JCL.
Your JES2 settings determine the behavior of your JCL and how JES3 JECL cards are
handled. By default (or if you do not code anything), all JES3 JECL cards are processed by
JES2.
For most JES3 JECL statements, you can control how JES2 handles that statement.
PROCESS The specific JES3 JECL statement is processed (translated or directly processed).
This option is the default.
WARN The specific JES3 JECL statement is processed, but a warning message is issued
that indicates that the installation intends to discontinue use of this statement in the
future and that it should no longer be used.
FAIL An error message is generated for the specific JES3 JECL statement. The job does
not run.
IGNORE The specific JES3 JECL statement is ignored and treated as a comment.
First, create a list of all monitored items that are active in your system automation, which
might include the following items:
Alarms that set for certain JES3 messages.
Custom REXX programs that perform any kind of JES3 monitoring.
Native JES3 commands that are issued frequently.
Custom REXX programs to conduct predefined tasks; for example, moving JES3 GLOBAL
to another system.
Upon completion, assign the following tasks that must be done for migration:
Removal of the function; for example, all items that are related to JES3 specialities (JES3
GLOBAL).
Transfer the function to a JES2 version.
Find the appropriate JES2 message for JES3 to monitor and add any JES2 messages that
you want to be monitored.
Attention: This process is ongoing and must be reviewed frequently. It has no claim to
completeness.
For the beginning when JES2 is used, you can put the messages that are listed in Table 6-13
in your system automation. This inclusion should prevent the most important JES2 cases that
influence the stability of JES2.
$HASP121 jobname device name ERROR RECEIVING NETWORK JOB HEADER RC=rc
jobname device name ERROR RECEIVINGNETWORK DATA SET HEADER RC=rc
jobname device name ERROR RECEIVINGNETWORK JOB TRAILER RC=rc
$HASP263 WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME volser LOCK HELD BY
MEMBER member_name
WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME volserLOCK HELD BY
SYSTEM
WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME volserSYSTEM
MANAGED PROCESS ACTIVE
$HASP292 MEMBER member-name JES2 WAITING FOR RESPONSE TO READ FROM ckpt
MEMBER member-name JES2 WAITING FOR RESPONSE TO WRITE TO ckpt
MEMBER member-name JES2 WAITING FOR RESPONSE TO FORMAT OF ckpt
MEMBER member-name JES2 WAITING FOR RESPONSE TO EXTEND OF ckpt
MEMBER member-name JES2 WAITING FOR RESPONSE TO I/O TO ckpt
$HASP375 Job name ESTIMATED metrics EXCEEDED job name ESTIMATE EXCEEDED BY
nnn metrics xxx% SPOOL
$HASP492 The general JES2 start message that indicates JES2 is started.
$HASP496 This message indicates a mismatch between the saved initialization in the checkpoint
compared with the JES2 initialization PARMLIB configuration during JES2 startup.
$HASP531 Job name: Devname INVALID DATA BLOCK DETECTED TRANSMITTER devname
ON NODE nodename
$HASP565 General message that indicates that no NJE connection was established to the
partner node
$HASP9207 This message can indicate that an alert or an incident JES2 is tracking.
$HASP829 NEWCKPT1=(DSNAME=JES2#A.RZ4.P0.CKPT1NEW,
$HASP829 VOLSER=SYA412)
$HASP829 NEWCKPT2=(DSNAME=JES2#A.RZ4.P0.CKPT2NEW,
$HASP829 VOLSER=SYA411),MODE=DUPLEX,DUPLEX=ON,LOGSIZE=1,
$HASP829 VERSIONS=(STATUS=ACTIVE,NUMBER=50,WARN=80,MAXFAIL=0,
$HASP829 NUMFAIL=0,VERSFREE=50,MAXUSED=2),RECONFIG=NO,
$HASP829 VOLATILE=(>
If such a situation occurs, you run without any backup checkpoint available. To avoid this
situation, monitor the JES2 message as listed in Table 6-15.
Under JES2, such options for output classes are not available. In the customer project, we
implemented a solution that is based on system automation.
A timer periodically sends a JES2 command to the system that changes the destination of
certain output elements. Some JES2 sample commands from the customer environment are
listed in Table 6-16. These commands change all output elements in the specified sysout
class.
$TO JOBQ,/Q=T,/AGE>3,Q=O All output elements in sysout class T are moved to class
0 if older than three days.
Attention: If you must transfer many output elements, consider issuing the commands
more often. Doing so avoids the situation in which JES2 is busy for extended periods in
processing the request.
ISFPrefix = "**"
ISFOwner = "**"
DestPlex = 'PLEXQ'
Address SDSF "ISFEXEC O"
Do i=1 to JNAME.0
if SCLASS.i = '2'
Then Do
Address SDSF "ISFACT O TOKEN('"TOKEN.i"')",
"PARM(DEST" DestPlex!!"."!!DEST.i")"
End
End
rc = ISFCalls('OFF')
exit
The differences while transferring output to another system by using the JES2 command and
the REXX program are listed in Table 6-17.
Change this REXX program to suit your needs and place it in your system automation based
on your needs. The program should run with more or less frequency.
It is recommended to place all of the profiles that are listed in Table 6-18 in your RACF
database to ensure that all JES2 system commands are protected. You replace only the
.jesx prefix with your own JES2 subsystem ID (usually JES2).
$A jesx.MODIFYREALEASE.* UPDATE
$A A jesx.MODIFYRELEASE.JOB UPDATE
$A J jesx.MODIFYRELEASE.BAT UPDATE
$A S jesx.MODIFYRELEASE.STC UPDATE
$A T jesx.MODIFYRELEASE.TSU UPDATE
$C J/S/T O jesx.CANCEL.JST*/BAT*/STC*/TSU*
$C J jesx.CANCEL.BAT UPDATE
$C S jesx.CANCEL.STC UPDATE
$C T jesx.CANCEL.TSU UPDATE
$C O J jesx.CANCEL.BATOUT UPDATE
$C O S jesx.CANCEL.STCOUT UPDATE
$C O T jesx.CANCEL.TSUOUT UPDATE
$D * jesx.DISPLAY.* READ
$D A jesx.DISPLAY.JOB READ
$D F jesx.DISPLAY.QUE READ
$D I jesx.DISPLAY.INITIATOR READ
$D J jesx.DISPLAY.BAT READ
$D N jesx.DISPLAY.JOB READ
$D O J jesx.DISPLAY.BATOUT READ
$D O S jesx.DISPLAY.STCOUT READ
$D O T jesx.DISPLAY.TSUOUT READ
$D Q jesx.DISPLAY.JOB READ
$D S jesx.DISPLAY.STC READ
$D T jesx.DISPLAY.TSU READ
$D U jesx.DISPLAY.DEV READ
$L J jesx.DISPLAY.BATOUT READ
$L S jesx.DISPLAY.STCOUT READ
$L T jesx.DISPLAY.TSUOUT READ
$D M jesx.SEND.MESSAGE READ
$D M jesx.SEND.MESSAGE READ
$E J $E J jesx.RESTART.BAT CONTROL
$G * jesx.G* UPDATE
$G A jesx.GMODIFYRELEASE.JOB UPDATE
$G C jesx.GCANCEL.JOB UPDATE
$G D jesx.GDISPLAY.JOB READ
$G H jesx.GMODIFYHOLD.JOB UPDATE
$G R jesx.GROUTE.JOBOUT UPDATE
$H jesx.MODIFYHOLD.* UPDATE
$H A jesx.MODIFYHOLD.JOB UPDATE
$H J jesx.MODIFYHOLD.BAT UPDATE
$H S jesx.MODIFYHOLD.STC UPDATE
$H T jesx.MODIFYHOLD.TSU UPDATE
$M jesx.MSEND.CMD READ
$M jesx.MSEND.CMD READ
$N jesx.NSEND.CMD READ
$N jesx.NSEND.CMD READ
$O * jesx.RELEASE.BATOUT UPDATE
$O J jesx.RELEASE.BATOUT UPDATE
$O S jesx.RELEASE.STCOUT UPDATE
$O T jesx.RELEASE.TSUOUT UPDATE
$P jesx.STOP.SYS CONTROL
$P I jesx.STOP.INITIATOR CONTROL
$P J/B/T + O jesx.STOP.JST*/BAT*/STC*/TSU*
$R * jesx.ROUTE.JOBOUT UPDATE
$S jesx.START.SYS CONTROL
$S A jesx.START.AUTOCMD CONTROL
$S I jesx.START.INITIATOR CONTROL
$S N jesx.START.NET CONTROL
$S J $S J jesx.START.BAT UPDATE
$T I jesx.MODIFY.INITIATOR CONTROL
$T J/B/T + O jesx.MODIFY.JST*/BAT*/STC*/TSU*
$T J jesx.MODIFY.BAT UPDATE
$T S jesx.MODIFY.STC UPDATE
$T T jesx.MODIFY.TSU UPDATE
$T O J jesx.MODIFY.BATOUT UPDATE
$T O S jesx.MODIFY.STCOUT UPDATE
$T O T jesx.MODIFY.TSUOUT UPDATE
$Z * jesx.HALT.* CONTROL
$Z A jesx.HALT.AUTOCMD CONTROL
$Z I jesx.HALT.INITIATOR CONTROL
Then, assign RACF permissions by using the RACF PERMIT command to certain user groups in
your installation, as shown in the following profiles:
System engineers privileged (for example, z/OS and JES2)
System engineers from other product (for example, IBM Db2® IMS IBM CICS®)
In-house operators
Offshore operators
Print operators
System automation tasks, functions, or jobs
Attention: The permissions that are given to the RACF profiles must match the profile that
is given to the matching SDSF and EJES profiles.
If you use the REXX interface of one of these third-party products (SDSF or EJES), you must
consider the possibility of changing this use if you use fields that might no longer exist or were
changed.
Within JES2, all printers include a prefix in their name that is called PRT, followed by a
four-digit number. Two different JES3 printer definitions from the customer project are shown
in Example 6-26. In this example, Printer B433 and B439 turned on the separator page and
the burst mode.
The JES2 equivalent definitions for the printer are shown in Example 6-27. The printer name
changed, as listed in Table 6-19.
The change in the printer name affects your installation. Consider the following points:
Change printer permissions inside RACF if security is needed according to your new
printer names PRT*. For more information about security definitions, see 6.9, “Migrating
security” on page 157.
Adjust all console commands or REXX that use native JES commands to the new printer
names. Start, Stop, Modify, Forward, and Backward commands are targeted to the JES2
real printer name.
Attention: The name of the JES2 writer name and route destination is set to the original
JES3 printer name to be compatible with your applications. For more information, see the
R and WRITER option in the JES2 printer definition and Example 6-27.
The JES2 equivalent to the JES3 definition of printer B433 is shown in Example 6-29. The
JES2 printer name that is used is based on your company’s rules.
Tip: You can place JES2 and JES3 printer definitions in one FSS start procedure if the
lines are not exceeded. This configuration prepares your FSS procedure for both JES
versions. Alternatively, you can create a separate PROCLIB for all JES2 FSS procedures
and replace them during the migration process.
The CPU consumption of all JES STCs that are running in an eight-way UAT sysplex during
the migration time frame is shown in Figure 6-15. The chart also shows non-JES dependent
workloads in user address spaces (the values are in MSU). The migration from JES3 to JES2
occurred on November 29, 2015 from 10:00 AM - 1:00 PM.
Before the migration time, you see most of the CPU consumption is coming from system
R28R, where the JES3 GLOBAL was stored. All of the JES3 LOCALS CPU consumption is
low.
Conclusion
The total amount of CPU consumption per sysplex under JES2 is slightly lower compared to
JES3. The reason for this result is that some of conversion is done in the user’s address
space instead of the JES address space. (This extra CPU workload is not considered in
Figure 6-15.)
Note: You can configure your JES2 to move Converter and Interpreter to a separate JES
address space that is named JES2CIxx by using the INTERPRET=JES initialization
option. This process also moves the workload from the user’s address space to JES2 and
provides a better comparison between both JES versions.
Each of the participating JES2 members includes a dedicated defined time to access the
checkpoint. The checkpoint is shared by MAS members in a time-sliced manner.
Each member gets a lock on the checkpoint data set, reads the changes that were made by
other members, processes the queues, writes updated control blocks back to the checkpoint,
and releases the lock. It then waits before trying to access the checkpoint again.
We recommend that you consider the use of dynamic checkpointing with this release of z/OS.
Using dynamic checkpointing brings your JES2 MAS in position to manage the HOLD and
DORMANCY that is based on the JES2 workload on each of the participating systems in your
MAS.
In a typical customer situation, you do not know in detail from where the JES2 workload is
coming. If you know the origin of the workload, it can be changed rapidly because of moving
subsystems to another system or workload considerations. An adjustment of the HOLD and
DORMANCY values is required whether you know the origin of the workload.
DD *,DLM=$$ Read the data until $$ appears Read the data until $$ or // appears
DD DATA,DLM=$$ Read the data until $$ appears Read the data until $$ appears
The solution for this issue is to migrate all of your JCL by using DD *,DLM= to DD
DATA,DLM=.
The root cause was determined to be the different handling of the JCL accounting field of the
job card. The handling of the accounting field under JES2 is shown in Figure 6-16.
According to the description of the account field that is shown in Figure 6-16 on page 172, the
fourth value in the accounting field is honored as the maximum number of lines your job can
produce. Therefore, the job is canceled after producing one line with the S722 abend. This
behavior is the standard behavior of JES2. To eliminate this behavior, use the JES2
initialization parameter JOBDEF ACCTFLD=IGNORE.
The second job JOBB appears not to be converted. The old JES3 //*MAIN CLASS statement
still exists and is ignored by JES2 because it is only a comment.
In both situations, JOBA and JOBB are assigned to the default job class that is defined by
JES2. This situation caused many delays in processing the default job class. For a brief
overview of how many jobs are waiting to be run, use the $DQ,Q=XEQ JES2 operator
command, as shown in Example 6-32.
CMDS Console message buffers used CMDNUM on the CONDEF statement SYS
for JES2 commands
These resources can be set according to your needs in the JES2 initialization PARMLIB
member. In addition to the value of each resource, you can add a threshold value when you
are notified that the value exceeds a previously defined threshold. In such cases, a generic
$HASP050 message appears that indicates the resource type that caused the issue.
If a message appears, system operations often are not yet affected. The message that is
coming from the job output elements resource is shown in Example 6-33. Therefore, the
number of jobs in the JES2 output queue exceed 80% of total defined maximum.
If the messages appear too often, consider increasing the value of that resource.
An overview of all JES2 resources in a sample production system is shown in Figure 6-17. All
values are defined in such a way that enough space still exists for unplanned actions.
RESOURCE Limit InUse InUse% Warn% IntAvg IntHigh IntLow OverWarn% JESLevel
BERT 2100 447 21.28 80 447 447 447 0.00 z/OS 2.4
BSCB 0 0 0.00 0 0 0 0 0.00 z/OS 2.4
BUFX 179 0 0.00 80 0 0 0 0.00 z/OS 2.4
CKVR 50 0 0.00 80 0 1 0 0.00 z/OS 2.4
CMBS 204 0 0.00 80 0 0 0 0.00 z/OS 2.4
CMDS 1000 0 0.00 80 0 0 0 0.00 z/OS 2.4
ICES 33 0 0.00 80 0 0 0 0.00 z/OS 2.4
JNUM 9999 1373 13.73 80 1373 1373 1373 0.00 z/OS 2.4
JOES 10000 3754 37.54 80 3754 3754 3754 0.00 z/OS 2.4
JQES 3000 1373 45.76 80 1373 1373 1373 0.00 z/OS 2.4
LBUF 47 0 0.00 80 0 0 0 0.00 z/OS 2.4
NHBS 100 0 0.00 80 0 0 0 0.00 z/OS 2.4
SMFB 51 0 0.00 80 0 0 0 0.00 z/OS 2.4
TBUF 104 0 0.00 0 0 0 0 0.00 z/OS 2.4
TGS 40017 13345 33.34 80 13339 13345 13332 0.00 z/OS 2.4
TTAB 3 0 0.00 80 0 0 0 0.00 z/OS 2.4
VTMB 0 0 0.00 0 0 0 0 0.00 z/OS 2.4
ZJC 1000 49 4.90 80 49 49 49 0.00 z/OS 2.4
This issue affected of the output that were in the SPOOL files that were created with an
SVC99 on the JES3 site. This issue occurred when the application used SVC99 for creating
JES2 SPOOL data set; for example, memory dumps.
The solution was to code SNAGROUP=YES in the JES3 OUTSERV statement, as shown in
Example 6-34.
Attention: Do not forget to configure the pairing JES3 NJE server to four lines by using the
OUTTRANS= parameter on the NJERMT JES3 initialization statement.
The JES2 and JES3 commands that are used to change to number of sysoutt channels is
shown in Example 6-35.
For more information, see 6.12.5, “Monitor JES2 resources” on page 174.
Two jobs that have more than one output data set allocated are shown in Figure 6-18 on
page 177. Each job acquires one JOE.
The root cause was the TSO FREE command. This command includes the default option
SPIN(UNALLOC), which closes the data set and generates a JOE in JES2 SPOOL.
By using the SPIN(NO) option in the FREE command, the output data sets are not closed
immediately. Instead, they are closed at the end of the job (REXX). Therefore, only one JOE
in JES2 SPOOL is occupied per job. The differences in the commands are shown in the
following examples:
Old command: FREE D(<DDNAME>)
New command: FREE D(<DDNAME>) SPIN(NO)
A UAT sysplex runs with a time in the future. It was not possible to establish a connection to
this sysplex from the system that was set to normal time. The UAT sysplex is reset to normal
time every quarter. Then, connection problems occurred again because the remaining NJE
nodes stored a later time stamp than the sysplex now used.
This behavior was not caused by NJE, but by the pathmanager functionality. To avoid this
issue, turn off the path manager of JES2 by using the PATHMGR=NO option.
To establish a static NJE connection without the use of NJE path manager capability, you
must manually define all network routes.
A sample NJE configuration with three systems that connect over TCP/IP is shown in
Figure 6-19. With PATHMGR=YES, no other definitions to JES2 are necessary to connect
nodes.
If you are requested to use PATHMGR=NO, you must manually define the route from SYS1 to
SYS3. The following statement must be placed in your JES2 PARMLIB configuration data set
for system SYS1:
CONNECT PATHMGR=NO,NA=SYS2,NB=SYS3
This statement tells NJE on SYS1 that node SYS3 is connected or reachable over SYS2. On
SYS3, you must define the route in the opposite manner, as shown in the following example:
CONNECT PATHMGR=NO,NA=SYS2,NB=SYS1
Within JES2, you cannot change the printer selection criteria, such as sysout class and forms
while the printer is active. How JES2 works with printers is shown in Figure 6-21. In this
example, we start the JES2 printer for sysout class A and forms CTD0. The first job for
processing is JOB1. The next waiting job to print JOB2 is coming from sysout class B and
form CTD1. The printer must be inactive to change the printer’s selection criteria.
Stopping the printer causes at least a waste of paper. To avoid this issue, we recommend
starting your printer with parms to process more than one sysout class (up to eight are
possible).
The solution was to remove that SUBSYS(JES3) statement. The primary subsystem is used if
this option is omitted.
Note: It is suggested to scan all of your z/OS PARMLIBs for occurrences of the JES3
keyword to identify such mis-configurations in advance.
During the migration, all subject matter experts must be available to the control their
subsystems and conduct tests after JES2 is activated.
Information: Any subject matter expert must confirm that their product is working with
JES2 after migrating to the project.
Replace the primary subsystem JES3 with JES2 in your active IEFSSNxx member, as shown
in Example 6-36 and Example 6-37.
Attention: With a primary JES2 subsystem, it is not possible to have a parallel JES3
secondary subsystem available. The SUBSYS SUBNAME(JES3) must be removed from
the IEFSSNxx member.
The next step is to prepare all participating subsystem products, especially those that are
close in contact with JES.
JES2 initialization
It is recommended to start JES2 in front of the migration with a JES2 cold start. This process
can be easily done by defining JES2 as the secondary subsystem in parallel to JES3 as the
primary.
Attention: This step should be started well in advance because some jobs might be
running for a long time, especially in production. Contact your BATCH scheduling team for
more information.
JES2 Sysplex
Transfer of
SPOOL Data
NJE
The extra system is part of the JES3 complex and becomes the new JES3 GLOBAL. That
system was active for the next week after migration to JES2 because of the reasons that are
described in this section.
Stop BATCH
To prevent unwanted jobs in your system, stop job processing by removing queue affinity from
your JES2 job classes, as shown in Example 6-38.
Attention: After changing your JES3 INISH member, you need a JES3 hot start to pick up
these changes.
The JES2 node also can be defined dynamically by using the JES3 commands that are
shown in Example 6-40.
Next, add the renamed node name to your JES2 MAS (see Example 6-41).
Now you can establish the NJE connection between both systems by using the JES2 start
command that is shown in Example 6-42.
The JES3 commands that are used for starting the JES2 node from the JES3 system are
shown in Example 6-43.
*I U Q=WTR,CL=?
IAT8131 T=PRT, CL=A, L=199055, PG=0, SR=199055, BY=24222204.
IAT8119 NUMBER OF JOBS FOUND : 628
Information: To calculate the number of bytes that must be transferred and the time that is
needed, do not use the number of bytes you see in SDSF. Instead, multiply the number of
lines by the record length of 133 to calculate the number of bytes that must be transferred.
Some sample JES3 commands are shown in Example 6-45. The destination to your target
system can be changed for all elements in sysout hold class X in this example.
Attention: Before starting the SPOOL migration, ensure that the SNAGROUP=YES option
is enabled in JES3 so that the output files are not split. For more information, see 6.12,
“Hints and tips” on page 172.
Check EDP Jobs from EDP (end of Day No JCL errors or abends caused by
Processing) might run the migration
NJE Connectivity Check active NJE lines All defined NJE nodes active
JCL Test Test JCL Job runs successfully RC=0 on all test jobs
JES2 Access Check JES2 modify commands Unauthorized users prevented from
for unauthorized users JES2 modify commands
UserID and Password Test Allocate new DSN with no RACF error S913
permission. Submit job without
password from secondary UID
Alarm Tests Tests of alarm you can set with Alarm is showing on the monitor,
JES2 email, and mobile phone
Batch OFF/ON Check if BATCH can be All job classes must be off or on,
stopped and started based on their JES2 system affinity
Exit Test Test all of your JES2 user JES2 exits works as designed
modifications
Test Printing Print file from mainframe to Print file arrives in JES2 Spool
remote printer File is printed
Print from IMS
Attention: Carefully monitor JES2 default job class for misplaced jobs because of missing
job class information.
The project was separated in 10 subprojects, which were managed by a dedicated person.
The overall project organization on the customer site is shown in Figure 6-24. The project
contains 10 deliverables called Work products (WP). This number can vary in your
environment based on your needs and your available head count.
• Provide educations
WP6 General topics
• Disable DLOG, enable OPERLOG
The plan that includes all affected stakeholders should be created to ensure that all persons
that are affected by replacing JES3 are known. Based on that list, you start planning for
education or communications to those stakeholders.
The communication plan is crucial for the project to improve the acceptance of the project for
all stakeholders. All communication should be adjusted according to the following levels of the
stakeholder:
Information to the management (a 2-week cycle is sufficient)
Information to the technical stakeholder on weekly basis
All the other users, if needed
The next plan should cover all types of resource planning. The plan includes registering
people that are needed for the project to ensure that they are available for the project. At the
same time, carefully record all known planned absences to balance the available resources to
avoid unwanted project delays.
The only one task that is left is the migration of the printer names to the JES2 printer naming
convention.
In a customer’s environment, the following exits were left that needed to reprogrammed:
JES2 Exit 6 to adjust JCL with customer modifications
JES2 Exit 23 is user for PSF to create a print header page
Important: After identifying all of the users, contact all of the job owners and prepare to
migrate the jobs, if still needed. After JES2 is migrated, carefully monitor all migrated jobs.
Important: Our r experience shows that you can expect most problems after migration
because many users made mistakes while migrating their JCL.
WP5 security
The purpose of subproject is to correctly set up the JES2 command security according to
your JES3 settings. We created a list of all available JES2 commands and their corresponding
RACF profile and assigned them to the users based on the JES3 settings.
Important: This work product can be tested in parallel to your JES3 in advance with the
dependency to WP9 JES2 setup. If you use a running JES2 as a secondary subsystem,
you can test your security setup.
Command Alias Profile Name Access Level all auto print oper sysprog command details Description
$A jesx.MODIFYREALEASE.* UPDATE Y
$A A jesx.MODIFYRELEASE.JOB UPDATE $A A Release all jobs
$A J jesx.MODIFYRELEASE.BAT UPDATE $A Job Release held jobs
$A JOBQ jesx.MODIFYRELEASE.JST UPDATE
$A S jesx.MODIFYRELEASE.STC UPDATE
$A T jesx.MODIFYRELEASE.TSU UPDATE
Attention: In this WP, one of the key tasks that must be addressed is education.
Experience shows that frequent education increases the acceptance of all stakeholders
during the project.
The first basic education session must mandatory for all stakeholders in your company and
conducted at the beginning of the project. Consider offering this educational session in
different languages, if needed.
During the JES2 migration project, consider offering more detailed education sessions for
expert teams, such as system engineering or system controlling (operations). The types of
topics that must be addressed in detailed education sessions are listed in Table 6-23.
At the end of the project, we conducted a mandatory refresh session for all stakeholders that
use JES2.
Tip: For the success of the project, it might be necessary to request an acknowledgment
from every department that is affected to ensure that all stakeholders are ready for the
migration.
The first task is to collect and document all JES3-related automation items that are defined in
your environment. Then, you can categorize that list based on the following factors:
No change: Can be used unchanged.
Change: Must be adjusted according the JES2 (new message number).
Delete: No longer needed with JES2.
Add: New messages must be defined.
Tip: For this task, it is helpful to have a JES2 expert onsite to discuss how certain JES3
settings are working under JES2. That is, what JES2 appears for a defined action that
must be handled by the system automation.
Tip: This action should be done as soon as possible so that all stakeholders can test any
types of items to migrate under JES2.
Important: After finishing the JES2 setup, start any created JES2 instance with JES2 cold
start to initialize your SPOOL. This process saves you time during the migration process.
JES2 can be started as a secondary subsystem next to JES3 as the primary.
Important: Start the project early in the year to avoid problems with end-of-year freeze.
The estimated time that you need strongly depends on your installation and the needed
migration steps. In a customer’s environment, much time was needed to re-create the
program that was needed for managing printing.
Another important issue is how many human resources are available for the project. Because
almost all of the migration steps can be done in parallel, the estimated time for the project
depends on the available people power. An example of the time frames that are used in the
case study is shown in Figure 6-26.
User JCL 29.05.19 29.05.19 29.05.19 29.05.19 29.05.19 29.05.19 29.05.19 29.05.19
migration*
Part 3 Appendixes
In Part 3, we provide some useful samples to help with migration and that can be used to
explore new JES2 features after migration.
Copyright license and permission to copy: This appendix contains a sample application
program in source language that illustrates programming techniques. You might copy,
modify, and distribute this sample program in any form without payment to IBM, for the
purposes of developing, using, marketing, or distributing application programs conforming
to the application programming interface for the operating platform for which the sample
program is written. This example has not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of this program.
Changes to OPERCMDS profiles also are referenced, where applicable. Although this
information is not a complete list of all possible commands, it provides examples of each type
of command.
Copyright license and permission to copy: This appendix contains a sample application
program in source language that illustrates programming techniques. You might copy,
modify, and distribute this sample program in any form without payment to IBM, for the
purposes of developing, using, marketing, or distributing application programs conforming
to the application programming interface for the operating platform for which the sample
program is written. This example has not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of this program.
The input to program SMF84RPT is the SMF dump data set that is generated by IFASMFDx
program.
The program writes output to two data sets: a SYSOUT with the report generated and a
SYSPRINT with program messages.
An example of JCL statements that are required to run the SMF84RPT program and produce
a report from JES2 SMF84 records is shown in Example C-1. This sample is showing an
execution that uses the MEM option on EXEC PARM.
Example C-1 Sample JCL to run the SMF84RPT program to generate a MEM usage report
//SMF84JOB JOB (),'SMF84 MEM REPORT',CLASS=B,MSGCLASS=X,DSENQSHR=ALLOW,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=SMF84RPT,PARM='MEM'
//STEPLIB DD DSN=your-load-library,DISP=SHR
//SMFOUT DD SYSOUT=*
//SMFPRINT DD SYSOUT=*
//SMFIN DD DISP=SHR,DSN=your-input-smfdump-dataset
An example of a Memory Usage report that is produced by SMF84RPT when the user selects
the MEM option on EXEC PARM parameter is shown in Example C-2. The report is
generated to all intervals that are collected from the input SMF data set that is provided to
program.
Example C-3 Sample of Resource usage by JES report generated by SMF84RPT program
1SMF-DATE SMF-TIME Z/VERSION SYSID JES RSU_NAME RSU_LIMIT RSU_INUSE RSU_LOW RSU_HIGH RSU_WARN RSU_OVER RSU_AVG
---------- -------- --------- ----- ---- -------- --------- --------- -------- -------- -------- -------- --------
2018/06/09 00:00:15 SP7.2.3 SC74 JES2 BERT 2100 378 376 378 80% 0 377
BSCB 0 0 0 0 0% 0 0
BUFX 79 0 0 0 80% 0 0
CKVR 50 0 0 1 80% 0 0
CMBS 204 1 1 1 80% 0 1
CMDS 1000 0 0 0 80% 0 0
ICES 33 0 0 0 80% 0 0
JNUM 9999 619 617 619 80% 0 618
JOES 10000 1410 1408 1410 80% 0 1410
JQES 3000 619 617 619 80% 0 618
LBUF 47 0 0 0 80% 0 0
NHBS 100 0 0 0 80% 0 0
SMFB 51 0 0 0 80% 0 0
TBUF 104 0 0 0 0% 0 0
TGS 40017 8944 8942 8944 80% 0 8943
TTAB 3 0 0 0 80% 0 0
VTMB 0 0 0 0 0% 0 0
ZJC 1000 44 44 44 80% 0 44
SMF-DATE SMF-TIME Z/VERSION SYSID JES RSU_NAME RSU_LIMIT RSU_INUSE RSU_LOW RSU_HIGH RSU_WARN RSU_OVER RSU_AVG
---------- -------- --------- ----- ---- -------- --------- --------- -------- -------- -------- -------- --------
2018/06/09 01:00:15 SP7.2.3 SC74 JES2 BERT 2100 378 376 378 80% 0 377
BSCB 0 0 0 0 0% 0 0
BUFX 79 0 0 0 80% 0 0
CKVR 50 1 0 1 80% 0 0
CMBS 204 1 1 1 80% 0 1
CMDS 1000 0 0 0 80% 0 0
ICES 33 0 0 0 80% 0 0
JNUM 9999 621 619 621 80% 0 620
JOES 10000 1412 1410 1412 80% 0 1412
JQES 3000 621 619 621 80% 0 620
LBUF 47 0 0 0 80% 0 0
NHBS 100 0 0 0 80% 0 0
SMFB 51 0 0 0 80% 0 0
TBUF 104 0 0 0 0% 0 0
TGS 40017 8946 8944 8946 80% 0 8945
TTAB 3 0 0 0 80% 0 0
VTMB 0 0 0 0 0% 0 0
ZJC 1000 44 44 44 80% 0 44
SMF-DATE SMF-TIME Z/VERSION SYSID JES RSU_NAME RSU_LIMIT RSU_INUSE RSU_LOW RSU_HIGH RSU_WARN RSU_OVER RSU_AVG
---------- -------- --------- ----- ---- -------- --------- --------- -------- -------- -------- -------- --------
2018/06/09 02:00:15 SP7.2.3 SC74 JES2 BERT 2100 378 376 378 80% 0 378
BSCB 0 0 0 0 0% 0 0
BUFX 79 0 0 0 80% 0 0
CKVR 50 1 0 1 80% 0 0
CMBS 204 1 1 1 80% 0 1
CMDS 1000 0 0 0 80% 0 0
ICES 33 0 0 0 80% 0 0
JNUM 9999 623 621 623 80% 0 622
JOES 10000 1414 1412 1414 80% 0 1413
JQES 3000 623 621 623 80% 0 622
LBUF 47 0 0 0 80% 0 0
NHBS 100 0 0 0 80% 0 0
SMFB 51 0 0 0 80% 0 0
TBUF 104 0 0 0 0% 0 0
TGS 40017 8950 8946 8950 80% 0 8948
TTAB 3 0 0 0 80% 0 0
VTMB 0 0 0 0 0% 0 0
ZJC 1000 44 44 44 80% 0 44
An example of the SMFDATE macro that is used by SMF84RPT program to convert date from
SMF Julian format to edited European Gregorian format is shown in Example C-7.
An example of the SMFTIME macro that is used by SMF84RPT program to convert time from
SMF format to editable values is shown in Example C-8.
An example of the SMFEDIT macro that is used by SMFRPT84 program to edit numbers that
are used to count are shown in Example C-9.
An example of the EDITMK macro that is used to edit numbering for SMF report fields is
shown in Example C-10.
When enabled, JES2 migrates JES3 //*NET JECL statements to the JES2 JEC job group
support. A JEC job group is created to support a DJC semantics.
The JOBGROUP name is the NETID= value that is specified on the //*NET statement. The
JOBGROUP that is created is marked as having a DJC statement origin. Marking it in this
way allows JES2 to mimic the JES3 DJC runtime behavior. All job group commands can be
used.
As with job groups, a logging job is created by using NETID. The logging job is a central place
to collect messages that are related to important events in the life of the NETID and its
constituent jobs. These events include jobs that are run or skipped and return codes.
TEST4 also has only one dependency; it is released when TEST4 finishes. The same is true
for TEST5.
Although TEST6 execution has no dependencies, it is delayed for four minutes because of the
SCHEDULE JCL card. When TEST6 finishes, it releases jobs TEST7 and TEST2. TEST7
has only one dependency: the conclusion of TEST6.
As shown in Figure D-2 on page 228, TEST1 registered to group TESTE1 at 14:37:50. All
other jobs registered to group TESTE1 at the same time (they were all submitted at the same
time).
TEST1 began execution immediately; NHOLD=0. The other JOB that had NHOLD=0 was
TEST6. However, the log indicates that it did not began its execution immediately; instead, it
waited until 14:42:03 to be executed. The HOLDUNTIL parameter of the SCHEDULE JCL
card delayed its execution for at least 4 minutes (see Figure D-3). As you can see, it is
possible to add SCHEDULE JCL to a JES3 NET.
You also see that TEST3 began execution when TEST1 finished. The only dependency was
the completion of TEST1.
Figure D-3 SYSOUT OF TEST6: Using JES2 JEC with JES3 NET
In Figure D-3 on page 229, you see the output of TEST4. That output shows a JES2
message HASP1309 indicates that the NET statement was successfully processed.
First, the job name is the same as the NETID. Then, you must to define by way of a GJOB
statement all jobs that belong to this group.
For each job, you must define the relationship with other jobs; for example, TEST1 must
execute before TEST2 and TEST3. TEST2 must execute before TEST4 and TEST5.
You must submit this job before submitting the jobs in the group for the dependency to take
place.
You must add a SCHEDULE JCL card with the JOBGROUP parameter for every job to
associate the JOB to the corresponding JOBGROUP. You can also use other parameters in
the SCHEDULER JCL statement, such as in TEST6.
Comparing both job stream executions (as shown in Figure D-2 on page 228 and Figure D-6
on page 232), you can see that the jobstreams executed the same way in both cases. The
JOBGROUP that was created by JES2 when processing the //* NET JES3 LECL statements
controlled the execution of the jobs in the job stream, such as the JOBGROUP we created
with the corresponding SCHEDULE JCL statements.
The spool partitioning allows you to isolate different types of spool data. Isolating spool data
in separate partitions can help you improve spool performance, spool recovery procedures,
and spool space management.
Copyright license and permission to copy: This appendix contains a sample application
program in source language that illustrates programming techniques. You might copy,
modify, and distribute this sample program in any form without payment to IBM, for the
purposes of developing, using, marketing, or distributing application programs conforming
to the application programming interface for the operating platform for which the sample
program is written. This example has not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of this program.
Before implementing this exit, you must determine if your installation uses spool partitioning.
Your installation uses spool partitioning if FENCE=ACTIVE=YES is specified on the
SPOOLDEF initialization statement.
Spool partitioning Initializes and resets bits in the Can only reset bits in the mask
mask mask. to allow spool space to be
Can be used to define spool allocated from more spool
partitioning for the job. volumes.
Started to Allocate spool space for the first time Allocate more spool space
for the job. when JES2 determines that the
spools that use the allowed
mask of the job must be
expanded.
When exit 11 is called for the first time, situations exist that it are called again if the following
conditions are met:
The job was not assigned the maximum number of spool volumes (SPOOLDEF
FENCE=VOLUMES=nnnn), regardless of whether space is available on the spool
volumes from which the job is permitted to allocate space.
The job assigned the maximum number of volumes and no space is available for allocation
(that is, the volumes are full, the volumes are not available for allocation, or the volumes do
not have affinity for the system).
Exit 12 is taken when JES2 determines that the spools that are using the allowed mask for the
job that was set by exit 11 must be updated. The spools that are using the allowed mask are
updated in the following situations:
The job is not yet using the maximum number of spool volumes (SPOOLDEF
FENCE=VOLUMES=nnnn), regardless of whether space is available on the spool
volumes from which the job is permitted to allocate space.
The job is using the maximum number of volumes (CCTFNCNT in HCCT) and no space is
available for allocation (that is, the volume is full, the volume is not available for allocation,
or the volume does not have affinity for the system) on the spool volumes from which the
job is permitted to allocate space.
Also, to allow a job to overflow spool data from a partition, you must define a RACF
$JES2.SPART.EXT.sysid.jobname profile on class FACILITY and grant READ access to users
extend the current partition to volumes on overflow partition.
The volumes that are assigned to a default partitions are used only if all primary and overflow
volumes become full and the job requires more spool space to processing.
If the volumes on default partition also becomes full, the exit 12 sends a message to the
operator requesting to retry the process or cancel the processing of spool partitioning and
allocate spool data into unassigned volumes with space available.
Define at least one volume for the default partition to receive data from overflow volumes
without affecting the reserved spool space. If you do not define a default partition for the exits,
JES2 uses the reserved spool space that is not assigned to the exits as normal processing if
all volumes are full.
The partitioning control that is offered by these exits is based on the job name and type of
address space (which differs from the partitioning control that is provided by JES3 based on
the job execution class). Therefore, to permit the jobs to use the spool partitioning
functionality that is provided by exits, the following profiles must be defined to RACF:
$JES2.SPART.jobtype.sysid.jobname
This profile is used by exit 11 to control by jobnames the users that can use the provided
spool partitioning functionality. The following variables are used on this profiles:
– jobtype: The type of job that is authorized to use the spool partitioning functionality
(JOB, TSU, or STC).
– sysid: The system ID of the MAS member where the spool partitioning functionality is
active to the specific job.
– jobname: The name partial or fully qualified of job authorized to use the spool
partitioning functionality that is provided by exits.
TRACK,DDNAME=SPOOL1,SPART=NORMAL
TRACK,DDNAME=SPOOL2,SPART=NORMAL
TRACK,DDNAME=SPOOL3,SPART=NORMAL
TRACK,DDNAME=SPOOL4,SPART=SPECIAL
TRACK,DDNAME=SPPOL5,SPART=SPARE
CLASS,NAME=A,SPART=NORMAL
CLASS,NAME=B,SPART=SPECIAL
SYSOUT,CLASS=X,SPART=NORMAL
SYSOUT,CLASS=Y,SPART=SPECIAL
With the new APAR OA55792 applied, the JES2 supports the use of job class and message
class to select the jobs that can use spool partitioning. Because the APAR was not available
during the tests, the version that is presented uses the JOBNAME to select the candidate
jobs. Also, you must permit special users to use the spool partitioning function, as shown in
Example E-2.
$JES2.SPART.VOL.sysid.volid
$JES2.SPART.VOL.*.SPOOL1: Permit normal users
$JES2.SPART.VOL.*.SPOOL2: Permit normal users
$JES2.SPART.VOL.*.SPOOL3: Permit normal users
$JES2.SPART.VOL.*.SPOOL4: Permit special users to allocate spool space for batch
job processing.
$JES2.SPART.EXT.sysid.jobname
$JES2.SPART.EXT.*.EMG*: Permit special users to acquire more spool space if the
primary partition became full
$JES2.SPART.CLASS.sysid.class
$JES2.SPART.*.A*: Permit that jobs running with jobclasses started with A are
able to use spool partitioning.
$JES2.SPART.OVRFL.sysid.volid
$JES2.SPART.OVLF.*.SPOOL5: Permit special users to use the spool volume SPOOL5
as overflow space from primary partition.
$JES2.SPART.DFLT.sysid.volid
It also can reinterpret JOB JCL if z/OSEM Job Classing is used to change a JOB’s CLASS to
obtain JES2 default values, such as TIME.
z/OSEM also provides support for the JES2 parameter in the initialization deck JOBDEF
INTERPRET=JES|INIT, JES2 Exit 59, and JES2 Exit 60.
The support that is offered by IBM as of this writing and ThruPut Manager Automation Edition
is compared in Figure F-1 on page 265.
For more information about ThruPut Manager Automation Edition, see this website.
//*FORMAT Supported - some keyword exceptions • $JES3_ DAL/JAL descriptors available for ALL keywords.
• Builds OUTPUT JCL statement for supported • Automatically handles changes via SOS for all supported keywords.
keywords. • Converts internally
• Not Supported Keywords
o CHNSIZE
o OVFL
o THRESHLD
//*MAIN Some keywords supported • $JES3_ DAL/JAL descriptors available for ALL keywords.
• Not Supported Keywords – message issued • Changes to SWA done automatically for all supported keywords.
o DEADLINE • DEADLINE= is also supported (Deadline Scheduling).
o EXPDTCHK • MAIL= translated to ROOM= (feature not documented by IBM)
o FAILURE
o FETCH
o SETUP
o SPART
o THWSSEP
o UPDATE
o USER
• Obsolete Keywords – message issued
o ACMAIN
o IORATE
o LREGION
o MSS
o RINGCHK
o TRKGRPS
//*NET •TYPE
Obsolete Keywords – message issued • $JES3_ DAL/JAL descriptors available for ALL keywords.
o DEVPOOLACMAIN • Changes to SWA done automatically for all supported keywords
o DEVRELSEIORATE
o RELSCHCT
//*NETACCT Supported • $JES3_ DAL/JAL descriptors available for ALL keywords. Changes to
SWA done automatically.
//*PROCESS Tolerated – no message issued • Converted to // EXEC dspname. CI, MAIN, OUTSERV and PURGE are
//*ENDPROCESS ignored.
• Value passed in $JES3 PROCESS to DAL/JAL.
//*ROUTE XEQ Not supported. Message issued - Job stream Automatically converted via JECL=
flushed.
IBM Support Legend
Not supported – Message $HASP1133 issued - ignored Obsolete - $HASP1132 issued – ignored
Tolerated – no messages – ignored
If ThruPut Manager Automation Edition JES3 support is enabled, all jobs with JES3 JECL
statements receive the following message:
DTM1118I JES3 JECL Ignored due to 'INPUTDEF JES3JECL=PROCESS' in SYSMSGS.
Search for SG24-8427, select the title, and then, click Additional materials to open the
directory that corresponds with the IBM Redbooks form number, SG24-8427.
The publication that is listed in this section is considered particularly suitable for a more
detailed discussion of the topics that are covered in this book.
IBM Redbooks
The IBM Redbooks publication JES3 to JES2 Migration Considerations, SG24-8083,
provides more information about the topics in this document. Note that this publication might
be available in softcopy only.
You can search for, view, download or order this document and other Redbooks, Redpapers,
Web Docs, draft, and other materials, at the following website:
ibm.com/redbooks
SG24-8427-01
ISBN 0738458201
Printed in U.S.A.
®
ibm.com/redbooks