Customer experience case study
This chapter describes the experiences of a mid-sized business customer when they chose to migrate from JES3 to JES2.
This chapter includes the following topics:
 
 
 
 
 
 
 
6.1 Migration steps overview
An overview of the necessary tasks that must be done during the JES3-to-JES2 migration project are listed in Table 6-1. Some of the listed tasks might not be included in your migration project based on your system environment.
Table 6-1 Project tasks overview
Project task
Target
Comments
Project management
Covers all types of project management, such as:
•Managing project
•Stakeholder plannings
•Communication plan
•Resource plan
•Vacation plan
•Education plan
•Organize meetings
N/A
Detachment JES3 Exits
•Identify all used JES3 exits
•Identify all used PSF printing exits
•Create migration strategy (removal or transformation to exits)
•Create needed JES2 exits
We recommend starting the removal of JES3 exits as soon as possible.
Detachment JES3 special functions
•Replace JES3 DEADLINE
•Replace JES3 DJC
•Disable MDS
•Establish JES2 equivalent for all functions
•Disable JES3 DLOG and activate OPERLOG
We recommend starting the process to disable JES3 functions as soon as possible before the project starts.
 
For DLOG deactivation, you must rewrite some programs that are using DLOG.
Changes for JCL/JECL
•Convert production JCL
•Provide tool to convert user JCL
Try to align your production JCL to 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 RACF
•Assign permissions to stakeholders
•Add SDSF/EJES profiles to RACF
•Add profile definitions for changed printer names
The RACF permissions that are defined for JES2 should match to profiles that being made or exist for SDSF/EJES.
System automation
•Analyze JES3 automation that is in place
•Setup new JES2 automation
This task can take some time because you must review all 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
•Code new JES2 print exits
•Adjust procedures for printing that uses JES3 commands
Consider some extra time to create JES2 exits and conduct printing tests. We faced some unplanned issues that needed to be sorted.
JES2 setup
•Define JES2 setup according to your company defaults
•Calculate needed storage and request DASD for all systems
•Request all other resources that you need (HLQ, RACF, and STC)
•Request TCP/IP and firewall settings for NJE
•Start JES2 on all environments to verify the function
This task can be done during normal system operation time. JES2 can be run in parallel to JES3 as secondary subsystem. You should calculate some time to define all the standards you need for the JES2.
General things to do
•Provide education material
•Conduct education sessions
•Quit your JES3 license
These tasks are an important part of the project. To get the most 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.
6.2 Planning and assumptions
The case study that is described in this section is based on experience from a real customer situation with their JES3 migration. The case study was completed with z/OS V2R1and was now updated to the z/OS V2R4 level. This configuration makes a JES3 Migration much easier for customers. The customer runs eight sysplexes that vary 2 - 8 systems in the sysplex.
To enable all functions of z/OS V2R4, complete the following steps:
1. Migrate your JES2 Checkpoint to the z22 mode by using the $ACTIVATE command.
2. Enable SPOOL compression and encryption by using the $TSPOOLDEF,ADVF=ENABLED command.
3. Enable JES2 disk reader support by adding one or more SUBMITLIB and SUBMITRDR statements to your JES2 initialization member.
4. Use the new supported JES3 JECL ROUTE XEQ by enabling that support in your JES2 initialization member by using the following statements:
 – INPUTDEF JES3JECL=SUPPORT
 – JECLDEF JES3=(ROUTE=PROCESS)
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.
Identifying stakeholders
One of the first tasks that must be done is to identify all affected stakeholders. An example of an overview of the stakeholders, the possible affect, and the open tasks for that group of stakeholders is shown in Figure 6-1.
Figure 6-1 Stakeholder sample planning
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.
Figure 6-2 Expectations from stakeholders
Main differences overview
To give all stakeholders a brief overview what is going to be changed during migration, it might be helpful to provide a one-pager to all stakeholders. Use the chart that is shown in Figure 6-3 to provide a brief overview to your stakeholders about that main differences between both JES versions.
Figure 6-3 Overview JES comparison
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.
Example 6-1 CONTROL-M JES3 support
*-------------------------------------
* JES parameters
*-------------------------------------
JES JESTYPE=JES3, JES type installed
JESCHAR=*, JES command character
JESREL=, JES release
d= Method of issuing JES3 commands
To activate JES2 support for CONTROL-M, replace JESTYPE and JESCHAR statements to support JES2. The portion of the IOAPARM member with JES2 support is shown in Example 6-2.
Example 6-2 CONTROL-M JES2 support
*-------------------------------------
* JES parameters
*-------------------------------------
JES JESTYPE=JES2, JES type installed
JESCHAR=$, JES command character
JESREL=, JES release
JES3CMD= Method of issuing JES3 commands
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.
Example 6-3 JES3 EJES CAS
//EJESCAS PROC GDSN='JES3#A.RZ0.P0.EJES.GLOBAL.DATA',
// CDSN='JES3#A.RZ0.P0.INISH',
// MBR=EJESCASC,
// PRTY='(o)',
// SSYS=EJES,
// SC=T
//EJESCAS EXEC PGM=EJESCAS,TIME=1440,DPRTY=&PRTY,
// PARM='CASKEY=&SSYS'
//GBLDATA DD DSN=&GDSN,DISP=SHR
//CASCONFG DD DSN=&CDSN.(&MBR),DISP=SHR
//SYSABEND DD SYSOUT=&SC
//SYSOUT DD SYSOUT=*
//
When EJES is used with JES2, the CAS shared data set is no longer needed and can be removed from EJES CAS start procedures in your installation. An example of an EJES CAS started task for JES2 working with default values is shown in Example 6-4.
Example 6-4 JES2 EJES CAS
//EJESCAS PROC
//EJESCAS EXEC PGM=EJESCAS,TIME=1440
//SYSABEND DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//
 
 
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.
Example 6-5 ACF2 JES2 exits
LOAD(ACFJ2ITF) STOR=CSA /* ACF2/JES2 interface */
EXIT2 ROUTINE=ACFEXIT2 /* job card scan routine */
EXIT4 ROUTINE=ACFEXIT4 /* jcl card scan routine */
EXIT20 ROUTINE=ACFEXT20 /* end-of-rdr manager */
EXIT24 ROUTINE=ACFEXT24 /* Post-Initialization Exit */
EXIT26 ROUTINE=ACFEXT26 /* Termination Exit */
EXIT31 ROUTINE=ACFEXT31 /* SSI Data Set Allocation Exit */
EXIT34 ROUTINE=ACFEXT34 /* SSI Data Set Unallocation Exit */
EXIT46 ROUTINE=ACFEXT46 /* NJE Transmit Exit */
EXIT50 ROUTINE=ACFEXT50 /* end-of-rdr manager - user environment */
EXIT52 ROUTINE=ACFEXT52 /* job card scan routine - user environment */
EXIT54 ROUTINE=ACFEXT54 /* jcl card scan routine - user environment */
EXIT56 ROUTINE=ACFEXT56 /* NJE Transmit Exit - user environment */
EXIT225 ROUTINE=ACFEX225 /* subtask attach/post rtne */
EXIT227 ROUTINE=ACFEX227,DISABLE /* debug message routine */
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.
By using ThruPut Manager, customers can perform the following tasks:
•Better prioritize batch processing based on business policies and goals
•Automatically select the most urgent jobs first without system overload
•Verify that jobs include the resources that they need
•Proactively manage resource contention between jobs
The JES2 initialization statements of ThruPut manager are shown in Figure 6-4 on page 120. Most of the changes are the loading and activation of several JES2 exits that are used by ThruPut manager. In the customer case, we combined some ACF2 exits with another ThruPut manager exit (see Figure 6-4 for JES2 exit 2, 4, 24, 52, and 54).
/*-------------------------------------------------------------------*/
/* 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).
$HASP466 INCLUDE STMT 217 LOADMOD(DTMJ2MV7) STORAGE=PVT
$HASP466 INCLUDE STMT 217 /* LOAD MAIN TASK EXIT
$HASP466 INCLUDE STMT 217 MODULE */
$HASP003 RC=(34),LOADMOD(DTMJ2MV7) - DTMJ2MV7 - MODULE VERSION
$HASP003 IS INVALID, EXPECTED-z/OS 2.3 ACTUAL-z/OS 2.2
*3587 $HASP469 REPLY PARAMETER STATEMENT, CANCEL, OR END
Figure 6-5 Example of wrong JES2 exit version
You now must re-create the all of the JES2-depended exits with the correct version and reload the exit under JES2. Also, strong dependency exists between TM and JES2 control blocks. Therefore, after any JES2 maintenance that affects JES2 control blocks, you must recompile the following Thruput manager modules (z/OS version and maintenance level depended exist):
•DTMJ2DB7
•DTMJ2GO7
•DTMJ2MV7
•DTMJ2SV7
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.
Example 6-6 Basic TM commands for jobclass setup
$MJ,TM,CLASS,SET,Analyze(TMA)
$MJ,TM,CLASS,SET,General_Services(TMG)
$MJ,TM,CLASS,SET,On_Demand(TMO)
$MJ,TM,CLASS,DELETE(ALL)
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.
An example of starting the Thruput manager is shown in Figure 6-8. Upon completion, you can use the product in your installation.
$HASP100 MP00TM ON STCINRDR
IEF695I START MP00TM WITH JOBNAME MP00TM IS ASSIGNED TO USER BSTHPUT , GROUP OMVSGRP1
$HASP373 MP00TM STARTED
ACF9CCCD USERID TMMGR IS ASSIGNED TO THIS JOB - MP00TM
IEF403I MP00TM - STARTED - TIME=23.38.08 SC74
DTM0000I THRUPUT MANAGER AE 18.02 121
TMT7118 (C) COPYRIGHT 1985, 2019 COMPUWARE CORPORATION
ALL RIGHTS RESERVED.
DTM0051I SNAME=TPMAUTEDT+ CODE=MR.
DTM0055I License validation successful. TM processing continues
DTM8000I DATA SPACE SERVICES SUBTASK INITIALIZED
DTM8300I DATA COLLECTION SUBTASK INITIALIZED
DTM8137I SLM POLICY I/O SUBTASK STARTED
DTM8100I SLM TASK INITIALIZED
DTM7261I THRUPUT MANAGER XCF SERVICES SUBTASK INITIALIZATION COMPLETE
DTM0803I THE VOLUME INFORMATION FILE IS TPM.QUIKSTRT.VIF ON B00077
DTM0832I VIF INITIALIZATION COMPLETE
DTM6016I THE CONTROL FILE IS TPM.QUIKSTRT.CF ON B00074
DTM6028I THRUPUT MANAGER IS RECONCILING SC74 ON WTSCPLX
DTM7433I NO DBS CONFIGURATION IS CURRENTLY INSTALLED
DTM6029I RECONCILIATION OF SC74 ON WTSCPLX IS COMPLETE
DTM8184I SLM policy INITIAL has no initiator maximum for all members - ON DEMAND class defined
DTM6422I JLS RECONCILE COMPLETE
DTM8130I SLM POLICY INITIAL VALIDATED WITH WARNING(S)
DTM8128I SLM POLICY INITIAL ACTIVE ON S02 WITH WARNINGS
DTM7525I ROBOTIC RECONCILIATION IN PROGRESS
DTM7526I ROBOTIC RECONCILIATION COMPLETE
DTM0023I TMSS INITIALIZATION COMPLETE
DTM8102I SLM SERVER FUNCTION ACTIVE ON SC74
Figure 6-8 Startup of Thruput Manager
 
 
 
JES2 sysplex for testing
Early in the project, you should consider including sandbox sysplex with JES2 as the primary subsystem that is available for all stakeholders. In the customer environment, two systems were added that run native with JES2 added. A possible merger of two JES2 systems into an existing JES3 sysplex by adding two more systems is shown in Figure 6-9.
.
Figure 6-9 JES2 sandbox layout
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.
Figure 6-10 JES2 as secondary subsystem
JES2 expert nearby
During the migration project, it strongly recommended to have a JES2 expert on site or at least available by phone. Customers can experience many situations during the migration process in which access to an experienced JES2 expert was needed to quickly answer questions or solve technical problems. Otherwise, time and resources are wasted to get a problem fixed.
6.3 JES2 system design
The new JES2 system design should be flexible, easy to maintain, and simple to deploy. It also should match the following items that are compared with your existing JES3 installation:
•JES2 member names
•NJE node names
•Used Job classes
•Used Job output classes
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.
An example of a system-specific JES2 PARMLIB member is shown in Example 6-7. This member includes configuration statements that are unique to that particular system. All generic JES2 definitions are made available by using an INCLUDE statement in the system-specific PARMLIB member.
Example 6-7 Sample JES2 PARMLIB start member
/*-------------------------------------------------------------------*/
/* */
/* GDE: JES2 INIT AND TUNING REFERENCE */
/* DOC: THIS MEMBER CONTAINS THE INITIAL JES2 PARMS */
/* */
/* UPDATES: */
/* */
/*-------------------------------------------------------------------*/
/* INCLUDE THE STANDARD MEMBER WITH THE GENERAL DEFAULTS */
INCLUDE MEMBER=JES2&JESENV.STD
/*-------------------------------------------------------------------*/
/* CHECKPOINT - CKPT1 */
/* - CKPT2 BACKUP */
/* RECONFIGURATION USING: $TCKPTDEF,RECONFIG=YES */
/*-------------------------------------------------------------------*/
/* SEE JES2&JESENV.STD MEMBER FOR GENERAL DEFAULTS */
/*-------------------------------------------------------------------*/
CKPTDEF CKPT1=(STRNAME=JES2CKPT_1,INUSE=YES)
 
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,
VOLSER=SYA411)
/*-------------------------------------------------------------------*/
CKPTSPACE BERTNUM=55100 /* BLOCK EXTENSION REUSE TABLE */
CKPTSPACE BERTWARN=70 /* ALERT MESSAGE $HASP050 */
/*-------------------------------------------------------------------*/
/* MAS - MULTI ACCESS SPOOL - DEFINTION */
/*-------------------------------------------------------------------*/
MASDEF DORMANCY=(50,500)
MASDEF HOLD=00000050
MASDEF LOCKOUT=1000
/*-------------------------------------------------------------------*/
/* MEMBER DEFINITION */
/*-------------------------------------------------------------------*/
MEMBER(1) NAME=SYS1
MEMBER(2) NAME=SYS2
/*-------------------------------------------------------------------*/
/* SPOOL VOLUMES AND DEFINITIONS */
/*-------------------------------------------------------------------*/
SPOOLDEF VOLUME=SYA4
SPOOLDEF DSNMASK=JES2#A.&SYSNODE..&JESENV.0.SPOOL*
/*-------------------------------------------------------------------*/
SPOOL(SYA480) DSNAME=JES2#A.&SYSNODE..&JESENV.0.SPOOL80
SPOOL(SYA481) DSNAME=JES2#A.&SYSNODE..&JESENV.0.SPOOL81
SPOOL(SYA482) DSNAME=JES2#A.&SYSNODE..&JESENV.0.SPOOL82
SPOOL(SYA483) DSNAME=JES2#A.&SYSNODE..&JESENV.0.SPOOL83
/*-------------------------------------------------------------------*/
/* JOB DEFINITIONS */
/*-------------------------------------------------------------------*/
JOBDEF JOBNUM=40000
JOBDEF JOBWARN=80
JOBDEF RANGE=(1-65534)
JOBDEF INTERPRET=INIT
JOBDEF ACCTFLD=IGNORE
/*-------------------------------------------------------------------*/
/* INITDEF AND INIT - DEFINE INITIATORS */
/*-------------------------------------------------------------------*/
INITDEF PARTNUM=200
I(001-050) CLASS=(M1,P0,M,A), /* 50 INIT FOR ENGINEERING+BATEMERG */
START=YES,
NAME=BASE
I(051-100) CLASS=(S0,S1,S2), /* 50 INIT FOR SYSTEM JOBS */
START=YES,
NAME=BSYS
I(101-200) CLASS=(S0,S1,S2,M1,P0,M), /* SPARE INIT */
START=NO
/*-------------------------------------------------------------------*/
/* OUTDEF - OUTPUT DEFAULTS */
/*-------------------------------------------------------------------*/
OUTDEF JOENUM=60000
OUTCLASS(*) BLNKTRNC=YES, /* DEFAULTS FOR ALL CLASSES */
OUTDISP=(WRITE,WRITE), /* DISP NORMAL,ABEND */
OUTPUT=PRINT, /* */
TRKCELL=YES,           /* */
COMPRESS=YES           /* Enable SPOOL compression          */
OUTCLASS(C)
OUTCLASS(D)
OUTCLASS(E)
OUTCLASS(F)
OUTCLASS(G)
OUTCLASS(H)
OUTCLASS(I)
OUTCLASS(J)
OUTCLASS(L) OUTDISP=(WRITE,WRITE)
OUTCLASS(N) OUTPUT=DUMMY
OUTCLASS(O)
OUTCLASS(R) OUTDISP=(HOLD,HOLD)
/*-------------------------------------------------------------------*/
/* INCLUDE PRINTER DEFINITIONS */
/*-------------------------------------------------------------------*/
INCLUDE MEMBER=JES2PRT
/*-------------------------------------------------------------------*/
/* DEFINE NJE NODES */
/*-------------------------------------------------------------------*/
NODE(1) NAME=SYS1 /* OWNNODE=1 */
NETSRV1 SOCKET=LOCAL
SOCKET(SYS1) NODE=1,IPADDR=YOUR-ADRESS,SECURE=YES,PORT=2252
/*-------------------------------------------------------------------*/
NODE(2) NAME=SYS2
SOCKET(SYS2) NODE=2,IPADDR=YOUR-ADRESS,SECURE=YES,PORT=2252,CONNECT=YES
NODE(3) NAME=SYS3
SOCKET(SYS3) NODE=3,IPADDR=YOUR-ADRESS,SECURE=YES,PORT=2252,CONNECT=YES
/*-------------------------------------------------------------------*/
/* JES2 PROCESSOR NUMBERS (TASKS) */
/*-------------------------------------------------------------------*/
PCEDEF CNVTNUM=25 /* # CONVERTER PCE'S */
PCEDEF OUTNUM=10 /* # OUTPUT PCE'S */
PCEDEF PSONUM=10 /* # PSO PCE'S */
PCEDEF PURGENUM=10 /* # PURGE PCE'S */
PCEDEF SPINNUM=3 /* # SPIN PCE'S */
PCEDEF STACNUM=10 /* # TSO/ STATUS/CANCEL PCE'S */
/*-------------------------------------------------------------------*/
/* SMF DEFINITIONS ???? */
/*-------------------------------------------------------------------*/
SMFDEF BUFNUM=300 /* NUMBER OF SMF BUFFERS */
SMFDEF BUFWARN=80 /* WARNING THRESHOLD % */
/*-------------------------------------------------------------------*/
$D INITINFO /* WRITE INITIALIZATION INFO. TO HASPLIST */
/*-------------------------------------------------------------------*/
$T JOBCLASS(A),MODE=WLM /* SET CLASS=A TO WLM MANAGED ON PRODUCTION */
/*-------------------------------------------------------------------*/
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.
 
Information: The use of z/OS system symbols is recommended to include a more common PARMLIB member. By including this member, less effort is required later to maintain the JES2 parmlib.
The common part of our sample JES2 configuration is shown in Example 6-8. This member is valid and used for all of your systems. The following parameters can be used to code the common JES2 PARMLIB member:
PROCLIB Use z/OS system symbols to address system-specific PROCLIB. Also, the UNCOND option allows you to define PROCLIBs that must not be available when JES2 starts. That feature allows you to define PROCLIB in the common member that is not available on all systems; for example, on IBM GDPS® controlling systems.
JOBCLASS Define all of your job classes that your installation needs. It is recommended to lower your migration effort to define the same jobclasses you used in your JES3 installation. You can code all common parameters that apply to all job classes after the specific definitions with the JOBCLASS(*) statement. All job classes are enabled by default. If you do not want all job classes to be active, use the ACTIVE=NO option for all job classes that you do not need.
ESTLNCT Under JES3 per default, all tasks abend with S722 when they produce more than 16 million lines of output. The ESTLNCT statement that is shown in Example 6-8 shows how to limit tasks to under 16 million lines of output (16,000 x 1000 lines of output).
NJEDEF For performance reasons, define the number of transmit and receive paths to a maximum of four. For more information about defining NJE connections, see Chapter 6.12, “Hints and tips” on page 172.
OUTPRTY Defines a priority of JES2 output elements based on their size. We set a common priority for all output elements as does JES3 to avoid enabling JES2 to perform a reorder for printed output.
Example 6-8 Sample common JES2 PARMLIB
/*-------------------------------------------------------------------*/
/* GDE: JES2 INIT AND TUNING REFERENCE */
/* DOC: this Member contains the initial Base JES2 Parms */
/* included within member JES2P00 valid for all Systems. */
/* */
/* UPDATES: */
/*********************************************************************/
/* DEFINE JES2 PROCLIB */
/*-------------------------------------------------------------------*/
PROCLIB(PROC00) DD(1)=(DSN=SYS1.&SYSNODE..ZOS.PROCLIB)
PROCLIB(PROC00) DD(2)=(DSN=SYS1.DIV.ZOS.PROCLIB)
PROCLIB(PROC00) DD(3)=(DSN=SYS1.DIV.IBM.PROCLIB)
PROCLIB(PROC00) DD(4)=(DSN=SYS1.&SYSNODE..SUB.PROCLIB)
PROCLIB(PROC00) DD(5)=(DSN=PCL.U0000.P0.&[email protected]),
UNCOND
PROCLIB(PROC00) DD(6)=(DSN=PCL.U0000.P0.&[email protected]),
UNCOND
PROCLIB(PROC00) DD(7)=(DSN=JOBP.SYSA.PROC),UNCOND
PROCLIB(PROC00) DD(8)=(DSN=JOBP.AL&RZID.A.PROC),UNCOND
/*-------------------------------------------------------------------*/
/* DEFINE JES2 CHECKPOINT */
/*-------------------------------------------------------------------*/
CKPTDEF MODE=DUPLEX
CKPTDEF DUPLEX=ON
CKPTDEF VOLATILE=(ONECKPT=IGNORE)
CKPTDEF OPVERIFY=NO
/*-------------------------------------------------------------------*/
/* DEFINE JES2 MULTI ACCESS SPOOL (MAS) */
/*-------------------------------------------------------------------*/
MASDEF AUTOEMEM=ON
MASDEF OWNMEMB=&SYSNAME
MASDEF XCFGRPNM=JES2&SYSNODE.&JESENV. /* */
MASDEF CYCLEMGT=AUTO
/*-------------------------------------------------------------------*/
/* DEFINE JES2 SPOOL */
/*-------------------------------------------------------------------*/
SPOOLDEF BUFSIZE=3992
SPOOLDEF TGSIZE=36
SPOOLDEF TRKCELL=4
SPOOLDEF LARGEDS=ALWAYS /* MORE THAN 64 TRACKS, MAX. 1M TRACKS */
SPOOLDEF SPOOLNUM=32
SPOOLDEF TGSPACE=(MAX=5000000) /* 15 Mio Tracks */
SPOOLDEF CYL_MANAGED=ALLOWED /*enables CYLinder managed space */
/*-------------------------------------------------------------------*/
/* JOB DEFINITION */
/*-------------------------------------------------------------------*/
JOBDEF PRTYJECL=NO
JOBDEF DEF_CLASS=A
JOBDEF CNVT_SCHENV=HONOR
JOBDEF DUPL_JOB=DELAY
JOBDEF ACCTFLD=IGNORE
/*-------------------------------------------------------------------*/
/* DEFINE JES2 JOBCLASSES */
/* VARY OFF 1 SYS.(BATCH OFF): $TJOBCLASS(P0,P1,P2,P3),QAFF=-S03 */
/* (OR SCHENV DEFAULT + DEFBASE ??? ) */
/*-------------------------------------------------------------------*/
/* SYSTEM JOBS + ENGINEERING *************/
JOBCLASS(S0,S1,M1,M) COMMAND=IGNORE,
MSGCLASS=T, /* DEFAULT MESSAGE CLASS */
MODE=JES /* SYST/ENG WITH JES INIT */
JOBCLASS(S2) COMMAND=IGNORE,
MSGCLASS=T, /* DEFAULT MESSAGE CLASS */
MODE=JES, /* SYST/ENG WITH JES INIT */
XEQCOUNT=MAXI=25 /* MAXIMUM OF 25 JOBS PER SYSPLEX */
/* USER JOBS *************/
JOBCLASS(A) COMMAND=IGNORE,
MSGCLASS=T, /* DEFAULT MESSAGE CLASS */
MODE=JES /* WLM INIT'S */
/* PRODUCTION JOBS (BATEMERG) *************/
JOBCLASS(P0) COMMAND=IGNORE,
MSGCLASS=E, /* DEFAULT MESSAGE CLASS */
MODE=JES /* BATEMERG WITH JES INIT */
/* PRODUCTION JOBS (BATLOW/BATMED/BATHIGH) */
JOBCLASS(P1,P2,P3) COMMAND=IGNORE,
MSGCLASS=E, /* DEFAULT MESSAGE CLASS */
MODE=WLM /* WLM INIT'S */
JOBCLASS(STC,TSU) COMMAND=IGNORE,
MSGCLASS=E /* DEFAULT MESSAGE CLASS */
/*-------------------------------------------------------------------*/
/* Disable all unused Jobclasses */
/*-------------------------------------------------------------------*/
JOBCLASS(B,C,D,E,F,G,H,I,J,K,L,N,O,P,Q,R,S,T,U,V,W,X,Y,Z) ACTIVE=NO
JOBCLASS(0,1,2,3,4,5,6,7,8,9) ACTIVE=NO
/*-------------------------------------------------------------------*/
/* Defaults valid for all Jobclasses */
/*-------------------------------------------------------------------*/
JOBCLASS(*) REGION=1200M, /* REGION DEFAULT FÜR BATCH */
MSGLEVEL=(1,1), /* JOB, ALL MSGS */
SWA=ABOVE, /* SWA CONT.BLOCKS ABOVE THE 16M-LINE */
PROCLIB=00, /* PROCLIB(PROC00) */
SCHENV=DEFAULT, /* DEFAULT SCHENV (OR DEFBASE?) */
TIME=(1439,00), /* 23H + 59M TIME LIMIT FOR JOB STEP */
PROMO_RATE=3, /* promotion rate for STARTBY function */
SYSSYM=ALLOW /* ALLOW USAGE OF SYSTEM SYMBOLS */
/*-------------------------------------------------------------------*/
/* ESTBYTE - Default estimated SYSOUT bytes/Job $HASP375 */
/*-------------------------------------------------------------------*/
ESTBYTE NUM=99999 /* 99999 KBYTES FOR 1ST MESSAGE */
ESTBYTE INT=50000 /* THEN AT 50000 KBYTE INTERVALS */
ESTBYTE OPT=0 /* ALLOW JOBS TO CONTINUE */
/* 0 Job is allowed to continue execution */
/* 1 Job is canceled without a dump */
/* 2 Job is canceled with a dump */
/* (if a dump statement was coded for this job step) */
/*-------------------------------------------------------------------*/
/* ESTLNCT - Default estimated SYSOUT lines/Job $HASP375 */
/*-------------------------------------------------------------------*/
ESTLNCT NUM=16000 /* Limit to 16M Lines per Job */
ESTLNCT INT=10000 /* THEN AT 10K LINE INTERVALS */
ESTLNCT OPT=1 /* Job will be canceled by JES    */
/*-------------------------------------------------------------------*/
ESTPAGE NUM=500 /* 1K PAGES FOR 1ST MESSAGE */
ESTPAGE INT=250 /* THEN AT 100 PAGE INTERVALS */
ESTPAGE OPT=0 /* ALLOW JOBS TO CONTINUE */
/*-------------------------------------------------------------------*/
/* ESTPUN - Default estimated PUNCH cards/Job $HASP375 */
/*-------------------------------------------------------------------*/
ESTPUN NUM=10000 /* 10K CARDS FOR 1ST MESSAGE */
ESTPUN INT=5000 /* THEN AT 2000 CARD INTERVALS */
ESTPUN OPT=0 /* ALLOW JOBS TO CONTINUE */
/*-------------------------------------------------------------------*/
/* INTRDR - Internal Reader Definition */
/*-------------------------------------------------------------------*/
INTRDR CLASS=A /* DEFAULT JOB CLASS */
/*-------------------------------------------------------------------*/
/* LOADMOD/EXIT - JES2 EXITS */
/*-------------------------------------------------------------------*/
LOADMOD(HASX06A) /* EXIT FOR DD DSN=...#DT# */
EXIT(6) ROUTINES=(EXIT06) /* JES2 CONVERTER EXIT */
LOADMOD(HASX23A) STORAGE=CSA /* EXIT FOR PSF HEADER,TRAILER */
EXIT(23) ROUTINES=(EXIT23) /* JES2 FSS EXIT */
/*-------------------------------------------------------------------*/
/* CONDEF - Console Definition */
/*-------------------------------------------------------------------*/
CONDEF DISPLEN=70 /* LENGTH OF OUTPUT LINES ON CONSOLE */
CONDEF DISPMAX=1000 /* # OF OUTPUT LINES/MSG ON CONSOLE */
CONDEF CMDNUM=3000 /* CONSOLE MESSAGE BUFFER */
CONDEF BUFNUM=3000 /* CONSOLE MESSAGE BUFFER */
CONDEF BUFWARN=50 /* Warnings at 50% usage */
/*-------------------------------------------------------------------*/
/* NJE Definitions */
/*-------------------------------------------------------------------*/
NJEDEF LINENUM=15 /* MAX NUMBER OF NJE LINE'S */
NJEDEF JRNUM=4 /* MAX NUMBER OF Job receiver */
NJEDEF JTNUM=4 /* MAX NUMBER OF Job transmitter */
NJEDEF SRNUM=4 /* MAX NUMBER OF Sysout Receiver */
NJEDEF STNUM=4 /* MAX NUMBER OF Sysout Transmitter */
NJEDEF NODENUM=15 /* MAX NODE NUMBER */
NJEDEF OWNNODE=1 /* NODE(1) */
NJEDEF TIMETOL=0 /* ALLOW TIME DIFFERENCES with PTA */
NODE(*) PATHMGR=NO /* PATHMGR not used due to conn failures*/
LINE(1-15) UNIT=TCP,START=YES,CONNECT=(YES,10)
/*-------------------------------------------------------------------*/
/* PCE Definitions */
/*-------------------------------------------------------------------*/
SUBTDEF GSUBNUM=40 /* # of JES2 worker tasks */
PCEDEF CNVTNUM=25 /* # CONVERTER PCE'S */
PCEDEF OUTNUM=25 /* # OUTPUT PCE'S */
PCEDEF PSONUM=10 /* # PSO PCE'S */
PCEDEF PURGENUM=25 /* # PURGE PCE'S */
PCEDEF SPINNUM=10 /* # SPIN PCE'S */
PCEDEF STACNUM=10 /* # TSO/ STATUS/CANCEL PCE'S */
/*-------------------------------------------------------------------*/
/* Set Output Priority default to 8                                  */
/*-------------------------------------------------------------------*/
OUTPRTY(*) PAGE=16000000,PRIORITY=8,RECORD=16000000
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.
Example 6-9 Sample of JES2 start procedure
//JES2 PROC P=WARM,R=NOREQ,
// M=00, 00 = ACTIVE, 90=BACKUP
// JE=&JESENV, P = PROD-JES, T=TEST-JES
// JO='DSORG=PS', DUMMY = SET HASPLIST TO DUMMY
// RZ=&RZDSN DEFAULT FROM SYSTEM SYSTEM-SYMBOL
//*******************************************************************
//* FUNCTION: START JES2 SUBSYSTEM
//* RESPONSIBLE: z/OS Department
//* AT ABEND: CALL MVS ON CALL SERVICE
//*
//* START JES: /S JES2
//* STOP JES: /$PJES2
//* STOP JES: /$PJES2,ABEND
//*
//*******************************************************************
//ALLOC EXEC PGM=IEFBR14,TIME=1440
//DD1 DD &JO,
// DSN=JES2#A.&RZ..&JE.0.&SYSNAME..HASPLIST.D&LYYMMDD..T&LHHMMSS,
// UNIT=DISK,MGMTCLAS=COM#A064,
// SPACE=(TRK,(15,15),RLSE),DISP=(NEW,CATLG),
// LRECL=121,RECFM=FBA
//*
//JES2 EXEC PGM=HASJES20,TIME=1440,
// PARM='&P.,PARMLIB_MEMBER=JES2&JE.&M.,&R'
//STEPLIB DD DISP=SHR,DSN=SYS1.SHASLNKE
//HASPLIST DD &JO,
// DSN=*.ALLOC.DD1,DISP=SHR
//*
The start parameters are listed in Table 6-2.
Table 6-2 JES2 start parameters
Start parameter
Description
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.
The grouping of initiators to job classes should be planned and depends on the customers environment.
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.
Consider the following recommendations for the JES2 checkpoint:
•Place CKPT1 in the Coupling Facility (CF), if possible.
•Place CKPT2 on a separate DASD; no other data set should be allocated on that DASD.
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.
Example 6-10 Display of active Checkpoint definitions
$DCKPTDEF
$HASP829 CKPTDEF
$HASP829 CKPTDEF CKPT1=(STRNAME=JES2CKPT_1,INUSE=YES,VOLATILE=YES),
$HASP829 CKPT2=(DSNAME=JES2#A.RZ4.P0.CKPT2,VOLSER=SYA410,
$HASP829 INUSE=YES,VOLATILE=NO),
 
$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=(ONECKPT=IGNORE,ALLCKPT=WTOR),OPVERIFY=NO
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.
Table 6-3 Comparison of SPOOL values
Value
Total cylinder JES3
Total cylinder JES2
SPOOL size
225175 Cyl
480640 Cyl
Number of DASD
31
8
Under JES3, the average SPOOL utilization was approximately 50%. Under JES2, we see an average of 29% SPOOL utilization, as shown in Example 6-11.
Example 6-11 Sample JES2 SPOOL utilization
$DSPL
$HASP893 VOLUME(SYA280) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA281) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA282) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA283) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA284) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA285) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA286) STATUS=ACTIVE,PERCENT=29
$HASP893 VOLUME(SYA287) STATUS=ACTIVE,PERCENT=29
$HASP646 29.2025 PERCENT SPOOL UTILIZATION
 
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.
Example 6-12 Sample JES2 SPOOL definitions
$DSPOOLDEF
$HASP844 SPOOLDEF
$HASP844 SPOOLDEF BUFSIZE=3992,DSNAME=SYS1.HASPACE,
$HASP844 DSNMASK=JES2#A.RZ2.P0.SPOOL*,FENCE=(ACTIVE=NO,
$HASP844 VOLUMES=1),GCRATE=NORMAL,
$HASP844 LASTSVAL=(2015.290,16:06:08),LARGEDS=ALWAYS,
$HASP844 SPOOLNUM=32,TGSIZE=36,TGSPACE=(MAX=5000416,
$HASP844 DEFINED=2403340,ACTIVE=2403340,PERCENT=29.2117,
$HASP844 FREE=1701283,WARN=80),TRKCELL=4,VOLUME=SYA2
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.
An example of how NJE servers should be running is shown in Figure 6-11 on page 134.
Cmd Device Status SysName ServName SysID JESLevel
--- -------- -------- ------- -------- ----- --------
NETSRV1 DRAINED S21 R21 z/OS 2.4
NETSRV1 DRAINED S22 R22 z/OS 2.4
NETSRV1 DRAINED S23 R23 z/OS 2.4
NETSRV1 DRAINED S24 R24 z/OS 2.4
NETSRV1 DRAINED S25 R25 z/OS 2.4
NETSRV1 DRAINED S26 R26 z/OS 2.4
NETSRV1 DRAINED S27 R27 z/OS 2.4
NETSRV1 ACTIVE S28 JES2S001 R28 z/OS 2.4
Figure 6-11 NETSRV sysplex view
JES 2 cold start
After all of the tasks that are described thus far in this chapter are completed successfully, initialize your checkpoint data sets and your SPOOL data sets. This process can be done by using JES2 cold start.
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.
Example 6-13 Sample JES2 cold start
S JES2,P=COLD
IEF403I JES2 - STARTED - TIME=20.33.48 S00
IEE252I MEMBER JES2T00 FOUND IN SYS1.RZ0.ZOS.PARMLIB
IEE252I MEMBER JES2T00 FOUND IN SYS1.RZ0.ZOS.PARMLIB
IEE252I MEMBER JES2PSTD FOUND IN SYS1.DIV.ZOS.PARMLIB
IEE252I MEMBER JES2PSTD FOUND IN SYS1.DIV.ZOS.PARMLIB
IXZ0001I CONNECTION TO JESXCF COMPONENT ESTABLISHED, 382
GROUP JES2RZ0T MEMBER RZ0T$S00
 IEF403I IEESYSAS - STARTED - TIME=20.33.49 S00
$HASP9084 JES2 MONITOR ADDRESS SPACE STARTED FOR JES2
$HASP537 THE CURRENT CHECKPOINT USES 5282 4K RECORDS
*$HASP436 CONFIRM z22 MODE COLD START ON 417
CKPT1 - VOLSER=SYA013 DSN=JES2#A.RZ0.T0.CKPT1
CKPT2 - VOLSER=SYA013 DSN=JES2#A.RZ0.T0.CKPT2
SPOOL - PREFIX=SYA01 DSN=SYS1.HASPACE
*374 $HASP441 REPLY 'Y' TO CONTINUE INITIALIZATION OR 'N' TO TERMINATE IN RESPONSE TO MESSAGE HASP436
R 374,Y
IEE600I REPLY TO 374 IS;Y
$HASP478 INITIAL CHECKPOINT READ IS FROM CKPT1 424
(JES2#A.RZ0.T0.CKPT1 ON SYA013)
LAST WRITTEN TUESDAY, 19 JUN 2018 AT 18:28:52 (GMT)
*$HASP493 JES2 COLD START IS IN PROGRESS - z22 MODE
$HASP266 JES2 CKPT2 DATA SET IS BEING FORMATTED
$HASP267 JES2 CKPT2 DATA SET HAS BEEN SUCCESSFULLY FORMATTED
$HASP266 JES2 CKPT1 DATA SET IS BEING FORMATTED
$HASP267 JES2 CKPT1 DATA SET HAS BEEN SUCCESSFULLY FORMATTED
$HASP850 5000 TRACK GROUPS ON SYA013
$HASP851 4995416 TOTAL TRACK GROUPS MAY BE ADDED
IXZ0001I CONNECTION TO JESXCF COMPONENT ESTABLISHED, 435
GROUP SYSJ2$XD MEMBER JES2RZ0T$S00$$$$
$HASP492 JES2 COLD START HAS COMPLETED - z22 MODE
$HASP261 Member S00 performs deadline scheduling processing
$HASP249 COMMAND RECEIVED FROM INITIALIZATION 438
$DINITINFO
$HASP825 INITINFO 439
$HASP825 INITINFO --- Command used to start JES2
$HASP825 S JES2,P=COLD
$HASP825 --- HASPPARM data sets read
 
Information: In customers’ environments, a JES2 cold start with eight 3390-54 volumes that are defined for SPOOL took almost 9 minutes to complete.
6.4 Educating stakeholders
One of the most important aspects of migration is a working communication concept and in parallel, supportive education for stakeholders. These facets increase the acceptance of the project significantly.
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
 – TYPRUN=HOLD
 – Scheduling: JES
 – Scheduling: WLM
 – Queue affinity: JOBCLASS QAFF
 – Queue hold: JOBCLASS QHELD
 – Execution count: JOBCLASS XEQC
 – Stop Member Execution – $PXEQ
 – Stop JES2 Member: $P
 – JES initiator status
 – JES initiator halted or drained: $ZI/$PI
 – All JES initiators in use
 – All WLM initiators in use
 – Duplicate job name
 – Duplicate job name: Support on JOBCLASS
 – Job waiting for scheduling environment
 – Start job $SJ
 – Execution
 – Data set handling: JES3
 – Data set handling: JES2 (no SETUP or Locate)
 – Waiting for data set
 – Multiple jobs or data sets waiting
 – Requeue job: Waiting for data set
 – Send a message to a job log: EXEC
 – Output class
 – Output disposition
 – OUTPUT statement
 – Output group
 – Output group: JES2 display
 – Output group: SDSF display
 – Output samples
•JES2 features:
 – System/Sysaff (JES3 2.1)
 – JOB CLASS support (JES3 2.1)
 – Job correlator: UJOBCORR
 – Spin off JESLOG (JES3)
 – Spin off SYSOUT
 – Return and condition code step and job
 – Instream PROCs and INCLUDEs (JES3 2.1)
 – System symbols in batch (JES3 2.1)
 – Instream symbols
 – Big step program parameters (JES3 2.1)
 – Batch job enqueue downgrade
 – TSO multiple logon (JES3 2.1)
•JES2 JCL migration:
 – JCL changes: JOB
 – JCL changes: DD
 – JCL changes: OUTPUT
 – JCL changes: others
 – JES3 JECL statements
 – JES2 JECL statements
•JES2 commands overview:
 – JES2 commands in general
 – Display job: $DJ
 – Set and modify job: $TJ
 – Spool monitoring
 – Other shortages
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
6.5 Removing and replacing JES3 exits
The removal or replacement of all installed JES3 user exits to JES2 depends on the customer’s installation. During the migration project, we created a list of all installed JES3 exits and had to make the following decisions:
•Keep the exits and transfer them to the appropriate JES2 exit.
•Delete the exit that is under JES3.
•No longer needed under JES2, so leave them as is alone and delete them during migration.
 
Important: All newly created JES2 exits must be on the same software level, such as the destination JES2 level.
 
Next, we describe some general recommendations for migrating JES exits. The use of JES2 exits is shown in Figure 6-12.
Figure 6-12 JES2 exit flowchart
The execution environments for JES2 exits are listed in Table 6-4.
Table 6-4 JES2 exit execution environments
Type
Location
Description
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.
 
Special operating environment called (USER,ANY) - ENVIRON=(USER,ANY) on $MODULE or $ENVIRON statement (R11 = HCCT address).
 
If the routine is called by the JES2 main task, $SAVE/$RETURN are called. It is not possible to work with the linkage stack (BAKR). In any environment, a PSV-type save area is obtained rather than using a BAKR.
4
FSS Address space
Functional subsystem (FSS) is in the functional subsystem address space. Similar to the user environment (JES2 services are limited). Task interaction within the FSS. All data areas and control blocks are not accessible from the FSS. Accessible control blocks are $JOE, $JIB, FSSCB, FSACB, and system-wide MVS services.
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.
For testing purposes, you can use some of the JES2 commands that are listed in Table 6-5 to dynamically activate or deactivate JES2 exits.
Table 6-5 Useful JES2 exit commands
Command
Description
$ADD LOADMOD(x),STOT=PVT
Load a load module
$DEL LOADMOD(x)
Delete a load module
$T LOADMOD(x),REFRESH
Reload a new copy of a load module
$T EXIT(n),ROUTINES=
Change routines in list ROUTINES=+routine or ROUTINES=-routine allowed
$T EXIT(n),REFRESH
Locate most recent copy of exit routine
$D EXIT(n),LONG
Display more information
$T EXITt(006),STATUS=DISABLED
Disable (deactivate) an activated JES2 exit on that particular system
$TEXIT(xx),ROUTINE=<your mod>,STATUS=ENABLED,TRACE=NO
Enable (activate) a loaded JES2 exit on that particular system
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.
Customer-installed JES3 exits are listed in Table 6-6.
Table 6-6 Customers JES3 exits
JES3 Exit
Description
Action
IATUX69
LOCAL MESSAGE EXIT
Removed; custom made DEADLINE processing replaced
IATUX70
GLOBAL MESSAGE EXIT
Removed; custom made DEADLINE processing replaced
IATUD02
DSP LOCATE
No carry over; function does not exit under JES2
IATUD05
DSP II/ INQUIRE INITS
No carry over; function does not exit under JES2
IATUX09
INTRDR POSTSCAN EXIT
To be defined in JES2 PARMLIB
IATUX03
MODIFY JCL CHANGE ADD DSNAME
Removed; application that includes needed modified JES3 message is changed
IATUX29
CHANGES IN IATUX29 SET SA-LIM TO 200 FOR IBM IMS - JOBS (CNTL-,MPP-) NO PROD-CLS FOR TESTJOBS
Removed because SETUP no longer exits
IATDLTM
DEADLINE, ISSUE AUTOM. F J/NNNN R
Removed; custom made DEADLINE processing replaced
IATUD08
DSP INTERC
Removed; no longer used
IATUX19
Printer output routing selection
Removed
IATUX04
CHECK FOR CORRECT PROKOS-# IN JOB ACCOUNTING
Removed; in JES2, we use another method to pass parameter for start
IATUX15
INISH - DECK MODIFICATION EXIT
Removed; custom made function that can be removed
IATGRPT
FUNCTION CONTROL TABLE DEFINE USER DSP'S
Removed; no longer needed with JES2
IATOSFP
MSG-CHANGE IAT7007
Removed; belongs to IATUX03 and application was changed
IATUX28
IATUX29
IATUX33
IATUX40
IATSIOR
ACF2 interceptor exits
Use of JES2 interceptors instead (for more information, see Example )
IATUX45
3800-3 IATUX45
Transfer the function to JES2 exit HASX23A
Many of these exits belong to JES3 unique functions and do not feature anything to migrate (see Example 6-16).
Example 6-14 Sample ACF2 exit interceptors
LOAD(ACFJ2ITF) STOR=CSA /* ACF2/JES2 interface */
EXIT2 ROUTINE=ACFEXIT2 /* job card scan routine */
EXIT4 ROUTINE=ACFEXIT4 /* jcl card scan routine */
EXIT20 ROUTINE=ACFEXT20 /* end-of-rdr manager */
EXIT24 ROUTINE=ACFEXT24 /* Post-Initialization Exit */
EXIT26 ROUTINE=ACFEXT26 /* Termination Exit */
EXIT31 ROUTINE=ACFEXT31 /* SSI Data Set Allocation Exit */
EXIT34 ROUTINE=ACFEXT34 /* SSI Data Set Unallocation Exit */
EXIT46 ROUTINE=ACFEXT46 /* NJE Transmit Exit */
EXIT50 ROUTINE=ACFEXT50 /* end-of-rdr manager - user environment */
EXIT52 ROUTINE=ACFEXT52 /* job card scan routine - user environment */
EXIT54 ROUTINE=ACFEXT54 /* jcl card scan routine - user environment */
EXIT56 ROUTINE=ACFEXT56 /* NJE Transmit Exit - user environment */
EXIT225 ROUTINE=ACFEX225 /* subtask attach/post rtne */
EXIT227 ROUTINE=ACFEX227,DISABLE /* debug message routine */
Using JES2 policies
Another possibility to migrate JES3 exits is the new function that is called JES2 policies. JES2 introduces JES2 policies as a way to customize JES2 processing without exit programming. This support also reduces the need for specific JES2 logic skills and improves JES2 reliability by isolating JES2 from bugs in JES2 exit programs.
JES2 policies provide a way to customize JES2 processing without programming. Users formulate customization requirements in high-level terms based on general understanding of z/OS jobs and their attributes. These requirements are defined to the JES2 in a high-level human readable syntax. JES2 code applies customization requirements that are described in applicable policies in strategic points in JES2 processing.
 
Attention: JSON names are case-sensitive and must be entered exactly as defined.
An example of the use of JES2 policies is shown in Figure 6-13.
{ "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) "
}
]
}
]
}
Figure 6-13 Sample JES2 policy
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.
 
 
Print exits
In a customer environment, PSF is used to print documents on high-end printers and office printers. Some documents required a Header and Trailer page. Therefore, several PSF exits are in place, as listed in Table 6-7.
Table 6-7 Sample JES Printer exits
JES3 Exit
JES2 Exit
Description
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.
Job and user information often is used on header pages.
6.6 Transforming JES3 special functions
JES3 provides some special functions that are not available in JES2 or for which a full equivalent in JES2 does not exist.
 
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.
Dependent job control
Dependent job control (DJC) is a method of handling multiple jobs that must be run in a specific order because of job dependencies. DJC manages jobs that depend on one another.
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).
Example 6-15 Example of using JES2 JOBGROUP
//LUTZ JOBGROUP (SYSPRG,MIST,,0815),
// 'KÜHNER',
// OWNER=A710622,
// HOLD=NO,
// ONERROR=(STOP),
// SYSTEM=(SC80),
// SCHENV=DEFAULT
//A710JOBA GJOB
//A710JOBB GJOB
// AFTER NAME=A710JOBA,WHEN=(RC=0)
//A710JOBC GJOB
// AFTER NAME=A710JOBA,WHEN=(RC=4)
//A710JOBD GJOB
// AFTER NAME=A710JOBB
// AFTER NAME=A710JOBC
//LUTZ ENDGROUP
//A710JOBA JOB (RJO89350,LIPA,,1157),MSGCLASS=T,MSGLEVEL=(1,1),
// CLASS=M,NOTIFY=&SYSUID
// SCHEDULE JOBGROUP=LUTZ
//IEFBR1 EXEC PGM=IEFBR14
//
//A710JOBB JOB (RJO89350,LIPA,,1157),MSGCLASS=T,MSGLEVEL=(1,1),
// CLASS=M,NOTIFY=&SYSUID
// SCHEDULE JOBGROUP=LUTZ
//IEFBR1 EXEC PGM=IEFBR14
//
//A710JOBC JOB (RJO89350,LIPA,,1157),MSGCLASS=T,MSGLEVEL=(1,1),
// CLASS=M,NOTIFY=&SYSUID
// SCHEDULE JOBGROUP=LUTZ
//IEFBR1 EXEC PGM=IEFBR14
//
//A710JOBD JOB (RJO89350,LIPA,,1157),MSGCLASS=T,MSGLEVEL=(1,1),
// CLASS=M,NOTIFY=&SYSUID
// SCHEDULE JOBGROUP=LUTZ
//IEFBR1 EXEC PGM=IEFBR14
//
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.
Example 6-16 Successfully job group registration
11.45.17 JOB02568 $HASP1300 A710JOBA registered to job group LUTZ
11.45.17 JOB02568 $HASP1301 A710JOBA in job group LUTZ queued for execution
11.45.17 JOB02569 $HASP1300 A710JOBB registered to job group LUTZ
11.45.17 JOB02570 $HASP1300 A710JOBC registered to job group LUTZ
11.45.17 JOB02571 $HASP1300 A710JOBD registered to job group LUTZ
Based on Example 6-15, we show you the same logic in Figure 6-14 on page 145.
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.
Example 6-17 Sample job group messages
11:55:56.16 JOB02578 00000080 ICH70001I LUTZ LAST ACCESS AT 11:54:24 ON FRIDAY, JUNE 8, 2018
11:55:56.16 JOB02578 00000080 $HASP373 A710JOBA STARTED - WLM INIT - SRVCLASS DFLT - SYS SC80
11:55:56.17 JOB02578 00000080 Jobname Procstep Stepname CPU Time EXCPs RC
11:55:56.17 JOB02578 00000080 A710JOBA --None-- IEFBR1 00:00:00 8 00
11:55:56.17 JOB02578 00000080 $HASP395 A710JOBA ENDED - RC=0000
11:55:56.17 G0002577 00000080 $HASP1305 A710JOBC in job group LUTZ is flushed
11:55:56.17 JOB02579 00000080 $HASP1301 A710JOBB in job group LUTZ queued for execution
11:55:56.17 INTERNAL 00000280 SE '11.55.56 JOB02578 $HASP165 A710JOBA ENDED AT WTSCPLX8 MAXCC=0000'
,LOGON,USER=(LUTZ)
11:55:56.17 INTERNAL 00000280 SE '11.55.56 JOB02581 $HASP165 A710JOBC ENDED AT WTSCPLX8 - FLUSHED',
LOGON,USER=(LUTZ)
11:55:56.17 JOB02579 00000080 ICH70001I LUTZ LAST ACCESS AT 11:55:56 ON FRIDAY, JUNE 8, 2018
11:55:56.17 JOB02579 00000080 $HASP373 A710JOBB STARTED - WLM INIT - SRVCLASS DFLT - SYS SC80
11:55:56.18 JOB02579 00000080 Jobname Procstep Stepname CPU Time EXCPs RC
11:55:56.18 JOB02579 00000080 A710JOBB --None-- IEFBR1 00:00:00 8 00
11:55:56.18 JOB02579 00000080 $HASP395 A710JOBB ENDED - RC=0000
11:55:56.18 JOB02582 00000080 $HASP1301 A710JOBD in job group LUTZ queued for execution
11:55:56.18 INTERNAL 00000280 SE '11.55.56 JOB02579 $HASP165 A710JOBB ENDED AT WTSCPLX8 MAXCC=0000'
,LOGON,USER=(LUTZ)
11:55:56.19 JOB02582 00000080 ICH70001I LUTZ LAST ACCESS AT 11:55:56 ON FRIDAY, JUNE 8, 2018
11:55:56.19 JOB02582 00000080 $HASP373 A710JOBD STARTED - WLM INIT - SRVCLASS DFLT - SYS SC80
11:55:56.19 JOB02582 00000080 Jobname Procstep Stepname CPU Time EXCPs RC
11:55:56.19 JOB02582 00000080 A710JOBD --None-- IEFBR1 00:00:00 8 00
11:55:56.19 JOB02582 00000080 $HASP395 A710JOBD ENDED - RC=0000
11:55:56.19 G0002577 00000080 $HASP1304 job group LUTZ is complete
11:55:56.19 INTERNAL 00000280 SE '11.55.56 JOB02582 $HASP165 A710JOBD ENDED AT WTSCPLX8 MAXCC=0000'
,LOGON,USER=(LUTZ)
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.
Example 6-18 Example of JES2 JCL SCHEDULE
//A710JES2 JOB (RJO89350,LIPA,,1157),MSGCLASS=T,MSGLEVEL=(1,1),
// CLASS=M,NOTIFY=&SYSUID
// SCHEDULE HOLDUNTL=('12:50',05/28/2018),STARTBY=('13:00',05/28/2018)
// SCHEDULE HOLDUNTL=('12:40',05/28/2018)
// SCHEDULE STARTBY='+01:00'
//*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
//IEFBR1 EXEC PGM=IEFBR14
//
 
Attention: The JCL that is shown in Example 6-18 demonstrates the power of the SCHEDULE statements, but you can use only one statement for one job.
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).
Main Device Scheduling
Because JES2 does not provide an equivalent function to Main Device Scheduling (MDS), you must prepare before any migration to JES2 to eliminate its use in JES3. If you do use MDS, it is likely that it is only used for tape.
If you use tape virtualization, it is reasonable to assume that you have more virtual tape drives than you 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.
Job throughput problems can be addressed by using the following methods:
•Remove “Tape and Disk setup” high water mark thresholds:
 – Use WLM and job schedulers to manage this job throughput instead.
 – Under the STANDARDS section in the JES3 initialization deck, replace SETUP=THWS with SETUP=NONE. This configuration helps make the JES3 more JES neutral.
•Convert from JES3-managed volumes to SMS-managed volumes.
 
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.
 
Information: Checking for resources for jobs in advance is not a problem. You should consider only that you might see longer elapsed times for your jobs based on the availability of the resources that the jobs need. You might also see more ENQ contention because of jobs that are waiting for resources to become available.
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).
Example 6-19 Diskreader enablement
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.
How the diskreader support is working is shown in Example 6-20.
Example 6-20 Submitting a job with diskreader
$SUBMIT,M=IEBGENER,HOLD=NO,DD=SLIBDD
$HASP000 OK
$HASP100 LUTZIEB ON INTRDR LUTZ FROM $SUBMIT
IEBGENER
IRR010I USERID LUTZ IS ASSIGNED TO THIS JOB.
ICH70001I LUTZ LAST ACCESS AT 11:24:39 ON TUESDAY, JUNE 11, 2019
$HASP373 LUTZIEB STARTED - INIT 1 - CLASS D - SYS SC74
Jobname Procstep Stepname CPU Time EXCPs RC
LUTZIEB --None-- COPY 00:00:00 44 00
$HASP395 LUTZIEB ENDED - RC=0000
 
The restrictions for JES3 options that are listed in Table 6-8 apply to the JES2 $SUBMIT command and are not supported.
Table 6-8 JES3 options that are not supported
Parameter
Description
IN=
Device group for output
B=
Batch job size (in terms of job)
H/HN
Control-card processor hold (can hold the submitted jobs)
J=
Name of jobs in the member of where to start processing
JOBS=
Number of jobs to process from the member
K/KN
Keep reader after hitting EOF
P=
Priority of the control-card processor
PARMID=
Set of C/I options
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.
An example DLOG that starts a JES3 printer is shown in Example 6-21.
Example 6-21 JES3 DLOG example
MLG 12340 1329067 S22 R= MP20NVC NVS22 Z000507 ! NVC-CMDIF: Z000507 S22->S22 *S A100 WC=1
A0050722 12340 1329067 +S A100 WC=1
A0050722 12340 1329067 IAT7089 WTR (JOB14567) ON A100 ( )
A0050722 12340 1329067 IAT7075 STARTED
MLG 12340 1329067 &IAT7001 JOB PVS8259P (JOB57960) IS ON WRITER A100( ),RECORDS=86,PAGES=18
The equivalent of starting a JES2 printer by using the OPERLOG function is shown in Example 6-22.
Example 6-22 OPERLOG example
NC0000000 S28 18166 15:58:35.72 Z000426 00000210 $SPRT131
NR0000000 S28 18166 15:58:35.73 Z000426 00000010 $HASP000 OK
NC0000000 S28 18166 15:58:35.73 INTERNAL 00000210 START PSFGRP6I.PSFGRP6I,,,( ),SUB=JES2
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.
First, enable OPERLOG in your system according to the HARDCOPY option in your CONSOLxx member. Then, you can disable JES3 OPERLOG by using the following command:
*F O DLOG=OFF
6.7 Transforming JCL and JECL
Transforming the JCL and JECL in your installation is a large task. Although it is not a complex process, many stakeholders are involved because of the sensitive nature of the process.
 
Information: The intention of migrating our jobs was to align the JCL and JECL in a way that works with both JES versions.
We separated the transformation task into the following subtasks:
•For the production JCL that is controlled by a professional BATCH scheduling system, we aligned JES3 JCL to a common form that is usable with both JES versions in front of the migration.
•We provided support for users to convert their own private libraries to a JES2-conforming version.
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.
Table 6-9 Possible JES2 support options
Support
Description
Obsolete
A warning diagnostic is written, but is otherwise ignored.
Not supported
An error message is generated and the job is given a JCL ERROR.
Supported
Full support is provided under JES2.
The most current support of JES3 JECL cards in your JCL is listed in Table 6-10.
Table 6-10 JES3 JECL support
JES3 JECL
Sub option
Support
Comment
//*DATASET
 
Not supported
Is tolerated but ignored
//*ENDDATASET
 
Not supported
Required if //*DATASET is present
//*ENDPROCESS
 
Not supported
 
//*FORMAT
DDNAME CARRIAGE/FCB CHARS
COMPACT COPIES
DEST
EXTWTR
FLASH
FORMS
MODIFY
PRTY
STACKER
TRAIN
Supported
Each //*FORMAT statement results in a // OUTPUT statement, which is forced to be after the JOB statement and before the first EXEC statement.
 
The name that is given the OUTPUT statements uses the form JES2nnnn, where nnnn begins at 0000.
 
 
CHNSIZE
INT
OVFL
THRESHLD
Not supported
 
//*MAIN
ACMAIN IORATE LREGION
MSS
RINGCHK TRKGRPS
TYPE
Obsolete
 
 
BYTES
CARDS
CLASS
HOLD
JOURNAL
LINES
ORG
PAGES
PROC
SYSTEM
USER
Supported
 
 
DEADLINE EXPDTCHK FAILURE
FETCH
SETUP
SPART
THWSSEP UPDATE
Not supported
DEADLINE is replaced by JES2 SCHEDULE statement.
//*NET
ID/NETID ABCMP/AC
ABNORMAL
NORMAL
NETREL/NR
NHOLD/HC
NRCMP/PC
OPHOLD/OH
RELEASE/RL
Supported
Converted internally to a JES2 JOBGROUP.
 
DEVPOOL, DEVRELSE
RELSCHCT/RS
Obsolete
 
//*NETACCT
 
Supported
All keywords that are supported in the same way as JES3 supports them.
//*OPERATOR
 
Supported
Message text ends in 71, not 80.
//*PAUSE
 
Not supported
Is ignored if present.
//*PROCESS
 
Not supported
 
//*ROUTE
XEQ
Supported
No support for an alternative JES2 /*ROUTE XEQ.
//*SIGNON
 
Not supported
 
//*SIGNOFF
 
Not supported
 
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.
What happens if jobs are not changed?
All JES3 JECL cards that begin with //* are processed by JES2. Therefore, these jobs will not fail at any time, which results in JES3 JECL (which is not yet supported by IBM) being ignored and treated as a comment.
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.
Keywords exist for each JECL card type. Each keyword includes the valid options that are listed in Table 6-11.
Table 6-11 JES3 JECL process options
Option
Description
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.
6.8 Migrating system automation
Strong monitoring is available for JES3. This monitoring addresses the need to quickly detect dangerous situations during the JES’s lifetime.
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.
6.8.1 New JES2 messages
To achieve the same stability that you likely had under JES3, you might need to add JES2 messages to your system automation. The messages that are listed in Table 6-12 on page 154 are intended to ensure that JES2 is starting without any operator response. These messages are only a recommendation and can vary in your installation.
 
Attention: This process is ongoing and must be reviewed frequently. It has no claim to completeness.
Table 6-12 JES2 automated startup
Message
Description
Reply
HASP405
JES2 IS UNABLE TO DETERMINE IF OTHER MEMBERS ARE ACTIVE
Y
HASP417
ARE THE VALUES JES2 WILL USE CORRECT?
Y
HASP420
REPLY ‘ Y’ IF memname IS ALL MEMBERS ARE DOWN (IPL REQUIRED), ‘N’IF NOT
Y
HASP426
SPECIFY OPTIONS – JES2 jeslevel SSNAME= ssname
Y
HASP434
INVALID CHECKPOINT RECORD ON CKPTn DATA SET
This message ends up in the JES2 Checkpoint reconfiguration dialog.
Y
HASP454
SHOULD JES2 BYPASS THE MULTI-MEMBER INTEGRITY LOCK? (‘Y’ OR ‘ N’)
Y
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.
Table 6-13 JES2 messages to monitor
Message
Description
$HASP050
JES2 RESOURCE SHORTAGE OF resource-type nnn %UTILIZATION REACHED
$HASP065
AWAITING RESPONSE TO HASPxxx MESSAGE, AUTO-REPLY N sec SECONDS
$HASP080
JES2 SYSTEM DUMP REQUESTED FROM mod (adr) + X'oooooo'
$HASP094
I/O ERROR ON SPOOL, MTTR=nnnnnnnn
$HASP095
JES2 CATASTROPHIC ERROR CODE=cde (RC= rsnc)
JES2 CATASTROPHIC ABEND CODE=cde (RC= rsnc)
$HASP110
jobname illegal JOB card reason
jobname Invalid JOB statement reason
jobname Illegal //*MAIN card reason
$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
$HASP198
REPLY TO HASP098 WITH ONE OF THE FOLLOWING:
Message that appears during abnormal end of JES2
$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
$HASP310
Job name TERMINATED AT END OF MEMORY
$HASP355
SPOOL VOLUMES ARE FULL
$HASP375
Job name ESTIMATED metrics EXCEEDED job name ESTIMATE EXCEEDED BY nnn metrics xxx% SPOOL
$HASP490
HOT START DENIED - RE-IPL REQUIRED
$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.
$HASP500
CONNECTION CONTROL RECEIVE ON lna text
$HASP531
Job name: Devname INVALID DATA BLOCK DETECTED TRANSMITTER devname ON NODE nodename
$HASP543
Jobname: Devname DELETED
$HASP565
General message that indicates that no NJE connection was established to the partner node
$HASP9156
ADDRESS SPACES WAITING FOR SPOOL SPACE
$HASP9162
PCES WAITING FOR SPOOL SPACE
$HASP9201
JES2 MAIN TASK WAIT DETECTED AT module+offset DURATION-hh:mm:ss.xx PCE pcename EXIT exit JOB ID jobid COMMAND jes2_command
$HASP9207
This message can indicate that an alert or an incident JES2 is tracking.
6.8.2 CKPT reconfiguration
In JES2 MAS, all participating systems need access to the checkpoint. This checkpoint is a sensitive resource and it is available twice for security reasons. Each checkpoint includes a backup that is defined to JES2, as shown in Example 6-23.
Example 6-23 Sample checkpoint configuration
$DCKPTDEF
$HASP829 CKPTDEF
$HASP829 CKPTDEF CKPT1=(STRNAME=JES2CKPT_1,INUSE=YES,VOLATILE=YES),
$HASP829 CKPT2=(DSNAME=JES2#A.RZ4.P0.CKPT2,VOLSER=SYA410,
$HASP829 INUSE=YES,VOLATILE=NO),
 
$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=(ONECKPT=IGNORE,ALLCKPT=WTOR),OPVERIFY=NO
If an issue exists in accessing one of the primary checkpoints, the first or second JES2 automatically forwards this checkpoint to the defined backup checkpoint, as listed in Table 6-14.
Table 6-14 Sample checkpoint definitions
Checkpoint
Primary
Backup
One
JES2CKPT_1
JES2#A.RZ4.P0.CKPT1NEW
Two
JES2#A.RZ4.P0.CKPT2
JES2#A.RZ4.P0.CKPT2NEW
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.
Table 6-15 Checkpoint Actions
Message
Checkpoint
Action
HASP280
CF backup is active
Add the previous primary as backup to the system $TCKPTDEF,NEWCKPT1=(STRNAME=JES2CKPT_1)
HASP280
CF primary is active
Add the backup checkpoint to the system
$TCKPTDEF,NEWCKPT1=(STRNAME=JES2CKPT_1_NEW)
6.8.3 Replacement for JES3 unique functions
One of the differences between JES3 and JES2 is the ability to define more options to sysout classes, such as DESTINATION, as shown in Example 6-24.
Example 6-24 Sample JES3 output class definitions
SYSOUT,CLASS=O,OVFL=OFF,HOLD=EXTWTR,DEST=LOCAL
SYSOUT,CLASS=P,OVFL=OFF,DEST=RZ2
SYSOUT,CLASS=Q,DEST=RZ2
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.
Table 6-16 Sample JES2 commands
JES2 command
Description
$TO JOBQ,/Q=0,/D=LOCAL,D=<Target>
Transfers all output elements in sysout class 0 and destination local to the Target sysplex.
$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.
By using this solution, you can transfer entire job classes to another system. If you must transfer output elements to another system but must keep the old destination, you cannot use JES2 system commands. The use of these commands results in loosing such information. An example in which a simple REXX program is used is shown in Example 6-25.
Example 6-25 REXX for transferring output
/*REXX================================================================*/
/* Purpose: Transfer all Output elements located in Sysout class 2 */
/* to sysplex PLEXQ and keep to old destination (the old */
/* printer name). */
/* */
/* History: 14.06.18 LK Initial for ITSO Redbooks           */
/* */
/*====================================================================*/
rc = ISFCalls('ON')
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.
Table 6-17 DEST comparison
Output element at origin
In PLEXQ with $TOJOBQ command
In PLEXQ with the REXX program
DEST=B433
DEST=LOCAL
DEST=B433
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.
6.9 Migrating security
Complete the following steps to migrate your security definitions to a JES2 version:
1. Convert existing JES3 prefixed profiles in RACF to a JES2 prefixed profile. The following RACF classes are affected:
 – Class NODES and WRITER for NJE and RJE definitions
 – JESINPUT for offloading
 – JESSPOOL for controlling job permissions
2. Add RACF profiles for all JES2 commands.
3. Add RACF profiles for all SDSF/EJES JES2 profiles.
4. Add new RACF profiles for any printer you might use.
6.9.1 JES3 prefixed profiles
For all JES3-related RACF profiles, define a JES2 prefixed equivalent in your RACF database. Almost all RACF profiles that are used for JES3 are the same under JES2. For more information about exceptions, see E.1.1, “RACF profiles used by exits” on page 235.
6.9.2 New JES2 command profiles
The main part of migrating to JES2 are the profiles for all JES2 commands. All of these profiles should have their appropriate RACF profile defined.
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).
Table 6-18 Profiles in RACF database
Command
Command option
RACF profile
Access level
$A
 
jesx.MODIFYREALEASE.*
UPDATE
 
$A A
jesx.MODIFYRELEASE.JOB
UPDATE
 
$A J
jesx.MODIFYRELEASE.BAT
UPDATE
 
$A JOBQ
jesx.MODIFYRELEASE.JST
UPDATE
 
$A S
jesx.MODIFYRELEASE.STC
UPDATE
 
$A T
jesx.MODIFYRELEASE.TSU
UPDATE
$ACTIVATE
 
jesx.ACTIVATE.FUNCTION
CONTROL
 
$ACTIVATE
jesx.ACTIVATE.FUNCTION
CONTROL
$ADD
 
jesx.ADD.*
CONTROL
 
$ADD APPL
jesx.ADD.APPL
CONTROL
 
$ADD CONNECT
jesx.ADD.CONNECT
CONTROL
 
$ADD DESTID
jesx.ADD.DESTID
CONTROL
 
$ADD FSS
jesx.ADD.FSS
CONTROL
 
$ADD LINE
jesx.ADD.LINE
CONTROL
 
$ADD LOADMOD
jesx.ADD.LOADMOD
CONTROL
 
$ADD LOGON
jesx.ADD.LOGON
CONTROL
 
$ADD NETSRV
jesx.ADD.NETSRV
CONTROL
 
$ADD PROCLIB
jesx.ADD.PROCLIB
CONTROL
 
$ADD PRTnnnn
jesx.ADD.DEV
UPDATE
 
$ADD REDIRECT
jesx.ADD.REDIRECT
CONTROL
 
$ADD RMT
jesx.ADD.RMT
CONTROL
 
$ADD SOCKET
jesx.ADD.SOCKET
CONTROL
 
$ADD SUBMITLIB
jesx.ADD.SUBMITLIB
CONTROL
 
$ADD SRVCLASS
jesx.ADD.SRVCLASS
CONTROL
$B
device
jesx.BACKSP.DEV
UPDATE
$C A**
 
jesx.CANCEL.AUTOCMD
CONTROL
$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 JOBQ
jesx.CANCEL.JSTOUT
UPDATE
 
$C O S
jesx.CANCEL.STCOUT
UPDATE
 
$C O T
jesx.CANCEL.TSUOUT
UPDATE
$C device
 
jesx.CANCEL.DEV
UPDATE
 
$C Lx.yy
jesx.CANCEL.DEV
UPDATE
 
$C device
jesx.CANCEL.DEV
UPDATE
 
$C OFFn.JR
jesx.CANCEL.DEV
UPDATE
 
$C OFFn.JT
jesx.CANCEL.DEV
UPDATE
 
$C OFFn.SR
jesx.CANCEL.DEV
UPDATE
 
$C OFFn.ST
jesx.CANCEL.DEV
UPDATE
$D *
 
jesx.DISPLAY.*
READ
 
$D A
jesx.DISPLAY.JOB
READ
 
$D ACTIVATE
jesx.DISPLAY.ACTIVATE
READ
 
$D ACTRMT
jesx.DISPLAY.ACTRMT
READ
 
$D APPL
jesx.DISPLAY.APPL
READ
 
$D CKPTDEF
jesx.DISPLAY CKPTDEF
READ
 
$D CONDEF
jesx.DISPLAY.CONDEF
READ
 
$D CONNECT
jesx.DISPLAY.CONNECT
READ
 
$D DESTDEF
jesx.DISPLAY.DESTDEF
READ
 
$D DEStid
jesx.DISPLAY.DESTID
READ
 
$D F
jesx.DISPLAY.QUE
READ
 
$D I
jesx.DISPLAY.INITIATOR
READ
 
$D INITINFO
jesx.DISPLAY.INITINFO
READ
 
$D JES2
jesx.DISPLAY.SYS
READ
 
$D J
jesx.DISPLAY.BAT
READ
 
$D JOBQ
jesx.DISPLAY.JST
READ
 
$D JOBCLASS
jesx.DISPLAY.JOBCLASS
READ
 
$D L(nnnn).JR(n)
jesx.DISPLAY.L
READ
 
$D L(nnnn).JT(n)
jesx.DISPLAY.L
READ
 
$D L(nnnn).SR(n)
jesx.DISPLAY.L
READ
 
$D L(nnnn).ST(n)
jesx.DISPLAY.L
READ
 
$D LINE
jesx.DISPLAY.LINE
READ
 
$D LOADmod
jesx.DISPLAY.LOADMOD
READ
 
$D MASDEF
jesx.DISPLAY.MASDEF
READ
 
$D MEMBer
jesx.DISPLAY.SYS
READ
 
$D MODULE
jesx.DISPLAY.MODULE
READ
 
$D N
jesx.DISPLAY.JOB
READ
 
$D NETSRV
jesx.DISPLAY.NETSRV
READ
 
$D NJEDEF
jesx.DISPLAY.NJEDEF
READ
 
$D NODE
jesx.DISPLAY.NODE
READ
 
$D O J
jesx.DISPLAY.BATOUT
READ
 
$D O JOBQ
jesx.DISPLAY.JSTOUT
READ
 
$D O S
jesx.DISPLAY.STCOUT
READ
 
$D O T
jesx.DISPLAY.TSUOUT
READ
 
$D OPTSDEF
jesx.DISPLAY.OPTSDEF
READ
 
$D PATH
jesx.DISPLAY.PATH
READ
 
$D PCE
jesx.DISPLAY.PCE
READ
 
$D PRT
jesx.DISPLAY.DEV
READ
 
$D PRTnnnn
jesx.DISPLAY.DEV
READ
 
$D PUNnn
jesx.DISPLAY.DEV
READ
 
$D Q
jesx.DISPLAY.JOB
READ
 
$D REBLD
jesx.DISPLAY.REBLD
READ
 
$D RDI
jesx.DISPLAY.RDI
READ
 
$D RDRnn
jesx.DISPLAY.DEV
READ
 
$D Rnnnnn.CON
jesx.DISPLAY.DEV
READ
 
$D Rnnnnn.PRm
jesx.DISPLAY.DEV
READ
 
$D Rnnnnn.PUm
jesx.DISPLAY.DEV
READ
 
$D Rnnnnn.RDm
jesx.DISPLAY.DEV
READ
 
$D REDIRect
jesx.DISPLAY.REDIRECT
READ
 
$D S
jesx.DISPLAY.STC
READ
 
$D SOCKET
jesx.DISPLAY.SOCKET
READ
 
$D SPOOL
jesx.DISPLAY.SPOOL
READ
 
$D SPOOLDEF
jesx.DISPLAY.SPOOLDEF
READ
 
$D SUBMITLIB
jesx.DISPLAY.SUBMITLIB
READ
 
$D SUBMITRDR
jesx.DISPLAY.SUBMITRDR
READ
 
$D SRVCLASS
jesx.DISPLAY.SRVCLASS
READ
 
$D SSI
jesx.DISPLAY.SSI
READ
 
$D SUBNET
jesx.DISPLAY.SUBNET
READ
 
$D T
jesx.DISPLAY.TSU
READ
 
$D TRACE(x)
jesx.DISPLAY.TRACE
READ
 
$D U
jesx.DISPLAY.DEV
READ
 
$D init stmt
jesx.DISPLAY.initstmt
READ
 
$L J
jesx.DISPLAY.BATOUT
READ
 
$L JOBQ
jesx.DISPLAY.JSTOUT
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
$DEL
 
jesx.DEL.*
CONTROL
 
$DEL CONNECT
jesx.DEL.CONNECT
CONTROL
 
$DEL DESTID
jesx.DEL.DESTID
CONTROL
 
$DEL LOADMOD
jesx.DEL.LOADMOD
CONTROL
 
$DEL PROCLIB
jesx.DEL.PROCLIB
CONTROL
 
$DEL SUBMITLIB
jesx.DEL.SUBMITLIB
CONTROL
$E CKPTLOCK
$E CKPTLOCK
jesx.RESTART.SYS
CONTROL
$E J
$E J
jesx.RESTART.BAT
CONTROL
$E JOBQ
 
jesx.RESTART.JST
CONTROL
 
$E JOBQ
jesx.RESTART.JST
CONTROL
 
$E LINE(x)
jesx.RESTART.LINE
CONTROL
 
$E LOGON(x)
jesx.RESTART.LOGON
CONTROL
 
$E MEMBER()
jesx.RESTART.SYS
CONTROL
 
$E NETSRV
jesx.RESTART.NETSRV
CONTROL
 
$E OFFn.JT
jesx.RESTART.DEV
UPDATE
 
$E OFFn.ST
jesx.RESTART.DEV
UPDATE
 
$E device
jesx.RESTART.DEV
UPDATE
$F device
 
jesx.FORWARD.DEV
UPDATE
 
$F device
jesx.FORWARD.DEV
UPDATE
$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
 
$G R (for execution)
jesx.GROUTE.JOBOUT
UPDATE
$H
 
jesx.MODIFYHOLD.*
UPDATE
 
$H A
jesx.MODIFYHOLD.JOB
UPDATE
 
$H J
jesx.MODIFYHOLD.BAT
UPDATE
 
$H JOBQ
jesx.MODIFYHOLD.JST
UPDATE
 
$H S
jesx.MODIFYHOLD.STC
UPDATE
 
$H T
jesx.MODIFYHOLD.TSU
UPDATE
$I device
 
jesx.INTERRUPT.DEV
UPDATE
 
$I device
jesx.INTERRUPT.DEV
UPDATE
$J*
 
jesxMON.*
CONTROL
 
$JD DETAILS
jesxMON.DISPLAY.DETAIL
READ
 
$JD HISTORY
jesxMON.DISPLAY.HISTORY
READ
 
$JD JES
jesxMON.DISPLAY.JES
READ
 
$JD MONITOR
jesxMON.DISPLAY.MONITOR
READ
 
$JD STATUS
jesxMON.DISPLAY.STATUS
READ
 
$J STOP
jesxMON.STOP.MONITOR
CONTROL
$M
 
jesx.MSEND.CMD
READ
 
$M
jesx.MSEND.CMD
READ
$M SPL
 
jesx.MIGRATE.FUNCTION
CONTROL
 
$M SPL
jesx.MIGRATE.FUNCTION
CONTROL
$N
 
jesx.NSEND.CMD
READ
 
$N
jesx.NSEND.CMD
READ
$N device
 
jesx.REPEAT.DEV
UPDATE
 
$N device
jesx.REPEAT.DEV
UPDATE
$O *
 
jesx.RELEASE.BATOUT
UPDATE
 
$O J
jesx.RELEASE.BATOUT
UPDATE
 
$O JOBQ
jesx.RELEASE.JSTOUT
UPDATE
 
$O S
jesx.RELEASE.STCOUT
UPDATE
 
$O T
jesx.RELEASE.TSUOUT
UPDATE
$P *
 
jesx.STOP.* but not jesx.STOP.JST*/BAT*/STC*/TSU*
CONTROL
 
$P
jesx.STOP.SYS
CONTROL
 
$P I
jesx.STOP.INITIATOR
CONTROL
 
$P JES2
jesx.STOP.SYS
CONTROL
 
$P LINE(x)
jesx.STOP.LINE
CONTROL
 
$P LOGON(x)
jesx.STOP.LOGON
CONTROL
 
$P NETSRV
jesx.STOP.NETSRV
CONTROL
 
$P OFFn.JR
jesx.STOP.DEV
UPDATE
 
$P OFFn.JT
jesx.STOP.DEV
UPDATE
 
$P OFFn.SR
jesx.STOP.DEV
UPDATE
 
$P OFFn.ST
jesx.STOP.DEV
UPDATE
 
$P OFFLOADn
jesx.STOP.DEV
UPDATE
 
$P RMT(x)
jesx.STOP.RMT
CONTROL
 
$P SPOOL
jesx.STOP.SPOOL
CONTROL
 
$P SRVCLASS
jesx.STOP.SRVCLASS
CONTROL
 
$P TRACE(x)
jesx.STOP.TRACE
CONTROL
 
$P XEQ
jesx.STOP.SYS
CONTROL
 
$P device
jesx.STOP.DEV
UPDATE
$P J/B/T + O
 
jesx.STOP.JST*/BAT*/STC*/TSU*
 
 
$P JOBQ
jesx.STOP.JST
UPDATE
 
$P JOB
jesx.STOP.BAT
UPDATE
 
$P STC
jesx.STOP.STC
UPDATE
 
$P TSU
jesx.STOP.TSU
UPDATE
 
$PO JOBQ
jesx.STOP.JSTOUT
UPDATE
 
$PO JOB
jesx.STOP.BATOUT
UPDATE
 
$PO STC
jesx.STOP.STCOUT
UPDATE
 
$PO TSU
jesx.STOP.TSUOUT
UPDATE
$POLICY
$POLICY IMPORT
jesx.POLICY.DELETE
UPDATE
 
$POLICY DISABLE
jesx.POLICY.DISABLE
UPDATE
 
$POLICY DISPLAY
jesx.POLICY.DISPLAY
UPDATE
 
$POLICY ENABLE
jesx.POLICY.ENABLE
UPDATE
 
$POLICY IMPORT
jesx.POLICY.IMPORT
UPDATE
$R *
 
jesx.ROUTE.JOBOUT
UPDATE
 
$R ALL
jesx.ROUTE.JOBOUT
UPDATE
 
$R PRT
jesx.ROUTE.JOBOUT
UPDATE
 
$R PUN
jesx.ROUTE.JOBOUT
UPDATE
 
$R XEQ
jesx.ROUTE.JOBOUT
UPDATE
$S *
 
jesx.START.* but not jesx.START.BAT
CONTROL
 
$S
jesx.START.SYS
CONTROL
 
$S A
jesx.START.AUTOCMD
CONTROL
 
$S I
jesx.START.INITIATOR
CONTROL
 
$S LINE(x)
jesx.START.LINE
CONTROL
 
$S LOGON(x)
jesx.START.LOGON
CONTROL
 
$S N
jesx.START.NET
CONTROL
 
$S NETSRV(nnn)
jesx.MODIFY.NETSRV
CONTROL
 
$S OFFn.JR
jesx.START.DEV
UPDATE
 
$S OFFn.JT
jesx.START.DEV
UPDATE
 
$S OFFn.SR
jesx.START.DEV
UPDATE
 
$S OFFn.ST
jesx.START.DEV
UPDATE
 
$S OFFLOADn
jesx.START.DEV
UPDATE
 
$S device
jesx.START.DEV
UPDATE
 
$S RMT(x)
jesx.START.RMT
CONTROL
 
$S SPOOL
jesx.START.SPOOL
CONTROL
 
$S SRVCLASS
jesx.START.SRVCLASS
CONTROL
 
$S TRACE(x)
jesx.START.TRACE
CONTROL
 
$S XEQ
jesx.START.SYS
CONTROL
$S J
$S J
jesx.START.BAT
UPDATE
 
$SUBMIT
jesx.SUBMIT.JOB
CONTROL
$T *
 
jesx.MODIFY.* but not jesx.MODIFY.JST*/BAT*/STC*/TSU*
CONTROL
 
$T A(CREATE)
jesx.MODIFY.AUTOCMD
READ
 
$T A(OWNER)
jesx.MODIFY.AUTOCMD
READ
 
$T A(NOT OWNER)
jesx.MODIFY.AUTOCMD
CONTROL
 
$T APPL
jesx.MODIFY.APPL
CONTROL
 
$T BUFDEF
jesx.MODIFY.BUFDEF
CONTROL
 
$T CKPTDEF
jesx.MODIFY.CKPTDEF
CONTROL
 
$T CONDEF
jesx.MODIFY.CONDEF
CONTROL
 
$T CONNECT
jesx.MODIFY.CONNECT
CONTROL
 
$T DEBUG
jesx.MODIFY.DEBUG
CONTROL
 
$T DESTDEF
jesx.MODIFY.DESTDEF
CONTROL
 
$T DEStid
jesx.MODIFY.DESTID
CONTROL
 
$T ESTBYTE
jesx.MODIFY.ESTBYTE
CONTROL
 
$T ESTIME
jesx.MODIFY.ESTIME
CONTROL
 
$T ESTLNCT
jesx.MODIFY.ESTLNCT
CONTROL
 
$T ESTPAGE
jesx.MODIFY.ESTPAGE
CONTROL
 
$T ESTPUN
jesx.MODIFY.ESTPUN
CONTROL
 
$T EXIT
jesx.MODIFY.EXIT
CONTROL
 
$T FSS
jesx.MODIFY.FSS
CONTROL
 
$T I
jesx.MODIFY.INITIATOR
CONTROL
 
$T INTRDR
jesx.MODIFY.INTRDR
CONTROL
 
$T JOBCLASS
jesx.MODIFY.JOBCLASS
CONTROL
 
$T JOBDEF
jesx.MODIFY.JOBDEF
CONTROL
 
$T JOBPRTY
jesx.MODIFY.JOBPRTY
CONTROL
 
$T LINE
jesx.MODIFY.LINE
CONTROL
 
$T LOADMOD
jesx.MODIFY.LOADMOD
CONTROL
 
$T LOGON
jesx.MODIFY.LOGON
CONTROL
 
$T MASDEF
jesx.MODIFY.MASDEF
CONTROL
 
$T MEMBER(x)
jesx.MODIFY.SYS
CONTROL
 
$T NETSRV
jesx.MODIFY.NETSRV
CONTROL
 
$T NJEDEF
jesx.MODIFY.NJEDEF
CONTROL
 
$T NODE
jesx.MODIFY.NODE
CONTROL
 
$T NUM
jesx.MODIFY.NUM
CONTROL
 
$T OFFLOADx
jesx.MODIFY.OFFLOAD
CONTROL
 
$T OUTCLASS
jesx.MODIFY.OUTCLASS
CONTROL
 
$T OUTDEF
jesx.MODIFY.OUTDEF
CONTROL
 
$T OUTPRTY
jesx.MODIFY.OUTPRTY
CONTROL
 
$T PCE
jesx.MODIFY.PCE
CONTROL
 
$T PRINTDEF
jesx.MODIFY.PRINTDEF
CONTROL
 
$T device
jesx.MODIFY.DEV
UPDATE
 
$T RECVopts
jesx.MODIFY.RECVOPTS
CONTROL
 
$T REDIRect
jesx.MODIFY.REDIRECT
CONTROL
 
$T RMT
jesx.MODIFY.RMT
CONTROL
 
$T SMFDEF
jesx.MODIFY.SMFDEF
CONTROL
 
$T SOCKET
jesx.MODIFY.SOCKET
CONTROL
 
$T SPOOL
jesx.MODIFY.SPOOL
CONTROL
 
$T SPOOLDEF
jesx.MODIFY.SPOOLDEF
CONTROL
 
$T SRVCLASS
jesx.MODIFY.SRVCLASS
CONTROL
 
$T SSI
jesx.MODIFY.SSI
CONTROL
 
$T STCCLASS
jesx.MODIFY.STCCLASS
CONTROL
 
$T SUBMITLIB
jesx.MODIFY.SUBMITLIB
CONTROL
 
$T SUBMITRDR
jesx.MODIFY.SUBMITRDR
CONTROL
 
$T TPDEF
jesx.MODIFY.TPDEF
CONTROL
 
$T TRACEDEF
jesx.MODIFY.TRACEDEF
CONTROL
 
$T init stmt
jesx.MODIFY.init stmt
CONTROL
 
$T TSUCLASS
jesx.MODIFY.TSUCLASS
CONTROL
$T J/B/T + O
 
jesx.MODIFY.JST*/BAT*/STC*/TSU*
 
 
$T J
jesx.MODIFY.BAT
UPDATE
 
$T JOBQ
jesx.MODIFY.JST
UPDATE
 
$T S
jesx.MODIFY.STC
UPDATE
 
$T T
jesx.MODIFY.TSU
UPDATE
 
$T O J
jesx.MODIFY.BATOUT
UPDATE
 
$T O JOBQ
jesx.MODIFY.JSTOUT
UPDATE
 
$T O S
jesx.MODIFY.STCOUT
UPDATE
 
$T O T
jesx.MODIFY.TSUOUT
UPDATE
$VS*
 
jesx.VS
CONTROL
 
$VS*
jesx.VS
CONTROL
$Z *
 
jesx.HALT.*
CONTROL
 
$Z A
jesx.HALT.AUTOCMD
CONTROL
 
$Z I
jesx.HALT.INITIATOR
CONTROL
 
 
 
 
 
$Z OFFLOADn
jesx.HALT.DEV
UPDATE
 
$Z SPOOL
jesx.HALT.SPOOL
CONTROL
 
$Z device
jesx.HALT.DEV
UPDATE
$ZAPJOB
 
jesx.ZAP.JOB
CONTROL
 
$ZAPJOB
jesx.ZAP.JOB
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.
6.9.3 SDSF and EJES considerations
The migration of SDSF and EJES security profiles is a simple process. You must add all RACF profiles of commands or panels that do not exist under JES3.
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.
6.10 Migrating your printer
All printers that are defined in JES3 that use PSF must be migrated to JES2. Under JES3, you assign any printer name that you want if it meets the JES3 criteria.
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.
Example 6-26 JES3 Printer definitions
DEVICE,MODE=FSS,DTYPE=PRTAFP1,PM=(LINE,PAGE),FSSNAME=PSFGRP4A,
JNAME=B433,HEADER=YES,BURST=YES,DGROUP=PSFGRP4A,
JUNIT=(,*ALL,UR,ON),
CHARS=(YES,SC12),PAGELIM=0+,CKPNTPG=3,DYNAMIC=YES,
WS=(D,P,CL,F,L,C,PM,U),WC=2,FORMS=(h)
**-----------------------------------------------------------------
DEVICE,MODE=FSS,DTYPE=PRTAFP1,PM=(LINE,PAGE),FSSNAME=PSFGRP4A,
JNAME=B439,HEADER=NO,BURST=NO,DGROUP=PSFGRP4A,
JUNIT=(,*ALL,UR,ON),
CHARS=(YES,SC12),PAGELIM=0+,CKPNTPG=3,DYNAMIC=YES,
WS=(D,P,CL,F,L,C,PM,U),WC=2,FORMS=( )
The JES2 equivalent definitions for the printer are shown in Example 6-27. The printer name changed, as listed in Table 6-19.
Table 6-19 Comparison of JES printer names
JES3 printer name
JES2 printer name
JES2 writer name
B433
PRT1433
B433
B439
PRT1439
B439
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.
Example 6-27 JES2 printer definitions
/*-------------------------------------------------------------------*/
/* PRINTERS FOR FSS GROUP PSFGRP4A */
/*-------------------------------------------------------------------*/
PRT(1433) FSS=PSFGRP4A,R=B433,WRITER=B433,B=Y,SEP=Y
PRT(1439) FSS=PSFGRP4A,R=B439,WRITER=B439
/*-------------------------------------------------------------------*/
PRT(*) CLASS=2, /* DEFAULT CLASS FOR PRINT CENTER */
START=NO, /* PRT1 COMES UP DRAINED */
PRMODE=(LINE,PAGE), /* PROCESS MODE */
MODE=FSS, /* WHETHER PRT IS STARTED UNDER */
WS=(Q,R/F,PRM,LIM,W,C,T,P), /* WORK SELECT. CRITERIA */
NPRO=90, /* PRINT TIMEOUT */
FORMS=(3820), /* DEFAULT FORM TO PROCESS */
SEPDS=NO, /* DEFAULT NO SEP PAGE */
SEP=NO, /* DEFAULT NO SEP PAGE */
BURST=NO /* DEFAULT NO BURST MODE */
/*-------------------------------------------------------------------*/
6.10.1 FSS address spaces
The corresponding printer definitions in your FSS PSF started tasks must be changed slightly. The only one change that must be done is to change your printer names according to the new JES2 printer name. The appropriate JES3 FSS definition from printer B433 is shown in Example 6-28.
Example 6-28 JES3 FSS printer definition
//B433 CNTL
//B433 PRINTDEV FONTDD=*.FONT28, /* FONT LIBRARY DD */
// OVLYDD=*.OLAY01, /* OVERLAY LIBRARY DD */
// PSEGDD=*.PSEG01, /* SEGMENT LIBRARY DD */
// PDEFDD=*.PDEF01, /* PAGEDEF LIBRARY DD */
// FDEFDD=*.FDEF01, /* FORMDEF LIBRARY DD */
// JOBHDR=*.JOBHDR, /* JOB HEADER SEPARATOR OUTPUT */
// JOBTRLR=*.JOBTLR, /* JOB TRAILER SEPARATOR OUTPUT */
// DSHDR=*.DSHDR, /* DATA SET HEADER SEPARATOR */
// MESSAGE=*.MSGDS, /* MESSAGE DATA SET OUTPUT */
// PAGEDEF=A4H08, /* DEVICE PAGEDEF DEFAULT */
// FORMDEF=EFA4, /* DEVICE FORMDEF DEFAULT */
// CHARS=SC12, /* @H1C*/
// PIMSG=YES, /* ACCUMULATE DATA SET MESSAGES */
// TRACE=NO, /* BUILD INTERNAL TRACE ENTRIES */
// FAILURE=WCONNECT, /* PSF ACTION ON PRINTER FAILURE*/
// CONNINTV=86400, /* jes connect interval time 1D */
// TIMEOUT=REDRIVE, /* PSF ACTION ON TIMEOUT */
// DISCINTV=0, /* DISCONNECT INTERVAL IN SECOND*/
// IPADDR='XXXXXXXXXX', /* IP-ADDR */
// PORTNO=4711 /* PORTNO */
//B433 ENDCNTL
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.
Example 6-29 JES2 FSS printer definition
//PRT1433 CNTL
//PRT1433 PRINTDEV FONTDD=*.FONT28, /* FONT LIBRARY DD */
// OVLYDD=*.OLAY01, /* OVERLAY LIBRARY DD */
// PSEGDD=*.PSEG01, /* SEGMENT LIBRARY DD */
// PDEFDD=*.PDEF01, /* PAGEDEF LIBRARY DD */
// FDEFDD=*.FDEF01, /* FORMDEF LIBRARY DD */
// JOBHDR=*.JOBHDR, /* JOB HEADER SEPARATOR OUTPUT */
// JOBTRLR=*.JOBTLR, /* JOB TRAILER SEPARATOR OUTPUT */
// DSHDR=*.DSHDR, /* DATA SET HEADER SEPARATOR */
// MESSAGE=*.MSGDS, /* MESSAGE DATA SET OUTPUT */
// PAGEDEF=A4H08, /* DEVICE PAGEDEF DEFAULT */
// FORMDEF=EFA4, /* DEVICE FORMDEF DEFAULT */
// CHARS=SC12, /* @H1C*/
// PIMSG=YES, /* ACCUMULATE DATA SET MESSAGES */
// TRACE=NO, /* BUILD INTERNAL TRACE ENTRIES */
// FAILURE=WCONNECT, /* PSF ACTION ON PRINTER FAILURE*/
// CONNINTV=86400, /* jes connect interval time 1D */
// TIMEOUT=REDRIVE, /* PSF ACTION ON TIMEOUT */
// DISCINTV=0, /* DISCONNECT INTERVAL IN SECOND*/
// IPADDR='XXXXXXXXXX', /* IP-ADDR */
// PORTNO=4711 /* PORTNO */
//PRT1433 ENDCNTL
 
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.
6.11 Performance experience
This section provides information about general performance comparisons between JES3 and JES2. We also provide recommendations for the JES2 system layout.
6.11.1 CPU use comparison
In preparation for a JES3 migration project, no detailed information is available about the expected CPU use of a JES2 MAS versus JES3 complex. Because the CPU consumption is a key factor on IBM Z, we provide more information based on z13® hardware for the customer project.
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.
Figure 6-15 JES2/JES3 CPU consumption
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.
During the migration, the CPU consumption is higher because of all of the migration tasks that must be completed. After the migration to JES2, you see a more balanced CPU consumption across the sysplex because JES2s are independent of each other and have no GLOBAL equivalent, as JES3 does. This result might vary in your environment because of different workloads.
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.
6.11.2 Dynamic checkpoint
Within JES2, a single resource that is named CHECKPOINT is available. This resource is used to share JES2-relevant information across all participating JES2 MAS members in the sysplex.
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.
 
Information: In the customer environment, we saw a huge reduction of SPOOL delays in JES2 related workload.
To activate the support, code the JES2 initialization parameter MASDEF CYCLEMGT=AUTO, as shown in Example 6-7 on page 124. If JES2 is running, you can also enable the function dynamically by using the JES2 command $TMASDEF,CYCLEMGT=AUTO.
6.12 Hints and tips
In this section, we summarize the issues that we experienced during the JES2 migration process. This experience can vary on your site and has no claim to completeness.
6.12.1 JCL errors
After replacing JES3 with JES2, we observed several JCL errors in production BATCH processing. The root cause was the different handling of the JCL DD DLM option. The customer’s production JCL included the jobs that are shown in Example 6-30.
Example 6-30 JCL DLM example
//SYSIN DD *,DLM=$$
first line
second line
//third line
$$
JES3 DLM handling
Under JES3, you can use the DLM option with DD * or DD DATA. In both cases, the SYSIN records are read until the characters that are defined in the DLM option appear.
JES2 DLM handling
JES2 handles DLM differently from JES3. If you code a DLM character in your JCL with DD *, the input stream is read until the DLM character or // appears. The differences between both JES versions when DD *,DLM JCL is used are listed in Table 6-20.
Table 6-20 Comparison of DLM usage
DLM statement
JES3
JES2
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=.
6.12.2 S722 abends in JCL
Some customer’s jobs were abending with S722, which means that the number of lines that is produced by these jobs exceeded a certain limit. A customer’s limit was set to 16 message I/O (MIO) lines, as shown in Example 6-8 on page 127. Even so, some customer jobs were abending after only one line was produced.
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.
Figure 6-16 Structure of JCL accounting field
In some customer jobs, the following similar job card was used:
//JOBA JOB (ITSO,SYSLAB,LUTZ,1),CLASS=M
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.
6.12.3 Lost printer names after transfer
In the customer environment, print output is collected from all sysplexes in one sysplex where the office printers are connected. For this purpose, we used the manual transfer that is controlled by the system automation because JES2 does not provide such functions. For more information, see 6.8, “Migrating system automation” on page 153.
6.12.4 Monitoring default job class A
After migrating to JES2, monitor your set default JES2 job class (the standard is A). Because many people make mistakes during the conversion process, their user JCL can include many incorrect or missing job classes (see Example 6-31). The job card for JOBA does not contain any job class definition. It is possible that the user removed the //*MAIN CLASS= statement without moving that information to the job card.
Example 6-31 Missing JES2 job class definitions
//JOBA JOB (ACCT,ITSO,LUTZ),MSGCLASS=X,TIME=1440
//EXEC DD PGM=IEFBR14
//
//JOBB JOB (ACCT,ITSO,LUTZ),MSGCLASS=X,TIME=1440
//*MAIN CLASS=M
//EXEC DD PGM=IEFBR14
//
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.
Example 6-32 Sample output $DQ,Q=XEQ
$DQ,Q=XEQ
$HASP647 11 CNV SYSA
$HASP647 400 XEQ A SYSA
$HASP647 7 XEQ M SYSA
$HASP647 5 XEQ M1 SYSA
$HASP647 1 XEQ P1 SYSA
$HASP647 1 XEQ P3 SYSA
$HASP647 5 XEQ S0 SYSA
$HASP647 5 XEQ S1 SYSA
$HASP647 1 XEQ S2 SYSA
As shown in Example 6-32, 400 jobs are waiting for running in JES2 default job class A because many of those jobs were misplaced because of incorrect job class information.
6.12.5 Monitor JES2 resources
JES2 uses many resources as listed in Table 6-21.
Table 6-21 JES2 resource list
Resource
Description
Set by
Scope
BERT
Block Extension reuse tables
BERTNUM on CKPTSPACE
SYS
BSCB
Bisynchronous buffers
BSCBUF on TPDEF
SYS
BUFX
Extended logical buffers
EXTBUF on BUFDEF
SYS
CKVR
Checkpoint versions
NUMBER on the CKPTDEF statement
SYS
CMBS
Console message buffers
BUFNUM on the CONDEF statement
SYS
CMDS
Console message buffers used for JES2 commands
CMDNUM on the CONDEF statement
SYS
ICES
IBM VTAM® sessions
SESSIONS on the TPDEF statement
SYS
LBUF
Logical buffers
BELOWBUF on the BUFDEF statement
SYS
JNUM
Job numbers
RANGE on the JOBDEF statement
MAS
JQES
Job queue elements
JOBNUM on the JOBDEF statement
MAS
JOES
Job output elements
JOENUM on the OUTDEF statement
MAS
NHBS
NJE header/trailer buffers
HDRBUF on the NJEDEF statement
SYS
SMFB
System management facility buffers
BUFNUM on the SMFDEF statement
SYS
TBUF
TCP/IP buffer data space
No external settings defined
SYS
TGS
SPOOL space/track groups
TGSPACE=(MAX=) on the SPOOLDEF statement
MAS
TTAB
Trace tables
TABLES on the TRACEDEF statement
SYS
VTMB
VTAM buffers
SNABUF on TPDEF
SYS
ZJC
Zone Job Container
ZJCNUM on GROUPDEF statement
MAS
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.
Example 6-33 $HASP050 example
$HASP050 JES2 RESOURCE SHORTAGE OF JOES – 80% UTILIZATION REACHED
This message is a warning that the threshold for that particular resource was reached. Investigate the root cause of that message and take one of the following actions to solve the situation to avoid future problems:
• Run the $OQ command to release held output.
•Purge unneeded output.
•Make unprocessed output eligible for selection by changing printer characteristics.
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
Figure 6-17 JES2 resource display
6.12.6 Modifying JES3 OUTSERV
During the final migration to JES2, we decided to move files from selected JES3 SPOOL classes to JES2. During the transfer, we faced an issue that some JCL outputs were split in two or more pieces on the JES2 system. Therefore, the outputs were no longer all in one output file.
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.
Example 6-34 Sample JES3 OUTSERV
OUTSERV,CARRIAGE=7827,FORMS=7817,WS=(D,T,F,P,C,U,FL,CM,SS,CL,L),
WC=(0,1,2,3,4,5,6,7,9,A,B,D,F,G,H,I,J,K,M,N,P,Q,S,T,U,V,W,X,Y,Z),
THRESHLD=25000,TRAIN=H11,FLASH=NONE,OUTSVFCT=5,SNAGROUP=YES,
CHARS=(SC12),STACKER=C,CB=N
6.12.7 NJE performance
Based on the decision to move selected JES3 output classes to JES2, we recommend defining the maximum number of parallel NJE sender and receiver channels to get the maximum performance and reduce migration time. The appropriate NJEDEF statement with the SRNUM and STNUM option set to 4 is shown in Example 6-8 on page 127. By using this configuration, you can transfer four SYSOUT data sets in parallel.
 
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.
Example 6-35 NJE modification
JES2 $TLINE(<your line number>),SRNUM=4,STNUM=4
JES3 *F,NJE,N=<your system name>,OR=4,OT=4
6.12.8 REXX SPIN
During the first business day, the customer saw a high use of JES2 job output elements (JOEs). The situation is brought to the customer’s attention when the following JES2 message appeared:
$HASP050 JES2 RESOURCE SHORTAGE OF JOES – 80% UTILIZATION REACHED
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.
Figure 6-18 JES2 output queue
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)
6.12.9 NJE parms for time differences
In the customer environment, we use a UAT sysplex that runs with a date in the future to verify new application programs. Therefore, we have a time difference between that sysplex and all of the other application programs that are running. To establish an NJE connection between systems with different times, use the NJEDEF TIMETOL=0 option during JES2 initialization.
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.
 
Attention: If you must use the PATHMGR=NO option, you must manually define all of your NJE network routes.
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.
Figure 6-19 JES2 NJE configuration
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
6.12.10 Print delays
For a customer’s high-performance print center within JES3, they can change their printer selection criteria while the printer was active and printing. This change prevents the printer from stopping. A printer that stops leads to another warm-up phase of the printer, which wastes approximately 50 blank pages. The print flow within JES3 is shown in Figure 6-20 on page 179.
Figure 6-20 JES3 Printing
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.
Figure 6-21 JES2 Printing
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).
6.12.11 APPC abends
After restarting the systems with JES2, all APPC/ASCH address space failed. The problem occurred because of a hardcoded sub system declaration in customers ASCHPM00 member, as shown in Figure 6-22.
Figure 6-22 ASCHPM00 member
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.
6.13 Ready to migrate
In this section, we describe how a JES3 migration can be done based on a customer experience. Our example is based on the following steps:
1. Prepare your sysplex.
2. Shut down JES3 Sysplex.
3. Restart Sysplex with JES2 MAS until TSO.
4. Prepare the NJE connection to JES2 MAS.
5. Start SPOOL migration.
6. Start JES2 tests and sample jobs.
7. Restart subsystems, such as Db2, IMS, and CICS.
8. Release your BATCH.
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.
6.13.1 Preparing your sysplex
First, create a saved copy of your IEFSSNxx member in your PARMLIB. This saved copy is used if you must go back to JES3.
Replace the primary subsystem JES3 with JES2 in your active IEFSSNxx member, as shown in Example 6-36 and Example 6-37.
Example 6-36 JES3 IEFSSNxx entry
SUBSYS SUBNAME(JES3)
PRIMARY(YES) START(NO)
Example 6-37 JES2 IEFSSNxx entry
SUBSYS SUBNAME(JES2)
PRIMARY(YES) START(NO)
 
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.
Stop BATCH processing
All BATCH jobs outside of system engineering should be stopped. This process can be done by stopping all jobs that are coming from your BATCH control system and preventing the start of jobs by JES3.
 
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.
6.13.2 Shutting down JES3 sysplex
Now you can begin shutting down JES3 sysplex (all at once or individually). For safety reasons, it is better to leave one system up with JES3. In the customer case study that is shown in Figure 6-23 on page 182, a separate JES3 system was added to the sysplex for the following reasons:
•Transfer of JES3 SPOOL files to JES2 (if needed)
•To have a backup system available if:
 – You must check how a process was working under JES3 for comparison with JES2
 – To access the system if JES2 does not work
Figure 6-23 Migration to JES2
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.
6.13.3 Restarting sysplex with JES2 MAS until TSO
Now you can IPL all of the systems in your sysplex. Because the amount of time that a member can hold the checkpoint for and the time it waits before trying to reacquire the checkpoint is controlled by the HOLD= and DORMANCY= parameters on the MASDEF statement, prepare your JES2 MAS ahead of the migration, as described in 6.3, “JES2 system design” on page 124. The IPLs should be done up to TSO. Then, you can begin testing your JES2 infrastructure.
Refreshing automation table
The new automation table must be activated by using the INGAMS REFRESH automation command. The new table contains all of the new JES2 messages that must be processed and the new set procedures, if needed. This process can be done before the first activation of JES2.
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.
Example 6-38 Stopping JES2 BATCH
$DJOBCLASS(<your job classes>),QAFF(ANY)=OFF
6.13.4 Preparing NJE connection to JES2 MAS
This step is optional for your migration. If you want to keep your JES3 SPOOL files and move them to JES2, you must establish an NJE connection between your new JES2 MAS and the remaining JES3 system.
Because the JES2 includes the same NJE node name as the JES3 before, you must change the node name for the JES3 system by completing the following steps:
1. Rename the JES3 home node definition that is shown in Example 6-39.
2. Add the JES2 partner node (the origin node name that JES2 now uses).
Example 6-39 Modified JES3 NJE configuration
NJERMT,NAME=SYS2,HOME=YES,MAXLINE=0,DEFCLASS=NO
NETSERV,NAME=NJENSRV,HOSTNAME=TCPSYS2
*-----------------------------------------------
NJERMT,NAME=SYS1,HOME=NO,TYPE=TCPIP
SOCKET,NAME=S1SYS1,NETSERV=NJENSRV,
HOSTNAME=NJE-SYS1,NODE=SYS1
 
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.
Example 6-40 Defining JES2 partner node
*F,NJE,ADD=SYS1,TYPE=TCPIP
*F,SOCKET,ADD=S1SYS1,HOSTNAME=TCPSYS1,NETSERV=NJENSRV,NODE=SYS1
Next, add the renamed node name to your JES2 MAS (see Example 6-41).
Example 6-41 JES NJE definitions
NODE(1) NAME=SYS1 /* OWNNODE=1 */
NETSRV1 SOCKET=SYS1
SOCKET(SYS1) NODE=1,IPADDR=YOUR-ADRESS
/*-------------------------------------------------------------------*/
NODE(2) NAME=SYS2
SOCKET(SYS2) NODE=2,IPADDR=ADRESS-SYS2,CONNECT=YES
Now you can establish the NJE connection between both systems by using the JES2 start command that is shown in Example 6-42.
Example 6-42 JES2 start connection to JES3
$SN,N=SYS2
$HASP000 OK
IAZ0543I NETSRV1 TCP/IP connection with IP Addr: TCPSYS2 Port: 175 Initiated
IAZ0543I NETSRV1 TCP/IP connection with IP Addr: TCPSYS2 Port: 175 Successful
The JES3 commands that are used for starting the JES2 node from the JES3 system are shown in Example 6-43.
Example 6-43 JES3 start connection to JES2
*S,TCP,SOCKET=S1SYS1
*S,TCP,NODE=S1SYS1
6.13.5 Starting SPOOL migration
First, identify the SPOOL content that must be transferred. This content depends on your company SPOOL sysout class definitions and can vary. To determine the amount of sysout you must transfer, you can use JES3 command that is shown in Example 6-44. This command shows you the number of SPOOL files in all HOLD and WTR sysout classes.
Example 6-44 Display JES3 sysout
*I U Q=HOLD,CL=?
IAT8131 CL=0, L=27586, PG=0, SR=27586, BY=2642348.
IAT8131 CL=L, L=1000000, PG=0, SR=1000000, BY=121360144.
IAT8131 CL=T, L=3464764, PG=0, SR=3464764, BY=305434192.
IAT8131 CL=Y, L=369, PG=0, SR=369, BY=36756.
IAT8119 NUMBER OF JOBS FOUND : 3579
 
*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.
Example 6-45 JES3 command for transfer
*F U Q=HOLD,CL=X,ND=<new Destination>,N=ALL
*F,U,Q=HOLD,CL=X,AGE>3,ND=<new Destination>,N=ALL
 
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.
6.13.6 JES2 test cases
After all your systems that are brought up with JES2, you can conduct basic system tests to verify that the system with JES2 is working as expected. Define your own test scenario that is based on your system environment by using the test case information that is listed in Table 6-22.
Table 6-22 Sample test cases after migration
Name
Description
Expected result
Check EDP
Jobs from EDP (end of Day Processing) might run
No JCL errors or abends caused by 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 for unauthorized users
Unauthorized users prevented from JES2 modify commands
UserID and Password Test
Allocate new DSN with no permission. Submit job without password from secondary UID
RACF error S913
Test OPERATOR Security
•Stop / Start JES2
•Restart Job
•Start / Stop BATCH Job,STC,TSU,JST
•Device Management
No security error
NJE Security
•Send print output to remote RZ
•Start job on remote RZ
No security error
Alarm Tests
Tests of alarm you can set with JES2
Alarm is showing on the monitor, email, and mobile phone
Batch OFF/ON
Check if BATCH can be stopped and started
All job classes must be off or on, based on their JES2 system affinity
Exit Test
Test all of your JES2 user modifications
JES2 exits works as designed
SYSLOG
Syslog works as expected
No problems identified
SWITCH_SYSLOG
Switch syslog data works as expected
No problems identified
SYSLOG_ARCHIVE
SYSLOG can be archived
No problems identified
Test Printing
•Print file from mainframe to remote printer
•Print from IMS
•Print file arrives in JES2 Spool
•File is printed
6.13.7 Restarting subsystem
After the basic system tests are completed successfully, you can consider restarting all subsystems. In our case study, we did observe any issue with all subsystems upon restart under JES2.
6.13.8 Releasing your BATCH
If all of the previous steps were successful, you can now consider releasing your BATCH jobs. This process includes enabling job submission in your BATCH controlling system and if it exists in your company, release system affinity in your JES2 job classes to allow jobs to run.
 
Attention: Carefully monitor JES2 default job class for misplaced jobs because of missing job class information.
6.13.9 Quitting your JES2 license
Quit your JES3 license at the end of the process. The cancellation period often is one month.
6.14 Project considerations
In this section, we describe some project-related line items that are non-technical. We start with the general project organization in a customer’s environment.
6.14.1 Project organization
The project organization is based on the resources of people that are available for the project. Because most of the migration actions can be done in parallel, we suggest bringing as many people as you can to the project to lower the project time.
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.
Figure 6-24 Project organization example
WP0 Project management
In this subproject, many important non-technical activities should be covered, such as creating and maintaining:
•Project plan
•Stakeholder planning
•Communication plan
•Resource plan
•Required leave plan for all participants
The overall project plan should address all of the project needs in small pieces. This process helps you to monitor all line items and identify problems and delays early.
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.
WP1 and WP8 all kinds of printing
This work product varies in your installation and can be more simple on your site. One of the major targets at the customer site was the migration and reprogramming of a custom-made REXX printer control tool. This conversion took almost two months of investigation, programming, and testing of the new print solution.
The only one task that is left is the migration of the printer names to the JES2 printer naming convention.
WP2 JES3 exits
WP2 was established to cover all kind of things that needed to remove or convert all used JES3 exits in a customer’s installation. It is recommended to create a list of all installed JES3 exits and rate what should be done we these exits, including the following options:
•Remove the exits and replace functionality by using other functions
•Remove the exit because it is no longer needed
•Convert the JES3 exit to JES2
•No action is required; JES3 exit does not exist under JES2 and is no longer needed after migration
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
WP3 JES3 unique functions
This subproject covers all required actions that needed to replace JES3 functions, such as:
•Depended Job Control
•DEADLINE processing
•Disk reader
One significant task is to identify all users that use such functions. The following methods can be used to identify these users:
•Scan your production JCL libraries for the existence of JES3-specific JECL cards
•Keep your SYSLOG/OPERLOG data with at least one year and check for jobnames that are using such functions
 
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.
WP4 migration of your JCL
The subproject intended to align all of your JCL and JECL to work with JES2 and JES3. The following areas were affected in the customer’s environment:
•Migration of production BATCH processing
•Migration of technical jobs from infrastructure teams, mostly outside of BATCH management systems
•Migration of user defines JCL, which were in user datasets
•Identify and adjust all types of JCL generators that were used
•Identify job dependencies in terms of behavior of JES2 versus JES3
 
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.
Complete the following steps:
1. Create JES2 command security according to your JES3 definitions.
2. Define JES2 STC security definition, which also is part of WP9.
3. Define security for JES2 working data sets, such as SPOOL and CKPT.
4. Define (if necessary) new printer security definitions because the printer names are subject to change.
 
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.
A part of the table of JES2 commands and their permissions are shown in Figure 6-24. You must add columns for permissions that are based on your organization.
Figure 6-25 Sample of JES2 command security table
WP6 general actions
In WP6, we covered all other actions that must be done that do not belong to any other work product. The following tasks were defined in the customer’s environment:
•Create and education plan that is based on your environment
•Conduct basic JES2 education sessions all stakeholders
•Conduct more detailed education for infrastructure and operating teams
•Remove JES3 DLOG and set up OPERLOG, which is required by JES2
•Migrate any tools (commercial or custom-made) that still use JES3 DLOG
 
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.
Table 6-23 Special education topics
Stakeholder
Education topics
JES2 system engineering
•JES2 start and shutdown in detail
•Important control block
•How to handle emergency situations:
 – SPOOL exhausted
 – CKPT damage
 – outage of an SPOOL volume
•Standard actions:
 – relocated CKPT
 – adding SPOOL
 – managing different start types
 – most important configuration settings
System controlling; for example, operations
•JES2 start and stop
•Explain default JES2 messages
•Explain useful JES2 commands to control the system
•JES2 start types
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.
WP7 system automation
Almost all customers have a powerful system automation process in place to reduce manual intervention for known processing. In JES2, we managed by using automation for the relocation of the JES3 global processor during planned or unplanned outages of z/OS systems.
This subproject included the following tasks:
•Analyzed all JES3-related automatic actions.
•Define more JES2 surveillance actions (new JES2 messages).
•Removed no longer needed JES3 processing options.
•Adjusted all runbooks that are placed on the system control site.
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.
WP9 JES2 system design and setup
This subproject covers all aspects of defining, sizing, and setting up JES2 in your environment.
 
Tip: This action should be done as soon as possible so that all stakeholders can test any types of items to migrate under JES2.
The following tasks must be completed:
•Define JES2 system layout:
 – Define naming conventions for all needed new started tasks for JES2
 – Define data set naming for SPOOL and CKPT data sets or CF structures
 – Calculate SPOOL and CKPT sizes that are based on your JES3 sizes
•Create JES2 system environment according to your company defaults:
 – Allocate SPOOL space on dedicated DASD volumes
 – Allocate CKPT datasets or CF structures
 – Create STC JCL in your PROCLIBs
 – Create JES2 PARMLIBs
 – Define all of your NJE nodes and adapt the names from your JES3 node names
•Create a migration concept
 
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.
6.14.2 Project timeframe
In this section, we provide information about the time schedule in a customer’s migration project.
 
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.
Figure 6-26 Migration timeframe
The following timeframes are shown in Figure 6-26 on page 191:
JCL Mass Migration The checkpoint is part of the entire production JCL that often is managed by a professional BATCH management system. This checkpoint often is not complex because all JCL libraries are known.
User JCL Migration Before any JES2 migration, any stakeholder must finish their migration of JCL and JECL and report as such to the project team.
JES2 Activation This date is the primary migration date for the specific sysplex.
JES2 alternative date This date is the planned backup date if the primary date is not working for any reason.
 
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset