JES2 functions to help migration
JES2 and JES3 evolved over time by introducing new functions that address the needs of their specific customer sets. As a result, specific statements in job entry control language (JECL) and job control language (JCL) are unique to JES2 or JES3 and created several differences between them.
This IBM Redbooks publication covers JES2 features that were included in JES2 that helps to decrease these differences. For more information about JECL and JCL the differences between the languages before z/OS V2.2, see JES3 to JES2 Migration Considerations, SG24-8083.
This chapter includes the following topics:
4.1 JES3 to JES2 migration options
We think that the best way to migrate from JES3 to JES2 is to convert your JES3 JCL and JECL to the JES2 equivalent instead of JES2 capability to interpret and convert JES3 JECL. This approach avoids confusion, eliminates the need to maintain skills in both types of JECL, and provides you with a clean base for moving forward. Nearly every JESS3-provided function can be re-created in a JES2 environment through a combination of standard JES2 functions, z/OS functions, and (if necessary) user exits.
4.2 Job Execution Control concept
The JES2 Job Execution Control (JEC) and Deadline Scheduling are features that were introduced in z/OS 2.2. We cover the following topics in this section:
•Purpose of the JEC
•New JOBGROUP and related JCL statements that comprise JEC
•Job group logging job, which is used to record state transitions within the group and facilitate job group management
•Simultaneous execution of a set of jobs that uses the CONCURRENT JCL statement
•Commands that are used to manage job groups
•Deadline Scheduling feature
JEC provides simple controls that can facilitate breaking down jobs into their constituent parts. That is, taking a multistep job and breaking it into multiple separate but related jobs. When these jobs are submitted, JES2 manages their execution in the correct order.
Also, by using JEC, you can define a set of two or more jobs for simultaneous execution. These jobs run in parallel on the same z/OS image. This function helps users that are running JES3 and JES2 by providing similar functions as the JES3 dependent job control (DJC) in the JES2 environment.
The principal entity that controls job execution within JEC is a job group. A job group is defined by a JOBGROUP JCL statement.
The following JCL statements provide JEC support:
•JOBGROUP: Creates a job group
•ENDGROUP: Denotes the end of the job group
•GJOB: Defines a job within a job group
•JOBSET: Provides convenient method to define and reference a set of jobs with identical dependencies
•SJOB: Defines a single job within the job set
•ENDSET: Denotes the end of the job set
•BEFORE: Defines jobs or job sets that the current job must run before
•AFTER: Defines jobs or job sets that the current job must run after
•CONCURRENT: Defines a set of jobs or job sets that must run at the same time (simultaneously) on the same z/OS image
•SCHEDULE: Associates a job with a job group
4.2.1 Job group concept
The job group is an entity that describes the relationships between multiple separate jobs. A job group is defined by the JOBGROUP JCL statement.
|
Note: The job group definition defines the dependencies between the jobs only. The constituent jobs are defined separately by a traditional JCL statement.
|
The definition of a job group is static. Jobs cannot be added and dependencies cannot be changed after the job group is defined.
A job group includes a job group logging job that is associated with it. This job is a special type of job that acts as the front end for the job group. It serves the following purposes:
•The JESJCLIN data set of the logging job includes statements that are used to define the job group.
•The job log data set (JESMSGLG) contains messages about important events that are related to the jobs in the job group and to transitions in the job group state. For example, a message is logged when the job group completes, when each job starts, completes, and then is flushed.
•The logging job is used as a front end for the job group by the commands that act on the group (hold, cancel, and purge).
•The logging job is used as a front end for the job group by the extended status subsystem interface (SSI) and the job modify SSI. It is used for filtering, and so on.
After a job group is instantiated, jobs can then register to it through the SCHEDULE JCL statement. Any JES2 batch job can be registered to a job group. These concepts are shown in Example 4-1.
Example 4-1 JOBGROUP Example
//TESTE1 JOBGROUP
//*
//TEST1 GJOB
//*
//TEST2 GJOB
// AFTER NAME=(TEST1,TEST6)
//*
//TEST3 GJOB
// AFTER NAME=TEST1
//*
//TEST4 GJOB
// AFTER NAME=TEST2
//*
//TEST5 GJOB
// AFTER NAME=TEST2
//TEST6 GJOB
//TEST7 GJOB
// AFTER NAME=TEST6
//MYGROUP ENDGROUP
When this JCL is submitted, JES2 instantiates job group TESTE1 in the JES2 checkpoint. A logging job with the name TESTE1 is also created. Notice that no jobs are registered to the group at this point.
When jobs are registered, the following process occurs:
•TEST2 runs after TES1 and TEST6 complete.
•TEST3 runs after TEST1.
•TEST5 runs after TEST2 finishes.
•TEST7 runs after TEST6 completes.
•TEST1 and TEST6 have no dependencies (they run immediately).
The SCHEDULE JCL statement is used to register (associate) jobs with the job group (see Example 4-2).
Example 4-2 SCHEDULE JCL Statement
// SCHEDULE JOBGROUP=TESTE1
The SCHEDULE JCL must follow the JOB statement before the first EXEC statement. A JCL error is generated if it is misplaced.
After the JCL for a job with a SCHEDULE statement is successfully processed, the job is registered to the job group that is named on the JOBGROUP keyword. Jobs that are defined as part of a job group can be submitted in any order. However, you must submit them after the JCL of the job group is processed and the job group definition is committed to the JES2 checkpoint.
The job group owns certain resources and is authenticated by using the same process as normal batch jobs. This authentication includes checking profiles, such as the JESJOBS SUBMIT profile.
When a batch job is submitted that is registered to a job group, a check is made while the job is converting to validate the jobs access to the job group. If the user ID that owns the job group is the same as the user ID that owns the batch job, no other validation is performed (that is, no profiles are checked). If the user IDs are not the same, a check for authentication is made.
For more information about JOBGROUPs examples, see Appendix D, “DJC conversion and JEC examples” on page 225.
Use of JOBSET
JOBSET is a convenient method to define jobs with the same set of dependencies within a JOBGROUP. In the example that is shown in Figure 4-1 on page 47, TEST3, TEST4, and TEST5 share dependencies.
Figure 4-1 Use of JOBSET
All references to the set are made by using the set name (SET1).
CONCURRENT statement
The CONCURRENT statement denotes that the following jobs must run simultaneously on the same z/OS image:
•The job that is specified by GJOB statement
•One or more jobs that are listed in the NAME parameter of the CONCURRENT statement
The jobs that are associated in this manner comprise what is called a concurrent set.
The syntax of the CONCURRENT JCL statement is shown in Example 4-4.
Example 4-3 CONCURRENT Statement
//TEST5 GJOB
// CONCURRENT NAME=name|(name,name,….)
It is important to understand the difference between the following aspects of job execution:
•Parallelism that is provided by the CONCURRENT statement
•Job-execution parallelism that is provided by the basic job group functionality
For example, consider jobs in a job group that do not have dependencies between them that are defined by BEFORE and AFTER JCL statements. Such jobs can run in any order on any z/OS image at the same time or at different times, depending on the operational state of z/OS images. In contrast to that example, jobs in a concurrent set must run at the same time on the same z/OS image.
JOBGROUP commands
Various operator commands can be used on the job group after the group is instantiated, including the following examples:
•$CG’MYGROUP’: Cancel a job group and all the jobs that are registered to it.
•$PG’MYGROUP’: Purge a job group (if completed) and all jobs that are registered to it.
•$HG’MYGROUP’: Hold a job group.
•$AG’MYGROUP’: Release a job group.
•$TG’MYGROUP’: Change attributes of a job group.
•$DG’MYGROUP’,SUMMARY: Display a summary of a job group.
•$DG’MYGROUP’,JOBS: Display only job information for the job group.
The example that is shown in Example 4-1 on page 45 is simple. The 10 new JCL statements provide the base that can be used to model complex job relationships.
The job log data set for the logging job shows step-by-step information about the execution flow of the jobs in the job group. Also, the JOBGROUP commands provide the control and monitoring functions that are needed to maintain a smoothly running job group.
4.2.2 Deadline scheduling
JES2 provides functions to hold jobs until a specified time and to make jobs more likely to start running by a specified time. Various keywords of a SCHEDULE statement provide the following convenient functions that add flexibility to the job management task:
•Use the HOLDUNTL; keyword to specify that the job must be in the held state until the time that is specified by the keyword. Then, the job is automatically released and can become eligible for execution.
•Use the STARTBY; keyword to specify the target execution deadline for the job.
•Use the WITH; keyword to indicate that the job must not run unless another (reference) job is active. When the job runs, the job must run on the same z/OS image as the reference job.
You can use these features on their own or together with the JEC to further enhance the job scheduling capabilities of native work management on z/OS.
HOLDUNTL
HOLDUNTL keyword on the SCHEDULE statement tells the system that a job must be placed in the held state at the submit time and be released at the specified time.
HOLDUNTL specifies the time in one of the following formats:
•Interval notation: Some number of hours and minutes from the time the job was submitted to the system. The syntax HOLDUNTL=’+03:20 means that job must be released 3 hours and 20 minutes after the submission.
•Point In Time Notation: Direct specification of the time and optionally date when a job must be released. The syntax HOLDUNTL=('13:15',’01/08/2018’) means that job must be released at 1:15 PM on Aug. 5, 2018.
STARTBY
By using the STARTBY keyword on the SCHEDULE statement, a user can specify an approximate time in the future to start the job. The system manages the priority of the job so that the job is near the top of the relevant job class or service class queue by the target time. In a sense, this function provides a time-controlled alternative to traditional priority aging.
STARTBY syntax is identical to the syntax of the HOLDUNTL function. Target time can be specified in one of the same two formats: Interval or point-in-time notation.
WITH
Another job scheduling function is provided by the WITH keyword of the SCHEDULE statement. The WITH keyword indicates that a job must be selected for execution on the same system where another job (a reference job) is active. Until a reference job becomes active, the job that uses WITH function cannot be selected for execution.
The jobs can be submitted in any order. However, it is better to use the WITH keyword to submit and start the reference job before the jobs that point to it. A different order causes more system overhead.
A reference job does not have to be unique in the JESplex. If multiple jobs with the correct name are active on different z/OS images, the system chooses one of them. The choice of a z/OS image is unpredictable.
4.3 JES3 JECL processing support in JES2
JES2 can process various JES3 JECL statements if the corresponding options is activated. With this option, most of JES3 JECL statements can be processed by JES2 transparently. This option reduces the JECL conversion that is needed to run jobs that are originally coded for JES3 in a JES2 environment. As a result, you migrate JES3 to JES2 with minimal changes to your JES3 JECLs.
4.3.1 Activating JES3 JECL support
JES2 supports the processing of JES3 JECL statements in native support or translation into supported statements. The INPUTDEF JES3JECL and the JECLDEF JES3 initialization statements control how JES2 input processing handles various JES3 JECL statements. You can also use commands to perform the same control task.
Two levels of activation for this support are provided. In the first level, the following command enables the recognition of JES3 JECL syntax as JECL and not as a comment:
$T INPUTDEF,JES3JECL=PROCESS
This command tells JES2 that whenever a JES3 JECL statement is encountered, JES2 attempts to process it directly or by translating it into a JCL or a JES2 JECL statement.
However, if you issue the command $T INPUTDEF,JES3JECL=IGNORE, JES2 ignores all JES3 JECL statements. This option is the default.
The second level controls how each JECL statement is processed, as shown in the following example:
$T JECLDEF,JES3=(MAIN=PROCESS,DATASET=PROCESS,ROUTE=PROCESS,….)
This function supports the primary (//*) and alternative (/*) prefix for JES3 JECL. However, /* for NETACCT and ROUTE XEQ defaults to JES2 JECL.
INPUTDEF and JECLDEF feature single-member scope. Therefore, you can apply the same definition to all MAS members to keep consistent behavior among MAS members.
Also, in a hot start, INPUTDEF and JECLDEF in the initialization deck including defaults (IGNORE) are used unconditionally. This usage applies, even if you modified INPUTDEF or JECLDEF by $T commands before JES2 restarts. Therefore, you must define these statements explicitly in the initialization deck if you want to change the default value (IGNORE).
JES3 JECL toleration: JECLDEF for JES3
The following parameters are used for controlling JES3 JECL processing:
JECLDEF JES3=(
MAIN = PROCESS | IGNORE| WARN | FAIL
FORMAT = PROCESS | IGNORE| WARN | FAIL
ROUTE = PROCESS | IGNORE| WARN | FAIL
OPERATOR = PROCESS | IGNORE| WARN | FAIL
DATASET = PROCESS | IGNORE| WARN | FAIL
ENDDATASET = PROCESS | IGNORE| WARN | FAIL
PROCESS = PROCESS | IGNORE| WARN | FAIL
ENDPROCESS = PROCESS | IGNORE| WARN | FAIL
NET = PROCESS | IGNORE| WARN | FAIL
NETACCT = PROCESS | IGNORE| WARN | FAIL
PAUSE = PROCESS | IGNORE| WARN | FAIL)
Consider the following points:
•PROCESS means that the specific JES3 JECL statement is to be processed (translated or directly processed).
•IGNORE means that the specific JES3 JECL statement is not recognized and ignored, which is the default.
•WARN means that the specific JES3 JECL statement is to be processed (translated or directly processed), but a warning message is issued, as shown in the following example:
HASP1130 JECL card xxxx encountered
•FAIL means that the specific JES3 JECL statement is not to be processed and the corresponding job is not run with a JCL ERROR, as shown in Example 4-4.
Example 4-4 FAIL indicating that specific JES3 JECL statement is not processed
IEFC452I jobname - JOB NOT RUN - JCL ERROR
$HASP106 JOB DELETED BY JES2 OR CANCELLED BY OPERATOR BEFORE EXECUTION
HASP1130 JECL card xxxx encountered
Level of support for JES3 JECL
Each statement has different support level, as shown in Example 4-5.
Example 4-5 Support levels for JES3 JECL
//*DATASET Tolerated, but not supported
//*ENDDATASET Required if //*DATASET used
//*FORMAT Partially supported (converted to OUTPUT JCL card)
//*MAIN Partially supported
//*NET Partially supported (converted to JES2 job group)
//*NETACCT Fully supported
//*OPERATOR Supported, but message text ends in 71, not 80
//**PAUSE Not supported, ignored if present
//*PROCESS Tolerated, but not supported
//*ENDPROCESS Tolerated, but not supported
//*ROUTE XEQ Fully supported
//*MAIN JECL keywords support
Each MAIN JECL keyword has different support level, as shown in Example 4-6.
Example 4-6 //*MAIN keywords support level
ACMAIN, IORATE, LREGION, MSS, RINGCHK, TRKGRPS, TYPE –Obsolete
BYTES, CARDS, CLASS, HOLD, JOURNAL, LINES, ORG –Supported
PAGES, PROC, SYSTEM –Supported
DEADLINE, EXPDTCHK, FAILURE, FETCH, SETUP, SPART –Not supported
THWSSEP, UPDATE, USER –Not supported
Obsolete means that a warning message is issued (as shown in the following example) and the keyword is ignored:
HASP1132 Obsolete keyword xxxx ignored
Not supported means that a warning message is issued (as shown in the following example) and the keyword is ignored:
HASP1133 Unsupported keyword xxxx used
//*FORMAT JECL keywords support
As with //*MAIN JECL keywords, each //*FORMAT JECL keyword has a different support level, as shown in Example 4-7.
Example 4-7 //*FORMAT keywords support
PR/PUpositional –ignored
DDNAME, CARRIAGE/FCB, CHARS, COMPACT, COPIES, DEST –supported
EXTWTR, FLASH, FORMS, MODIFY, PRTY, STACKER, TRAIN–supported
CHNSIZE, INT, OVFL, THRESHLD –not supported
Not supported means that an error message is issued (as shown in the following example) and the keyword is ignored:
HASP1133 Unsupported keyword xxxx used
Each //*FORMAT statement requires a //OUTPUT statement, which is placed just after the JOB statement and before the first EXEC statement and created automatically by JES2 as part of the //*FORMAT JECL processing. The name that is given the OUTPUT statements uses the format JES2nnnn, where nnnn begins at 0000, as shown in Example 4-8.
Example 4-8 OUTPUT statement format
HASP1312 JES20000 OUTPUT statement created for this //*FORMAT
//JES20000 OUTPUT DDNAME=SYSUT2,COPIES=2 <- created OUTPUT JCL by JES2
//*FORMAT PR,DDNAME=SYSUT2,COPIES=2 <- original JES3 //*FORMAT JECL
//*NETACCT keyword support
All keywords are supported in the same way that JES3 supports them.
//*NET JECL keywords support
Each //*NET JECL keyword has different support level, as shown in Example 4-9.
Example 4-9 //*NET keywords support
ID/NETID, ABCMP/AC,ABNORMAL,NORMAL,NETREL/NR –Supported
NHOLD/HC,NRCMP/PC,OPHOLD/OH,RELEASE/RL–Supported
DEVPOOL, DEVRELSE,RELSCHCT/RS -Obsolete
Obsolete means that a warning message is issued (as shown in the following example) and the keyword is ignored:
HASP1132 Obsolete keyword xxxx ignored
The following message is issued if keywords are supported:
HASP1309 //*NET card - Statement successfully processed
You see this message even when obsolete parameters are included with HASP1132.
For more information about DJC, see 6.6, “Transforming JES3 special functions” on page 143.
//*ROUTE XEQ keyword support
The keyword XEQ is supported in same way that JES3 supports it. JES2 does not support alternative JES3 /*ROUTE XEQ syntax because of a conflict with the JES2 /*ROUTE XEQ statement.
JES3 JECL support summary
JES3 JECL support is listed in Table , where it is assumed that INPUTDEF JES3JECL=PROCESS is enabled.
Table 4-1 JES3 JECL support
|
JES3 JECL
|
Support level
|
JECLDEF
PROCESS
|
JECLDEF
IGNORE
|
JECLDEF
WARN
|
JECLDEF
FAIL
|
|
DATASET
|
Tolerated, but not supported
|
No additional message
|
JCL error (IEFC019I1)
|
HAS11302
|
HASP1130b
IEFC019Ia
$HASP1063
|
|
ENDDATASET
|
Tolerated, but not supported
|
No additional message
|
JCL error (IEFC019Ia)
|
HAS1130b
|
HASP1130b
IEFC019Ia
$HASP106c
|
|
FORMAT
|
Partially supported
(converted to
JES2 job group)
|
HASP13124
(HASP11335)
|
N/A
|
HASP1130b
HASP1312d
(HASP1133e)
|
HASP1130b
$HASP106c
|
|
MAIN
|
Partially supported
|
No additional msg
(HASP11326)
(HASP1133e)
|
N/A
|
HASP1130b
HASP1132f)
(HASP1133e)
|
HASP1130b
$HASP106c
|
|
NET
|
Partially supported
(converted to
OUTPUT JCL)
|
HASP13097
HASP13008
HASP13019
HASP130410
(HASP1132f)
|
N/A
|
HASP1130b
HASP1309g
HASP1300h
HASP1301i
HASP1304j
(HASP1132f)
|
HASP1130b
$HASP106c
|
|
NETACCT
|
Fully supported
|
No additional message
|
N/A
|
HASP1130b
|
HASP1130b
$HASP106c
|
|
OPERATOR
|
Supported, but message text ends in 71, not 80
|
$HASP10411
|
N/A
|
HASP1130b
|
HASP1130b
$HASP106c
|
|
PAUSE
|
Not supported, ignored if present
|
JCL error for //*PAUSE
(IEFC607I)12
|
JCL error for //*PAUSE
(IEFC607Il)
|
JCL error for //*PAUSE
(IEFC607Il)
|
JCL error for //*PAUSE
(IEFC607Il)
|
|
PROCESS
|
Tolerated, but not supported
|
No additional message
|
N/A
|
HASP1130b
|
HASP1130b
$HASP106
|
|
ENDPROCESS
|
Tolerated, but not supported
|
No additional message
|
N/A
|
HASP1130b
|
HASP1130b
$HASP106c
|
|
ROUTE
|
Fully supported
|
No additional message
|
N/A
|
No additional msg
|
HASP617513
HASP617614
HASP617715
|
1 IEFC019I MISPLACED statement STATEMENT
2 HASP1130 JECL card ccccccccccc encountered
3 $HASP106 jobname DELETED BY JES2 OR CANCELLED BY OPERATOR BEFORE EXECUTION
4 HAS1312 JES2nnnn OUTPUT statement created for this //*FORMAT
5 HASP1133 Unsupported keyword kkkkkkkk used
6 HASP1132 Obsolete keyword kkkkkkkk ignored
7 HASP1309 Job name //*NET statement successfully processed.
8 HASP1300 jobname registered to job group jobgroupname (SYSLOG only)
9 HASP1301 jobname in job group jobgroupname queued for execution (SYSLOG only)
10 HASP1304 job group jobgroupname is complete (SYSLOG only)
11 $HASP104 jobname text
12 IEFC607I JOB HAS NO STEPS
13 HASP6175 jobname Job to be transmitted has no records
14 HASP6176 jobname Expected JOB/NJB statement not found after //*ROUTE XEQ
15 HASP6177 jobname Encountered statement
JECL generic tracker
JES2 is instrumented to report the use of JES3 JECL in jobs that were submitted to the system and processed by JES2. Occurrences of JES3 JECL statements in a job stream are reported by using the Generic Tracker macro GTZTRACK. When GTZ tracking is enabled, JES2 records GTZ data that identifies the JES3 JECL statements that are found within a job stream. It applies to JES2 and JES3 JECL if the JECL type is active on INPUTDEF.
As an example of a job we created with JES3 JECL is shown in Example 4-10.
Example 4-10 JES3 JECL example
//TESTJOB JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//*MAIN SYSTEM=SC75,TYPE=VS2,SETUP=HWS,LINES=(100,C)
//*FORMAT PR,DDNAME=SYSUT2,COPIES=1,THRESHLD=20000
//*NETACCT PNAME=FURUYA,BLDG=POK008
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
Tracking (that is, recording track events) is disabled by default. When tracking is disabled, invocations of GTZTRACK are allowed, but ignored by the system. Use the SETGTZ TRACKING=ON operator command to enable tracking, as shown in Example 4-11.
Example 4-11 Generic tracking
SETGTZ TRACKING=ON
GTZ1105I SETGTZ TRACKING PROCESSING IS COMPLETE
$HASP100 TESTJOB ON INTRDR FROM TSU08997
LPRES1
IRR010I USERID LPRES1 IS ASSIGNED TO THIS JOB.
ICH70001I LPRES1 LAST ACCESS AT 14:14:25 ON WEDNESDAY, JUNE 6, 2018
$HASP373 TESTJOB STARTED - INIT 1 - CLASS A - SYS SC75
IEF403I TESTJOB - STARTED - TIME=10.42.31
Jobname Procstep Stepname CPU Time EXCPs RC
TESTJOB --None-- STEP01 00:00:00 313 00
IEF404I TESTJOB - ENDED - TIME=10.42.31
$HASP395 TESTJOB ENDED - RC=0000
$HASP309 INIT 1 INACTIVE ******** C=ABCDE
D GTZ,TRACKDATA
GTZ1002I 10.42.59 GTZ TRACKDATA 392
FOUND 1 MATCHING TRACKED INSTANCE(S)
----------------------------------------------------------------------
INSTANCE: 1 COUNT: 1
EVENTDESC: '|01101000 0|00000000 0| INTRDR TESTJOB LPRES1 '+
' JES2 '
OWNER: IBMJES2 SOURCE: HASCINJR
EVENTDATA: x0000000000000000 x0000000000000000
PROGRAM: *UNKNOWN PROGRAMOFFSET: x0000000000000000
HOMEJOB: LPRES1 HOMEASID: x0049
EVENTJOB: LPRES1 EVENTASID: x0049
AUTHORIZED: YES FIRST TIME: 2018-06-07 10:42:30
The sample job specified three JES3 JECLs, as shown in Example 4-10 on page 53. In the same example, you can see the result of the D GTZ,TRACKDATA command, which includes the following displayed fields:
•OWNER: The string IBMJES2. It identifies the JES2 subsystem as the source of the GTZ record.
•SOURCE: Identifies the JES2 module that identified the occurrence of a JES3 control statement in the job stream (HASCINJR).
•EVENTDATA: Set to zeros.
•PROGRAM: Is *UNKNOWN.
•PROGRAMOFFSET: Is zeros because JES2 provides no program-specific information.
•EVENTDESC: A 46-character string in which JES2 provides information about the job stream and the JES3 control statement usage within the job stream. The contents of EVENTDESC by character position are listed in Table 4-2 on page 55.
Table 4-2 EVENTDESC field description
|
Position
|
Meaning and field description
|
|
1
|
A starting delimiter, which is the vertical bar character “|”, for the JES3 or JES2 JECL control statement usage indicators
|
|
2-18
|
Each character identifies whether a specific JES3 or JES2 JECL control statement is used in the job stream; Not used (0), Used (1)
|
|
2
|
//*DATASET statement
|
|
3
|
//*FORMAT statement
|
|
4
|
//*MAIN statement
|
|
5
|
//*NET statement
|
|
6
|
//*NETACCT statement
|
|
7
|
//*OPERATOR statement
|
|
8
|
//*PAUSE statement
|
|
9
|
//*PROCESS statement
|
|
10
|
Blank character
|
|
11
|
//*ROUTE statement
|
|
12
|
A delimiter that is the vertical bar character “|”
|
|
13
|
/*JOBPARM statement
|
|
14
|
/*MESSAGE statement
|
|
15
|
/*OUTPUT statement
|
|
16
|
/*ROUTE statement
|
|
17
|
/*SETUP statement
|
|
18
|
/*XEQ statement
|
|
19
|
/*NETACC statement
|
|
20
|
/*NOTIFY statement
|
|
21
|
Blank character
|
|
22
|
/*XMIT statement
|
|
23
|
A delimiter that is the vertical bar character “|”
|
|
24
|
Blank character
|
|
25-34
|
JES2 device name for point of entry for the job stream
|
|
35
|
Blank character
|
|
36-43
|
Job name.
|
|
44
|
Blank character
|
|
45-52
|
Submitting TSO user ID when SOURCE=HASCINJR
|
|
53
|
Blank character
|
|
54-57
|
JES2 subsystem name JES2 JECL
|
4.3.2 //*NET support detail
JES2 support for //*NET must be enabled by using the following commands:
$T INPUTDEF,JES3JECL=PROCESS
$T JECLDEF,JES3=(NET=PROCESS)
When enabled, JES2 migrates JES3 //*NET JECL to JES2 JOBGROUPs, called a //*NET JOBGROUP. Created JOBGROUPs are marked as including a //*NET statement origin that allows runtime processing to emulate the behavior of JES3 //*NET. However, runtime behavior differs from standard JOBGROUPs. JOBGROUP name is the NETID= as specified on the //*NET statement. Name space is shared with traditional JOBGROUPs.
//*NET JOBGROUPs are built dynamically as jobs with //*NET statements are processed during INPUT phase. For JEC JOBGROUPs, the entire network exists before any jobs are “registered” to it. The intent of this support is to emulate JES3 //*NET behavior as closely as possible.
HOLD counts are maintained by the //*NET JOBGROUP. Commands to modify HOLD counts are supported.
Provided commands are similar to the corresponding JES3 commands. Runtime behavior for //*NET JOBGROUPs is tailored to emulate JES3 //*NET behavior as much as possible. Substantial runtime differences exist with traditional JOBGROUP behavior. No requirement exists that dictates that a target RELEASE= job exist when a parent job runs. This condition is the same for NETREL= network or target job.
//*NET options and support available in JES2
The following JES2 //*NET options and support are available:
•NETID=name
JES2 supports as the name of the JOBGROUP. A logging job is created.
•NHOLD=n
JES2 supports this option.
•Release=(jobname, jobname, …)
JES2 supports, treats similar to job group BEFORE processing.
•NETREL=(netid,jobname)
JES2 supports this option.
•NORMAL=(D or F or R)
JES2 supports this option.
•ABNORMAL=(D or F or R)
JES2 supports this option.
•ABCMP=(KEEP or NOKP)
JES2 supports this option.
•DEVPOOL=(ANY or NET or device-name,n)
JES2 does not support (ignored).
•DEVRELSE=(YES or NO)
JES2 does not support (ignored).
•NRCMP=(HOLD or NOHO or FLSH)
JES2 supports this option.
•OPHOLD=(YES or NO)
JES2 supports this option.
•RELSCHCT=n
JES2 does not support (ignored).
//*NET and security
Because NETs use the job group infrastructure, some JEC processing applies. Logging job is created for NET job groups. The name of the logging job is the name in the NETID= keyword.
The owner of the logging job is the same as the job that triggered its creation. Jobs registering (connecting) to the job group must pass a security check. The profile for the job groups you want to protect must have the same user ID as the logging job or READ access to the JESJOBS entity by using the following format:
GROUPREG.nodename.groupname.userid
//*NET JOBGROUP peculiarities
//*NET JOBGROUPs are built dynamically as each job is processed. Dependencies are built from the RELEASE= statement of a “parent” job. However, the dependencies cannot be populated until the NORMAL= and ABNORMAL= definitions of a dependent job are processed. A window of time exists when a dependency is “undefined”.
//*NET dependencies are now initialized as undefined when they are created. Jobs in a //*NET JOBGROUP can run out of order. A job can run whenever the HOLD count reaches zero (by using a command or definition). That is, job execution is not fully controlled by dependencies. //*NET JOBGROUPs have no concept of a concurrent set of jobs.
//*NET and JOBGROUP commands
The following job group commands work against //*NET job groups:
•Display overview of a //*NET JOBGROUP:
$DG*,JM=MYNET
•Display jobs in a //*NET JOBGROUP:
$DG*,JM=MYNET,JOBS
•Display dependencies in a //*NET JOBGROUP:
$DG*,JM=MYNET,DEP
•Cancel a //*NET JOBGROUP:
$CG*,JM=MYNET
•Purge a //*NET JOBGROUP:
$PG*,JM=MYNET
|
Note: MYNET is the NETID name (that is, - //*NET NETID=MYNET).Dependencies are created from the //*NET RELEASE=(jobname[,jobname]...) clause.
|
The following NHOLD operands are for jobs that are in //*NET JOBGROUPs:
•Display HOLD count value:
$DJ,JM=MYJOB,NHOLD
•Decrement HOLD count value:
$TJ,JM=MYJOB,NHOLD=-
•Increment HOLD count value:
$TJ,JM=MYJOB,NHOLD=+
•Force HOLD count to zero:
$TJ,JM=MYJOB,NHOLD=0
These commands are similar in function to what JES3 provides.
//*NET JOBGROUP peculiarities
Undefined dependencies result in pending or null data in displays. As shown in Example 4-12, successor (dependent) jobs (JOBB and JOBC) are not yet entered to JES2.
Example 4-12 JOBGROUP Display
$DG*,JM=NET1,JOBS,DEP
$HASP890 JOB(NET1) 651
$HASP890 JOB(NET1) JOB GROUP JOB LIST
$HASP890 JOB NAME JOBID JOB STAT COMP STAT HC
$HASP890 -------- -------- -------- --------- --
$HASP890 JOBZ JOB09109 Q=HRDCPY COMPLETE 0
$HASP890 JOBC NONE NOT REG PENDING 0
$HASP890 JOBB NONE NOT REG PENDING 0
$HASP890 JOBA JOB09107 Q=HRDCPY COMPLETE 0
$HASP890 JOB GROUP DEPENDENCY LIST
$HASP890 PARENT DEP JOB DEP STAT COMP ACT
$HASP890 -------- -------- -------- ---------
$HASP890 JOBZ JOBB UNDEFINE SATISFY
$HASP890 JOBA JOBC UNDEFINE SATISFY
$HASP890 JOBA JOBB UNDEFINE SATISFY
//*NET NETREL= support
//*NET JOBGROUPs supports NETREL=. This parameter reduces the NHOLD count for a job in another DJC network. If the target job group does not exist, a JOBGROUP object is created. A target job structure also is created (see Example 4-13).
Example 4-13 $DG example
$DG*,JM=NET2
$HASP890 JOB(NET2) 108
$HASP890 JOB(NET2) JOB_GROUP_STATUS=PENDING,
$HASP890 ONERROR=SUSPEND,SYSAFF=(ANY),HOLD=(NO),
$HASP890 OWNER=LPRES1
$DG*,JM=NET2,JOBS
$HASP890 JOB(NET2) 110
$HASP890 JOB(NET2) JOB GROUP JOB LIST
$HASP890 JOB NAME JOBID JOB STAT COMP STAT HC
$HASP890 -------- -------- -------- --------- --
$HASP890 JOBD NONE NOT REG PENDING -1
Although another job released NET2 of JOBD, NET2 of JOBD is not yet entered to JES2.
//*NET JOBGROUPs and Extended Status SSI
JES2 JOBGROUPs are used to implement //*NET networks. Existing JOBGROUP Extended Status infrastructure is used without change. The RELEASE= job name list is returned as multiple dependency (STATDB) objects.
New job information (STATJQ) //*NET subsection is added (STATNETI), which includes the following //*NET statement keyword information:
•Original HOLD count value (STNEOHLD)
•NETREL= NETID name (STNENRID)
•NETREL= JOB name (STNENRJB)
•NORMAL= value (STNENORM)
•ABNORMAL= value (STNEABNR)
•ABCMP= value (STNEABCM)
•NRCMP= value (STNENRCM)
•OPHOLD= value (STNEPHLD)
The following job information (STATJQ) JOBGROUP in the information subsection (STATJZXC) was updated:
•Network Origin Indicator (STJZ1NOI):
– OFF = Network is a static (JEC) JOBGROUP
– ON = network is a //*NET JOBGROUP
•Current HOLD count value (STJZCHLD)
•NETREL= NETID name (STJZNRID)
•NETREL= JOB name (STJZNRJB)
Also, HOLD count filter is added (STATHCFV). This option allows filtering on current HOLD counts =, >, <, >=, <=, != to STATHCFV. See fields STATSHCE, STATSHCL, and STATSHCG for their dependencies on STATHCFV.
For more information, see Appendix F, “Alternative conversion programs” on page 263.
4.3.3 //*ROUTE XEQ support detail
JES2 implements the support to //*ROUTE XEQ JECL statement that reduces the work that is required to convert JECL statements in a JES3 to JES2 migration. With this support, all //*ROUTE XEQ JECL statements that are coded on JES3 JCL are recognized and processed by JES2.
The syntax rules used by JES2 are the same as JES3, as shown in the following example:
//*ROUTE XEQ dest[.vmguestid]
JES2 does not support the alternative /*ROUTE XEQ syntax that is used by JES3 because of conflicts with the JES2 /*ROUTE XEQ syntax.
The //*ROUTE XEQ statement is used to send the following input stream to a network node where the job is then run. JES2 stops transmitting the input stream records when it finds one of the following conditions:
•A second JOB statement after the //*ROUTE XEQ statement.
•The input stream runs out of records.
Statement after //*ROUTE XEQ
An error in the //*ROUTE XEQ statement can cause the JOB statement that is following the //*ROUTE XEQ to be processed at the submitting node. To prevent this issue, code NJB instead of JOB on the second JOB statement. JES2 changes the NJB to JOB before transmitting the job.
|
Note: Consider the following points:
•TSO/E users must code NJB instead of JOB on the second JOB statement.
•If a JOB statement is not immediately following the //*ROUTE XEQ statement, the /*XMIT JCL statement must be used instead of //*ROUTE XEQ.
|
Example of //*ROUTE XEQ submitted by TSO/E user
In Example 4-14, the JOB JOBXEQ74 is sent to JES2 at system SC74 in node WTSCPLX7 by a SUBMIT command that is issued on a TSO/E edit session. The //*ROUTE XEQ statement tells JES2 to send the subsequent input stream (starting with the NJB statement JOBXEQ80) to the network node (WTSCPLX8) where the job is then run.
JES2 converts the NJB to JOB statement before transmitting the stream. Transmission of the input stream is stopped by the JOB statement JOBXEQ75. Job JOBXEQ80 is read and run by the system at node WTSCPLX8 (see Example 4-14). Job JOBXEQ75 is run at SC75 system of WTSCPLX7 node.
Example 4-14 JOB using //*ROUTE XEQ JECL submitted from a TSO/E
//JOBXEQ74 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//*ROUTE XEQ WTSCPLX8
//JOBXEQ80 NJB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//OUTPUT OUTPUT DEST=WTSCPLX7
//*
/*JOBPARM S=SC80
//*
//STEP01 EXEC PGM=IEFBR14
//*
//JOBXEQ75 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
/*JOBPARM S=SC75
//*
//STEP01 EXEC PGM=IEFBR14 
Example 4-15, Example 4-16 on page 61, and Example 4-17 on page 61 show the messages that are issued by the process of JOB by using the //*ROUTE XEQ.
Example 4-15 Messages from SC74 system processing the submitted job in Example 4-14
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '10.11.58 JOB02052 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
WTSCPLX8',LOGON,USER=(LPRES3)
$HASP100 JOBXEQ75 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP524 L9.JT1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654AE99)
$HASP540 JOBXEQ80 ON L9.SR1 FROM *UNKNOWN AT WTSCPLX8 65 RECORDS
SE '10.11.58 JOB02052 $HASP122 JOBXEQ80 (JOB02052 FROM WTSCPLX7)
RECEIVED AT WTSCPLX8',LOGON,USER=(LPRES3)
Example 4-16 Messages from SC75 processing the job JOBXEQ75
IEF196I IEFA111I INIT IS USING THE FOLLOWING JOB RELATED SETTINGS:
IEF196I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
ICH70001I LPRES3 LAST ACCESS AT 09:07:53 ON WEDNESDAY, JUNE 26, 2019
$HASP373 JOBXEQ75 STARTED - WLM INIT - SRVCLASS DFLT_MG - SYS SC75
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ75 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ75 ENDED - RC=0000
SE '10.31.44 JOB02053 $HASP165 JOBXEQ75 ENDED AT WTSCPLX7 - JOBRC=0000
',LOGON,USER=(LPRES3)
Example 4-17 Messages from SC80 system processing the received job JOBXEQ80
$HASP373 JOBXEQ80 STARTED - INIT 1 - CLASS B - SYS SC80
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ80 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ80 ENDED - RC=0000
$HASP309 INIT 1 INACTIVE ******** C=ABC
$HASP530 JOBXEQ80 ON L9.ST1 65 RECORDS
$HASP534 L9.ST1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654AE99)
Example of //*ROUTE XEQ submitted by $SUBMIT command
In Example 4-18, the JOB statement JOBXEQ74 is sent to JES2 at system SC74 on node WTSCPLX7 by a $SUBMIT command that is issued from an operator’s console. The //*ROUTE XEQ statement tells JES2 to send the subsequent input stream (starting with the JOB statement JOBXEQ80) to the network node (WTSCPLX8) where the job is then executed. Transmission of the input stream is stopped by the JOB statement JOBXEQ75. Job JOBXEQ75 is read and run by the system SC75 at node WTSCPLX7 (see Example 4-18).
Example 4-18 JOB using //*ROUTE XEQ JECL submitted by a $SUBMIT Command
//JOBXEQ74 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//*ROUTE XEQ WTSCPLX1
//JOBXEQ75 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=IEFBR14
//*
//JOBXEQ76 JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=IEFBR14
//*
To submit the job that is shown in Example 4-18, the following command was issued at the operator’s console:
$SUBMIT,MEMBER=JCLROUTE,DDNAME=SUBLIB00
This command calls the JES2 Disk Reader function to submit the job from a data set or an z/OS UNIX directory. The related messages from z/OS OPERLOG are shown in Example 4-19.
Example 4-19 Sample of $SUBMIT command issued to start a JOB with //*ROUTE XEQ JECL
$SUBMIT,MEMBER=JCLROUTE,DDNAME=SUBLIB00
$HASP000 OK
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM $SUBMIT
JCLROUTE
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '10.49.56 JOB02054 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
WTSCPLX8',LOGON,USER=(LPRES3)
$HASP100 JOBXEQ75 ON INTRDR ITSO REDBOOKS FROM $SUBMIT
JCLROUTE
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP524 L9.JT1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654B715)
$HASP540 JOBXEQ80 ON L9.SR1 FROM *UNKNOWN AT WTSCPLX8 65 RECORDS
ICH70001I LPRES3 LAST ACCESS AT 10:31:44 ON WEDNESDAY, JUNE 26, 2019
$HASP373 JOBXEQ75 STARTED - WLM INIT - SRVCLASS DFLT_MG - SYS SC75
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ75 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ75 ENDED - RC=0000
SE '10.49.56 JOB02054 $HASP122 JOBXEQ80 (JOB02054 FROM WTSCPLX7)
RECEIVED AT WTSCPLX8',LOGON,USER=(LPRES3)
SE '10.49.56 JOB02055 $HASP165 JOBXEQ75 ENDED AT WTSCPLX7 - JOBRC=0000
',LOGON,USER=(LPRES3) 
In Example 4-18 on page 61, the job JOBXEQ74 is used only to tell JES2 to transmit the subsequent job stream to WTSCPLX8 until the JOBXEQ75 JOB statement. The job JOBXEQ75 is processed locally.
The system SC80 messages when processing the job JOBXEQ80 that is transmitted by a //*ROUTE XEQ JECL statement on JOBXEQ74 job submitted by using the $SUBMIT command is shown in Example 4-20.
Example 4-20 Messages from SC80 system processing the transmitted job
$HASP100 JOBXEQ80 ON L9.JR1 ITSO REDBOOKS FROM *UNKNOWN
AT WTSCPLX7
$HASP373 JOBXEQ80 STARTED - INIT 1 - CLASS B - SYS SC80
Jobname Procstep Stepname CPU Time EXCPs RC
JOBXEQ80 --None-- STEP01 00:00:00 8 00
$HASP395 JOBXEQ80 ENDED - RC=0000
$HASP309 INIT 1 INACTIVE ******** C=ABC
$HASP530 JOBXEQ80 ON L9.ST1 65 RECORDS
$HASP534 L9.ST1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654B715)
Error messages
The following error messages can be issued by JES2 when processing the //*ROUTE XEQ JECL statement:
•$HASP6175 JOBXEQ74: Job to be transmitted has no records
•$HASP6176 JOBXEQ74: Expected JOB/NJB statement not found after //*ROUTE XEQ
•$HASP6177 JOBXEQ74: Encountered //*
//*ROUTE XEQ password management option
To implement the //*ROUTE XEQ password management option, JES2 includes a NODE statement initialization parameter JES3_LOCAL_CHK that specifies whether (Yes) or not (No) batch jobs that are routed by the //*ROUTE XEQ JECL to this node should include the JOB card that is verified on the submitting node (Yes) or not (No).
This statement, combined with the PENCRYPT parameter, provides the same functions as the JES3 PWCNTL parameter on the NJERMT statement. The JES2 settings to match the JES3 PWCNTL specifications are listed in Table 4-3.
Table 4-3 JES2 definitions to match the JES3 PWCNTL specification
|
JES3 PWCNTL parameter
|
JES2 JES3_LOCAL_CHK parameter
|
PENCRYPT parameter
|
|
LOCALCHK
|
YES
|
N/A
|
|
SENDCLR
|
NO
|
NO
|
|
SENDENC
|
NO
|
YES
|
Setting of JES3_LOCAL_CHK parameter
The setting of JES3_LOCAL_CHK parameter can be done by defining the parameter on JES2 initialization data set or by issuing the $T NODE(xxxxxxxx) command.
The command that is issued to set the JES3_LOCAL_CHK parameter to node WTSCPLX8 to activate the local check of password on submitter job by using the //*ROUTE XEQ JECL statement is shown in Example 4-21.
Example 4-21 $T NODE command used to set the JES3_LOCAL_CHK parameter
$TNODE(WTSCPLX8),JES3_LOCAL_CHK=YES
$HASP826 NODE(9) 255
$HASP826 NODE(9) NAME=WTSCPLX8,STATUS=(VIA/SC75),
$HASP826 AUTH=(DEVICE=YES,JOB=YES,NET=NO,SYSTEM=YES),
$HASP826 TRANSMIT=BOTH,RECEIVE=BOTH,HOLD=NONE,
$HASP826 PENCRYPT=NO,JES3_LOCAL_CHK=YES,
$HASP826 SIGNON=COMPAT,ADJACENT=NO,CONNECT=(NO),
$HASP826 DIRECT=NO,ENDNODE=NO,REST=0,SENTREST=ACCEPT,
$HASP826 COMPACT=0,LINE=0,LOGMODE=,LOGON=0,NETSRV=0,
$HASP826 OWNNODE=NO,PASSWORD=(VERIFY=(NOTSET),
$HASP826 SEND=(NOTSET)),PATHMGR=YES,PRIVATE=NO,
$HASP826 SUBNET=WTSCMXA,TRACE=NO
$HASP563 NODE(9) NAME=WTSCPLX8 DEFINITION HAS CHANGED 335
NODE(9) JES3_LOCAL_CHK=NO CHANGED TO JES3_LOCAL_CHK=YES
With this option in effect, when submitting a job with a //*ROUTE XEQ JECL statement and USERID and PASSWORD set in JOB card, the authentication processing occurs on submitting node and, if validated, the job submitted by using //*ROUTE XEQ is considered a trusted job by that receiving node.
If the password is incorrect in the JOB card of the submitting job, the job fails. An error message is issued that states that the user ID or password cannot be verified. The target JOB is no transmitted. A verification failed occurrence on JOBXEQ74 that was used to transmit a job by using the //*ROUTE XEQ JECL card is shown in Example 4-22.
Example 4-22 Syslog messages to job JOBXEQ74 with invalid password
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
ICH408I USER(LPRES3 ) GROUP(SYS1 ) NAME(XXXXXXXXXXXXXXXXXXX ) 339
LOGON/JOB INITIATION - INVALID PASSWORD
IRR013I VERIFICATION FAILED. INVALID PASSWORD GIVEN.
However, when the JES3_LOCAL_CHK parameter is set to NO, as shown in Example 4-23, even if an incorrect password is coded in the JOB card, this password is not validated in the submitting system and the target job is transmitted.
Example 4-23 Setting of JES3_LOCAL_CHK and PENCRYPT parameters on JES2
$TNODE(WTSCPLX8),JES3_LOCAL_CHK=NO,PENCRYPT=YES
$HASP826 NODE(9) 342
$HASP826 NODE(9) NAME=WTSCPLX8,STATUS=(VIA/SC75),
$HASP826 AUTH=(DEVICE=YES,JOB=YES,NET=NO,SYSTEM=YES),
$HASP826 TRANSMIT=BOTH,RECEIVE=BOTH,HOLD=NONE,
$HASP826 PENCRYPT=YES,JES3_LOCAL_CHK=NO,
$HASP826 SIGNON=COMPAT,ADJACENT=NO,CONNECT=(NO),
$HASP826 DIRECT=NO,ENDNODE=NO,REST=0,SENTREST=ACCEPT,
$HASP826 COMPACT=0,LINE=0,LOGMODE=,LOGON=0,NETSRV=0,
$HASP826 OWNNODE=NO,PASSWORD=(VERIFY=(NOTSET),
$HASP826 SEND=(NOTSET)),PATHMGR=YES,PRIVATE=NO,
$HASP826 SUBNET=WTSCMXA,TRACE=NO
$HASP563 NODE(9) NAME=WTSCPLX8 DEFINITION HAS CHANGED 359
NODE(9) PENCRYPT=NO CHANGED TO PENCRYPT=YES
NODE(9) JES3_LOCAL_CHK=YES CHANGED TO JES3_LOCAL_CHK=NO
The messages that are issued for the job that is submitted from SC74 system on WTSCPLX7 with a user ID and an incorrect password that were coded in the JOB card is shown in Example 4-24. No password validation is done by the submitter node and the job is successfully transmitted to the destination node.
Example 4-24 Job submitted using the //*ROUTE XEQ with JES3_LOCAL_CHK set to NO
$HASP100 JOBXEQ74 ON INTRDR ITSO REDBOOKS FROM TSU02046
LPRES3
IRR010I USERID LPRES3 IS ASSIGNED TO THIS JOB.
$HASP520 JOBXEQ80 ON L9.JT1
SE '11.51.50 JOB02061 $HASP526 JOBXEQ80 TRANSMITTED FOR EXECUTION AT
WTSCPLX8',LOGON,USER=(LPRES3)
$HASP524 L9.JT1 INACTIVE
$HASP250 JOBXEQ80 PURGED -- (JOB KEY WAS D654C4EC)
$HASP540 JOBXEQ80 ON L9.SR1 FROM *UNKNOWN AT WTSCPLX8 13 RECORDS
SE '11.51.50 JOB02061 $HASP122 JOBXEQ80 (JOB02061 FROM WTSCPLX7)
RECEIVED AT WTSCPLX8',LOGON,USER=(LPRES3)
However, the user ID that is used to submit the job is not propagated to the destination node. For this reason, the resulting job does not include a user ID that is associated to it and a security violation occurs because the user ID cannot be found in the destination node.
The Example 4-25 show the JOBLOG for the submitted job in the destination node.
Example 4-25 Job with Security Error on receiving node without user ID
J E S 2 J O B L O G -- S Y S T E M S C 8 1 -- N O D E W T S C P L X 8
11.51.50 JOB02061 ---- WEDNESDAY, 26 JUN 2019 ----
11.51.50 JOB02061 ICH408I USER( ) GROUP( ) NAME(??? )
LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED
11.51.50 JOB02061 IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND.
$HASP106 JOB DELETED BY JES2 OR CANCELLED BY OPERATOR BEFORE EXECUTION
------ JES2 JOB STATISTICS ------
9 CARDS READ
13 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
0 SYSOUT SPOOL KBYTES
0.00 MINUTES EXECUTION TIME
4.4 Privileged support
In a JES3 environment, users can reserve spool space for emergency jobs by using spool partitioning. However, it is not so easy for JES2 to implement this function because you need exits 11 and 12, as described in Appendix E, “SPOOL partitioning exits sample code” on page 233.
However, JES2 provides the privileged support function that assists the system programmer in the resolution of critical JES2 resource shortage conditions. This function reserves a certain amount of critical resources for privileged job (STC, TSU, and JOB) use. This reserved resources can then be used by privileged jobs to diagnose and correct resources shortages. Privileged jobs enter the system by using an emergency subsystem.
A small percentage of SPOOL, jobs, output elements, and BERTs are set aside for privileged jobs. This approach assures that you have enough resources to log on, perform analysis, submit jobs, and resolve the root cause of resource exhaustion. Privileged resources can be used by privileged jobs, STCs, and TSO logons only.
Consider the following points:
•Its sole purpose is to provide the possibility to analyze and solve critical resource shortages.
•Its purpose is not to run high-priority workloads.
The following resources are guarded with this privileged support:
•BERTs
•JQEs
•JOEs
•SPOOL/Tracks
You must activate this function by using the following command:
$T LIMITS,PRIV=ON
When you successfully activate the function, the following message is displayed:
$HASP1401 Privilege Resource Support activated for -- <resource type>
You receive one message for each of the resources; however, if the activation for the specific resource fails, the following message is displayed:
$HASP1403 Privilege Resource Support could not be activated for <resource type>
This failure occurs when the free elements of the resource are smaller than the minimum number required (see Table 4-4). The required free element numbers come from the default setting or from the small environment.
The required free elements for each resource in default environment are listed in Table 4-4.
Table 4-4 Privileged resources in default environment
|
Resource
|
Free required to activate
|
Number reserved for privilege
|
Maximum
|
|
BERTs
|
20,000
|
1% of free
|
756
|
|
JOEs
|
20,000
|
1% of free
|
600
|
|
JQEs
|
10,000
|
1% of free
|
300
|
|
SPOOL(TGs)
|
20,000 TGs
|
400 TGs
|
400
|
However, these requirements might be too large for small environments. In this case, you can run the following command to activate a “small environment,” which has smaller requirements:
$T LIMITS,PRIV=ON,SMALLENV=ON
The required free elements for each resource in a small environment are listed in Table 4-5.
Table 4-5 Privileged resources in small environment
|
Resource
|
Free required to activate
|
Number reserved for privilege
|
Maximum
|
|
BERTs
|
1,200
|
150
|
150
|
|
JOEs
|
600
|
60
|
60
|
|
JQEs
|
100
|
10
|
10
|
|
SPOOL(TGs)
|
380 TGs1
|
45 TGs per MAS member
|
32*45
|
1 Also required for activating SPOOL small environment, including Track Groups (TGs):
If the product of (45 TGs) X (number of MAS members) exceeds 12.5% of total free TGs, then activation cannot occur and the $HASP1403 message is issued.
If the product of (45 TGs) X (number of MAS members) exceeds 12.5% of total free TGs, then activation cannot occur and the $HASP1403 message is issued.
You can show the current LIMITS status in the default environment, as shown in Example 4-26.
Example 4-26 Sample display of privileged resources in a default environment
$DLIMITS
$HASP1490 LIMITS(1) 489
LIMITS(1)
PRIVILEGE SUPPORT IS ON
SPOOL PRIVILEGE SUPPORT IS ON
SPOOL UTILIZATION ON 11 JUN 2018 AT 16:35:25
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
39,617 80 8,889 22| 400 400
SPOOL EXHAUST: 23 JUL 2018 AT 09:02
*********************************************************
$HASP1490 LIMITS(2) 490
LIMITS(2)
PRIVILEGE SUPPORT IS ON
JQE PRIVILEGE SUPPORT IS OFF
JQE UTILIZATION ON 11 JUN 2018 AT 16:35:25
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
3,000 80 726 24| 0 0
JQE EXHAUST: 15 JUN 2018 AT 06:42
*********************************************************
$HASP1490 LIMITS(3) 491
LIMITS(3)
PRIVILEGE SUPPORT IS ON
JOE PRIVILEGE SUPPORT IS OFF
JOE UTILIZATION ON 11 JUN 2018 AT 16:35:25
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
10,000 80 1,528 15| 0 0
JOE EXHAUST: 9 JUL 2018 AT 04:37
*********************************************************
$HASP1490 LIMITS(4) 492
LIMITS(4)
PRIVILEGE SUPPORT IS ON
BERT PRIVILEGE SUPPORT IS OFF
BERT UTILIZATION ON 11 JUN 2018 AT 16:35:25
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
2,100 80 387 18| 0 0
BERT EXHAUST: 12 JUN 2018 AT 18:44
*********************************************************
You also can display the current LIMITS status in a small environment, as shown in Example 4-27.
Example 4-27 Sample display of privileged resources in a small environment
$DLIMITS
$HASP1490 LIMITS(1) 965
LIMITS(1)
PRIVILEGE SUPPORT IS ON,SMALL ENVIRONMENT IS ON
SPOOL PRIVILEGE SUPPORT IS ON
SPOOL UTILIZATION ON 13 JUN 2019 AT 11:20:56
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
39,927 80 13,428 34| 90 90
SPOOL EXHAUST: 19 AUG 2019 AT 07:51
*********************************************************
$HASP1490 LIMITS(2) 966
LIMITS(2)
PRIVILEGE SUPPORT IS ON,SMALL ENVIRONMENT IS ON
JQE PRIVILEGE SUPPORT IS ON
JQE UTILIZATION ON 13 JUN 2019 AT 11:20:56
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
2,990 80 1,380 46| 10 10
*********************************************************
$HASP1490 LIMITS(3) 967
LIMITS(3)
PRIVILEGE SUPPORT IS ON,SMALL ENVIRONMENT IS ON
JOE PRIVILEGE SUPPORT IS ON
JOE UTILIZATION ON 13 JUN 2019 AT 11:20:56
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
9,940 80 3,762 38| 60 60
*********************************************************
$HASP1490 LIMITS(4) 968
LIMITS(4)
PRIVILEGE SUPPORT IS ON,SMALL ENVIRONMENT IS ON
BERT PRIVILEGE SUPPORT IS ON
BERT UTILIZATION ON 13 JUN 2019 AT 11:20:56
---------- NON-PRIVILEGED ---------|--- PRIVILEGED --
MAXIMUM WARN% IN-USE %| MAX AVAILABLE
1,950 80 444 23| 150 150
********************************************************* 
4.5 JES2 initialization data set checker
The JES2 Initialization Data Set Checker, similar to JES3 Initialization Stream Checker, allows installations to verify their initialization data sets without starting a JES2 subsystem. The process can detect syntax errors in initialization statements and problems with settings that might prevent JES2 from starting. The checker can verify that the statements are valid for a cold or warm start.
If you are verifying parameters on a warm start, you must run the checker within a SYSPLEX with an active member of the MAS. The checker uses XCF messaging to extract information from the active MAS member to achieve the following goals:
•Verify that the parameters are valid on a warm start
•Perform more analysis of resource usage
For more information about the JES2 initialization data set checker, see Chapter 5.2.1, “Verifying the JES initialization deck” on page 95.
4.6 SMF 84 record support
JES2 provides a function to track JES2 resource usage that is similar to JES3 JMF (JES3 Measurement Facility).
With this function, JES2 automatically writes SMF 84 records for resource monitoring, if you do not disable the recording for SMF 84 in IFASMFxx.
Record type 84 contains information that is collected by JES2 or JES3 monitors. This record is intended to provide insights into what the subsystems are doing during the interval that the record represents. Each record type 84 contains a common section (with header, product, and general information portions) and a subtype section unique for each record. JES2 creates subtype 21. Subtype 21 contains resource limit and usage information.
JES2 SMF 84 records include the following sections:
•Header: No changes from JES3 header
•Product section: Same mapping that JES3 uses
•General section: Section present, but nothing is set in this section
•Data section: Subtype 21 –JES2 resource usage:
– Memory usage subsection (24-, 31-, and 64-bit areas) mapped by R84MEMJ2:
• <16M USER
• <16M SYSTEM
• >16M USER
• >16M SYSTEM
• >2G PRIVATE
– Resource usage subsection (limit, low, high, average, count over warn, and so on) reported by resource name mapped by R84RSUJ2:
• BERT
• BSCB
• BUFX
• CKVR
• CMBS
• CMDS
• ICES
• JNUM
• JOES
• JQES
• LBUF
• NHBS
• SMFB
• TBUF
• TGS
• TTAB
• VTMB
• ZJC
A 1,344-byte record is produced in each SMF interval.
Because no official formatting program exists for SMF 84 subtype 21, you must develop your own formatting program, depending on your requirements. For more information about a sample program to format SMF 84 subtype 21, see Appendix C, “Sample SMF84 Report program” on page 203. Although you can use this code as a starting point, you must thoroughly test the final code that you deploy.
4.7 Eight-character JOB CLASS and JOB CLASS GROUP support
In this section, we describe eight-character JOB CLASS and JOB CLASS GROUP support.
Eight-character JOB CLASS support
JES2 supports up to eight-character job class names, which is similar to the JES3 support. The JCL JOB card CLASS= parameter is expanded to support up to eight characters. Classes can be managed by using the $ADD/$DEL JOBCLASS command. Other commands are also updated to support eight-character job classes.
An eight-character JOB CLASS can be and assigned to an initiator, as shown in Example 4-28.
Example 4-28 Sample syslog to add and display eight characters job class
$ADD JOBCLASS(NEWADD),ACTIVE=YES
$HASP837 JOBCLASS(NEWADD) 200
$HASP837 JOBCLASS(NEWADD) ACTIVE=YES,GROUP=,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$TI(49),CLASS=(NEWADD)
$HASP892 INIT(49) 202
$HASP892 INIT(49) STATUS=INACTIVE,CLASS=(NEWADD),NAME=49,
$HASP892 ASID=0066
You can specify the eight-character JOB CLASS, as shown in Example 4-29.
Example 4-29 Sample JCL to specify 8-character job class
//JOBA JOB MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,CLASS=NEWADD
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
4.7.1 JOB CLASS GROUP support
JES2 also supports job class groups, which is similar to the JES3 support. Each job class can be in one job class group. Job class group names and job classes must be unique and you cannot have a job class group with the same name as a job class.
As shown in Example 4-30, two job classes are defined, each belonging to one job class group.
Example 4-30 Sample SYSLOG to add and display job class group
$ADD JOBCLASS(TEST1),ACTIVE=YES,GROUP=GRP1
$HASP837 JOBCLASS(TEST1) 853
$HASP837 JOBCLASS(TEST1) ACTIVE=YES,GROUP=GRP1,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$ADD JOBCLASS(TEST2),ACTIVE=YES,GROUP=GRP1
$HASP837 JOBCLASS(TEST2) 918
$HASP837 JOBCLASS(TEST2) ACTIVE=YES,GROUP=GRP1,MODE=JES,
$HASP837 QAFF=(ANY),QHELD=NO,SCHENV=,
$HASP837 XEQCOUNT=(MAXIMUM=*,CURRENT=0),
$HASP837 XEQMEMBER(SC75)=(MAXIMUM=*,
$HASP837 CURRENT=0),
$HASP837 XEQMEMBER(SC74)=(MAXIMUM=*,
$HASP837 CURRENT=0)
-------------------------------------------------------------------------------
$DCLASSGRP(GRP1)
$HASP816 CLASSGRP(GRP1) TEST2,TEST1
-------------------------------------------------------------------------------
$TI(50),CLASS=(GRP1)
$HASP892 INIT(50) 254
$HASP892 INIT(50) STATUS=INACTIVE,CLASS=(GRP1),NAME=50,
$HASP892 ASID=0065
A job class group facilitates selecting on job classes. Initiators and Offload Job Transmitters can specify 1 - 36 single character job classes or 1 - 8 multi- (or single-) character job classes or job class groups.
You can specify a job class name that is included in a job class group in the CLASS parameter of a JOB statement, as shown in Example 4-31. You cannot specify a job class group name directly in the CLASS parameter of a JOB statement.
Example 4-31 Sample JCLs to specify job class included job class group
//JOBA JOB MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,CLASS=TEST1
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
-------------------------------------------------------------------------------
//JOBB JOB MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,CLASS=TEST2
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
When an initiator that is assigned to a job class group selects a job for execution, it does so in a round-robin fashion. When a job is selected, the classes are rotated so the next selection starts with the next job class in the group.
For example, assume that you have ten jobs that specify CLASS=TEST1, and other ten jobs that specify CLASS=TEST2 in the job queue. In this example, TEST1 and TEST2 are included in a job class group GRP1. As a result, the initiator that GRP1 is assigned to select TEST1 jobs and TEST2 jobs in round-robin fashion.
The following updates were made to the CLASS= parameter in the command and initialization statement:
•CLASS=ABCD: Implies single-character job classes A, B, C, and D.
•CLASS=(ABCD): Implies four-character job class or job class group ABCD.
4.8 Interpreter after converter support
In a JES3 environment, the z/OS interpreter is called before a job is transferred to the initiator. However, in a JES2 environment, z/OS interpreter is normally called when the job is transferred to the initiator. If you want the same behavior in JES2 as you have in JES3, you can specify the following parameters:
•JOBDEF INTERPRET=JES (a parameter in the initialization statement)
•$T JOBDEF, INTERPRET=JES command
INTERPRET specifies when JES2 calls the z/OS interpreter to process a job.
With this option, the z/OS interpreter is called at the end of conversion processing. The use of this option includes the following benefits:
•Earlier detection of JCL errors that are detected by the MVS interpreter. This function allows errors to be detected, even if the job never runs f(TYPRUN=HOLD).
•Processing of JESDS OUTPUT statements to control data set attributes, even if the job never runs.
INTERPRET=JES also means that the converter and interpreter run in a JES2CI address space that is separated from a JES2 address space. Therefore, SYSZTIOT ENQ contention can be avoided between a spool offloaded allocation delay in JES2 address space and conversion JCL allocation in JES2CI address space. It is a best practice to use INTERPRET=JES.
INIT specifies to call the interpreter when the job is selected for execution by an initiator. Starting the interpreter in the initiator is the traditional JES2 processing method. This behavior is the default.
For example, the JCL that is shown in Example 4-32 immediately fails with JCL error in JES3 environment (even though TYPRUN=HOLD is requested) because the interpreter can find the error before the initiator.
Example 4-32 Sample JCL with TYPRUN=HOLD
//JOBA JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,TYPRUN=HOLD
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=XXX
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
However, in the JES2 default environment where JEBDEF INTERPRET=INIT, the job is held until released, as shown in Example 4-33. Therefore, timing for JCL error detection is much earlier in JES3.
Example 4-33 Sample job login INTERPRET=JES
14.32.52 JOB09571 ---- WEDNESDAY, 13 JUN 2018 ----
14.32.52 JOB09571 IRR010I USERID LPRES1 IS ASSIGNED TO THIS JOB.
14.43.05 JOB09571 IEF452I JOBA - JOB NOT RUN - JCL ERROR <- Held more than 10 minutes until released
14.43.05 JOB09571 $HASP396 JOBA TERMINATED
------ JES2 JOB STATISTICS ------
13 JUN 2018 JOB EXECUTION DATE
8 CARDS READ
25 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
1 SYSOUT SPOOL KBYTES
0.00 MINUTES EXECUTION TIME
1 //JOBA JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M,TYPRUN=HOLD
IEFC653I SUBSTITUTION JCL - CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=PRES1,REGION=0M,TYPRUN=HOLD
2 //STEP01 EXEC PGM=IEBGENER
3 //SYSPRINT DD SYSOUT=*
4 //SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=XXX
5 //SYSUT2 DD DUMMY
6 //SYSIN DD DUMMY
/*
STMT NO. MESSAGE
-
4 IEF643I UNIDENTIFIED POSITIONAL PARAMETER IN THE DISP FIELD
However, with JOBDEF INTERPRET=JES enabled, you can detect JCL errors in the early interpreter phase, as does JES3.
Enabling JOBDEF INTERPRET=JES requires the following conditions:
•z11 mode
•All members must be z/OS V2R1 or later
Also, specifying INTERPRET=JES causes EXIT 60 to be driven instead of EXIT 6. If you use EXIT 6, you might need to also provide similar function in EXIT 60 before setting INTERPRET=JES.
4.9 Functions similar to deadline scheduling
JES2 features two functions that are similar to JES3 deadline scheduling. The first function is a way to hold a job until a specific time. The other function is a way to move up a job’s position in the execution queue over time so that it runs before a certain time.
4.9.1 HOLDUNTL on SCHEDULE JCL statement
HOLDUNTIL= indicates a date and time (or an amount of time that the job is held) when the job can be released from hold status.
You specify a date and time when a job can be released, as shown in Example 4-34. The job is released on 16:30 on Jun. 12 2019 in this example.
Example 4-34 Sample JCL to specify HOLDUNTIL for specific date and time
//JOBZ JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID
// REGION=0M
//SCHED SCHEDULE HOLDUNTL=('16:30','2019/163')
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
Another option is to specify how long the job must be held, as shown in Example 4-35. The job is released after 30 minutes from the job submission in this example.
Example 4-35 Sample JCL to specify HOLDUNTIL for specific period
//JOBZ JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//SCHED SCHEDULE HOLDUNTL='+00:30'
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
Until a job is released, $DJ shows the status as shown in Example 4-36.
Example 4-36 Sample display for the job before release
$DJ9498
$HASP890 JOB(JOBZ) 551
$HASP890 JOB(JOBZ) STATUS=(AWAITING EXECUTION),CLASS=A,
$HASP890 PRIORITY=8,SYSAFF=(ANY),HOLD=(JOB,
$HASP890 HOLDUNTL)
4.9.2 STARTBY on SCHEDULE JCL statement
STARTBY specifies the preferred date and time that the job is selected for execution. JES2 attempts to position this job in the job queue so that the job is ready to be selected for execution at the specified time.
However, JES does not ensure that the job is selected at the specified time. The ability of the job to be selected depends on the system environment, system affinity, availability of initiators, and availability of resources, among other factors.
You specify a date and time when a job starts as shown in Example 4-37. In this example, the target date and time are 16:30, June 12, 2018.
Example 4-37 Sample JCL to specify STARTBY for specific date and time
//JOBX JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//SCHED SCHEDULE STARTBY=('16:30','2018/163')
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
Another option is to specify how long a job waits for selection, as shown in Example 4-38. The target time the job should be selected is after 30 minutes from job submission in this case.
Example 4-38 Sample JCL to specify STARTBY for specific period
//JOBX JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//SCHED SCHEDULE STARTBY='+00:30'
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
This function is not enabled by default. It must be enabled by using the following command:
$TJOBCLASS(c),PROMO_RATE=nn
Where nn specifies how many positions a job can be moved up the execution queue in one STARTBY aging cycle (1 minute=fixed value). The default value PROMO_RATE=0 means that the STARTBY function is disabled for the job class. You can also set this value in the PROMO_RATE parameter on JOBCLASS initialization statement.
4.9.3 WITH= on SCHEDULE JCL statement
In a JES3 environment, a user can control which system selects a job for execution that is based on JES3 set-up condition, without specifying the execution system. For example, if a volume is online only from one system, the job that requires the volume is automatically routed to the system.
In JES2, although the condition is not volume-online status, you can control which system can select a job for execution that is based on a specific job reference.
Use the WITH parameter to specify that the job must be run on the same system where another reference job is active. If the WITH parameter is used, the job is not eligible for execution until the reference job is active. In addition, the job can be run only on the same system where the reference job is active.
Jobs having a WITH specification can be submitted before or after the reference job is started or submitted. However, it is a best practice to submit a job after the reference job is started because the reverse sequence causes extra processor overhead.
The sample JCL that is shown in Example 4-39 specifies that JOBB must be run in the system where JOBA is running.
Example 4-39 Sample JCL to specify WITH parameter
//JOBB JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,
// REGION=0M
//SCHED SCHEDULE WITH=JOBA
//STEP01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SYS1.PARMLIB(JES3IN00),DISP=SHR
//SYSUT2 DD DUMMY
//SYSIN DD DUMMY
/*
If the referenced job (JOBA) is not yet active, the referencing job (JOBB) waits for execution, as shown in Example 4-40. When JOBA starts, JOBB automatically starts on the system JOBA is running.
Example 4-40 Sample display for the job waiting for reference job active
$DJ9543
$HASP890 JOB(JOBB) 605
$HASP890 JOB(JOBB) STATUS=(AWAITING EXECUTION),CLASS=A,
$HASP890 PRIORITY=8,SYSAFF=(ANY),HOLD=(NONE),
$HASP890 WITH=JOBA
4.10 SPOOL management
JES3 includes a spool partitioning function mainly to isolate certain types of work in a specific partition. This function can improve spool recovery by keeping critical spool data separate from noncritical data.
In a JES3 environment, it is easy to implement this functionality by using only JES3 Inish deck definitions, as shown in Example 4-41, Example 4-42, and Example 4-43. Only related parameters are described in these examples. The “SPECIAL” spool partition, which consists of SPOOL4, is reserved for CLASS=B and MSGCLASS=Y:
•Define spool partitions, as shown in Example 4-41.
Example 4-41 Define spool partition
SPART,NAME=NORMAL,DEF=YES
SPART,NAME=SPECIAL
•Assign each spool space to a defined spool partition, as shown in Example 4-42.
Example 4-42 Assign each spool space to a defined spool partition
TRACK,DDNAME=SPOOL1,SPART=NORMAL
TRACK,DDNAME=SPOOL2,SPART=NORMAL
TRACK,DDNAME=SPOOL3,SPART=NORMAL
TRACK,DDNAME=SPOOL4,SPART=SPECIAL
•Relate certain work to a specific spool partition, as shown in Example 4-43.
Example 4-43 Relate certain work to a specific spool partition
CLASS,NAME=A,SPART=NORMAL
CLASS,NAME=B,SPART=SPECIAL
SYSOUT,CLASS=X,SPART=NORMAL
SYSOUT,CLASS=Y,SPART=SPECIAL
However, JES2 does not have the same capabilities as JES3. Therefore, you must manage JES2 spool with some combination of JES2 functions.
This section describes some functions to help JES2 spool management.
SPOOL fencing
Standard JES2 processing allows all jobs to allocate track groups on all available spool volumes. Spool partitioning is a facility that is provided within JES2 that permits the specific identification of spool volumes from which a particular job or job class can allocate track groups. This facility is also referred to as spool fencing.
JES2 fences a job to an installation-defined number of volumes. In this form of fencing, the job starts with a zero spool partitioning mask work area. As the job allocates spool space, each volume that is used corresponds to a bit set in the mask. The job is forced to use volumes listed in the mask only. Minimum fencing is defined as setting the volume limit to “1”.
You also can implement SPOOL partitioning based on, for example, JOBCLASSes or JOBNAMEs, similar to JES3. The SPOOLDEF initialization statements and two installation exits, Exit 11 and Exit 12, provide methods for accessing and setting the spool partitioning mask work area.
For more information about the sample EXIT 11 and EXIT 12 to implement spool partitioning similar to JES3, see Appendix E, “SPOOL partitioning exits sample code” on page 233.
It is a best practice to use JES2 standard functions to manage JES2 spools instead of JES3 spool partitioning simulation by JES2 EXITs. This practice ensures future maintainability.
SPOOL affinity
JES2 also processes your fencing requirements based on the system affinity to those volumes.
Each spool volume includes masks of systems that can allocate space on that volume. Jobs are limited to the spool volumes associated with a system. You assign spool volumes to particular systems by using the $T SPOOL command, as shown in Example 4-44. (No initialization options are available to perform this task.)
Example 4-44 SYSLOG sample to modify spool affinity
$TSPOOL(BH5SP1),SYSAFF=SC74
$HASP893 VOLUME(BH5SP1) 211
$HASP893 VOLUME(BH5SP1) STATUS=ACTIVE,DSNAME=SYS1.HASPACE,
$HASP893 SYSAFF=(SC74),TGNUM=9975,TGINUSE=4414,
$HASP893 TRKPERTGB=5,PERCENT=44,RESERVED=NO,
$HASP893 MAPTARGET=NO
$HASP646 21.8981 PERCENT SPOOL UTILIZATION
Privileged space
This function is described in 1.3.2, “JES2 resiliency” on page 6.
Dynamic add/delete/allocate spool
You do not need to preallocate a spool data set. You can dynamically add or allocate spools in emergency situations.
SPOOL merge function
You can move data off one spool volume to another volume dynamically in emergency situations.
Dynamic expand of a spool (or checkpoint) data set
You can dynamically expand a spool or checkpoint data set into adjacent space on volumes for emergency recovery.
Reserved volumes
You can allocate JES2 spool volumes with the option RESERVED=Yes, which marks the spool volume as reserved for special processing and no new allocations are allowed. The RESERVED=No option clears the reserved attribute.
4.11 JES2 Disk Reader
Following the direction to support the main JES3 functions, JES2 includes a function that is similar to the JES3 Disk Reader that supports copying a member from a predefined concatenation of data sets to an internal reader, which passes the records in the member to JES2 input processing.
This function allows JCL to be submitted to JES2 from a concatenation without having to log on to TSO, submit a job, or run a started task.
To support this functionality on JES2, a logical concatenation of PDSs, PDSEs, and z/OS UNIX directories is used as source of members. Commands also are available that can be used to read the member and copy it to the internal reader.
Consider the following points:
•A concatenation SUBMITLIB is the source of the members.
•A statement SUBMITRDR defines defaults for the input device.
•A command $SUBMIT reads the members and passes them to JES2 INPUT processing.
4.11.1 SUBMITLIB concatenation
The SUBMITLIB concatenation is created by using the common code that is used to implement the PROCLIB concatenation that is in use by JES2. This concatenation allows for the creation of different lists of concatenated data sets or UNIX directories where the JES2 can locate JCL members then copy them to be processed by JES2 input processing (see Figure 4-2).
|
SUBMITLIB(ddname) DD(n)=(DSName=name,[VOLser=volume,UNIT=unit])
DD(n)=(PATH=pathname)
CONDitional|UNCONDitional
|
Figure 4-2 SUBMITLIB statement syntax:
These concatenated lists can be defined by the JES2 initialization data set deck or added dynamically by using the $ADD SUBMITLIB command.
Also, the $ADD, $DEL, $T, and $D commands are available on JES2 to manage SUBMITLIB concatenation.
Adding a SUBMITLIB concatenation
The $ADD SUBMITLIB command can be used to dynamically define a new SUBMITLIB data set concatenation to be used by JES2 when submitting batch jobs by using the $SUBMIT command. The concatenations can contain any combination of partitioned data sets (PDSs) or file system paths.
If a file system path is specified, files in the path must be with 1 - 8 character file names that conform to standard PDS member names and can be accessed by using the FILEDATA=TEXT allocation option (see Example 4-45).
Example 4-45 Sample of $ADD SUBMITLIB command used to define a new SUBMITLIB to JES2
$ADD SUBMITLIB(SUBLIB00),DD(01)=(DSNAME=SYS1.JES2.SUBMTLIB)
IEF196I IEF237I 9788 ALLOCATED TO $SB00006
$HASP736 SUBMITLIB(SUBLIB00) 393
$HASP736 SUBMITLIB(SUBLIB00)
$HASP736 DD(1)=(DSNAME=SYS1.JES2.SUBMTLIB,
$HASP736 VOLSER=BH5CAT)
Modifying a SUBMITLIB concatenation
The $T SUBMITLIB command is used to modify a SUBMITLIB concatenation. By using this command, new data sets can be added to a concatenation, or existing data sets can be updated or deleted from the concatenation.
If a $T SUBMITLIB command is entered with no operands, concatenation is reallocated. This feature is useful to retry a failed allocation or to pick up updates to an existing data set (for example, a data set cataloged on a new volume or a data set is expanding into new extents).
Unlike PROCLIB processing, JES2 opens and closes the SUBMITLIB concatenations for every $SUBMIT command. This ability reduces the risk of errors when data sets in the concatenation are compressed (see Example 4-46).
Example 4-46 Sample of $T SUBMIT command used to add a PATH to an existent concatenation
$T SUBMITLIB(SUBLIB00),DD(02)=(PATH='/u/jes2/submitlib/sublib00')
IEF196I IEF237I 9788 ALLOCATED TO $SB00010
IEF196I IGD103I SMS UNIX FILE ALLOCATED TO DDNAME SYS00006
IEF196I IEF285I SYS1.JES2.SUBMTLIB KEPT
IEF196I IEF285I VOL SER NOS= BH5CAT.
$HASP736 SUBMITLIB(SUBLIB00) 426
$HASP736 SUBMITLIB(SUBLIB00)
$HASP736 DD(1)=(DSNAME=SYS1.JES2.SUBMTLIB,
$HASP736 VOLSER=BH5CAT),
$HASP736 DD(2)=(PATH=/u/jes2/submitlib/subli
$HASP736 b00)
Displaying a SUBMITLIB concatenation
The $D SUBMITLIB command is used to display SUBMITLIB concatenations that are defined to JES2 to be used when a $SUBMIT command is issued to submit a job (see Example 4-47).
Example 4-47 Sample of $D SUBMITLIB command used to display a SUBMITLIB concatenation
$D SUBMITLIB(SUBLIB00)
$HASP736 SUBMITLIB(SUBLIB00) 430
$HASP736 SUBMITLIB(SUBLIB00)
$HASP736 DD(1)=(DSNAME=SYS1.JES2.SUBMTLIB,
$HASP736 VOLSER=BH5CAT),
$HASP736 DD(2)=(PATH=/u/jes2/submitlib/subli
$HASP736 b00)
Deleting a SUBMITLIB concatenation
The $DEL SUBMITLIB command is used to remove a SUBMITLIB data set concatenation that is no longer needed. After the use count for the specified SUBMITLIB goes to zero, the data sets in the concatenation are unallocated (see Example 4-48).
Example 4-48 Sample of $DEL SUBMITLIB command used to remove a SUBMITLIB concatenation
$DEL SUBMITLIB(SUBLIB00)
IEF196I IEF285I SYS1.JES2.SUBMTLIB KEPT
IEF196I IEF285I VOL SER NOS= BH5CAT.
IEF196I IGD104I UNIX FILE WAS RETAINED, DDNAME IS ( )
IEF196I FILENAME IS (/u/jes2/submitlib/sublib00)
$HASP736 SUBMITLIB(SUBLIB00) 468
$HASP736 SUBMITLIB(SUBLIB00)
$HASP736 DD(1)=(DSNAME=SYS1.JES2.SUBMTLIB,
$HASP736 VOLSER=BH5CAT),
$HASP736 DD(2)=(PATH=/u/jes2/submitlib/subli
$HASP736 b00) - ELEMENT DELETED
4.11.2 SUBMITRDR initialization statement
The SUBMITRDR statement is similar to the INTRDR statement and is used to define the characteristics of the reader that used to read the input members from SUBMITLIB concatenation and then pass this member to JES2 input processing.
The DD_DEFAULT subparameter specifies the default SUBMITLIB concatenation that is used by the $SUBMIT command (see Figure 4-3).
|
SUBMITRDR AUTH=(DEVICE=YES|NO,JOB=YES|NO,SYSTEM=YES|NO)
CLASS=jobclass,DD_DEFAULT=ddname,HOLD=YES|NO,
PRTYINC=nn,PRTYLIM=nn,SYSAFF=(affinity_list),
TRACE=YES|NO
|
Figure 4-3 SUBMITRDR statement syntax
4.11.3 $SUBMIT command
The use of the $SUBMIT command copies a member of a SUBMITLIB data set to the SUBMIT reader. The specified member of the SUBMITLIB data set is read and passed to JES2 input processing. Any valid record that can be passed to JES2 by using an internal reader can be passed to input processing by using the $SUBMIT command.
Default attributes for the submit reader can be specified on the SUBMITRDR statement.
Security for data that is passed over the submit reader is based on the issuer of the $SUBMIT command. If a user identity exists that is associated with the issuer of the command, that user is considered the submitter of the data stream. Commands and jobs are processed as if the originator of the command issued the commands or submitted the jobs.
Only one $SUBMIT command can be active on a member at a time. A second $SUBMIT command, while the first is still active, fails with a $HASP149 message, which indicates that a previous command is still active.
The existence of the default SUBMITLIB DD name is checked at the time that the $SUBMIT command is sued. If it does not exist, the $SUBMIT command fails with a $HASP665 message, which indicates that the SUBMITLIB was not found.
The use of the $SUBMIT command queues the processing to a subtask in the JES2 address space. The processing occurs asynchronous to the JES2 command processor. Error messages that are related to the member not being found or any other errors occur after the command processing completes.
Error messages that are associated with the submit command (such as the member not being found or an error reading the member) are routed back to the originating console. Normal messages that are created by input phase processing are routed by the route code, as usual (see Figure 4-4).
|
$SUBMIT DDname=name,MEMBER=member,HOLD=YES|NO
|
Figure 4-4 $SUBMIT command syntax
4.12 JES2 Multi-Job NJE Stream
JES2 lifted the restriction for a single job object in an NJE job stream. Jes2 can send a set of jobs to a node and have them processed by input processing in the correct order. This support is based on a JOBGROUP defining jobs and all the jobs that are related to the job group in one NJE job stream.
This property is enforced on existing nodes that are receiving jobs from a JES3 migrated environment that support multiple jobs that are received from an NJE node and JES2 not. This support removes the restriction of only one job allowed by NJE submission.
This feature is supported on JES2 base code and does not require any external change on current JES2 environment.
If you want to run the jobs in destination node following a specific order, you can create a package by using the JOBGROUP definition and it is grouped JOBs into one NJE transmission unit. With the definition that is shown in Example 4-49, the JOBGROUP is processed first, and therefore exists on the receiving node before the grouped JOBs are processed.
In summary, packaging all JOBs and JOBGROUPs in a single /*XMIT unit is easier to understand and can eliminate potential NJE transmission timing issues.
Example 4-49 Sample of job using Multi-Job NJE Stream with JOBGROUP definition
//JOBXMITG JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
/*XMIT WTSCPLX7 DLM=ENDXMIT
//*
//*-------------------------------------------------------------
//* JOBGROUP XMJG0001 : JOBXMITA --> JOBXMITB
//*-------------------------------------------------------------
//XMJG0001 JOBGROUP
//*
//JOBXMITB GJOB
// AFTER NAME=JOBXMITA,WHEN=(RC=0)
//*
//JOBXMITA GJOB
//*
//XMJG0001 ENDGROUP
//*------- JOB : JOBXMITA --------------------------------------
//JOBXMITA JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
// SCHEDULE JOBGROUP=XMJG0001
//STEP1 EXEC PGM=IEFBR14
//*------- JOB : JOBXMITB --------------------------------------
//JOBXMITB JOB (),'ITSO REDBOOKS',CLASS=B,MSGCLASS=X,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*
// SCHEDULE JOBGROUP=XMJG0001
//STEP1 EXEC PGM=IEFBR14
//*-------------------------------------------------------------
ENDXMIT
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.