Programming considerations

The accounting field resides in a 144-byte work area pointed to by X053ACCT in the XPL passed to the exit in register 0.
If you need to verify the existence of a JOB rather than a started task (STC) or TSO/E logon, this can be done by comparing the JCTJOBID field to a "J". The presence of a "J" indicates the existence of a JOB.
If you need to change the scheduling environment, use the JCTSCHEN field in the JCT.
The ACCTFLD parameter on the JOBDEF statement indicates whether JES2 should scan the accounting field of a JOB statement. For further details concerning the use of the ACCTFLD parameter, see z/OS JES2 Initialization and Tuning Reference
If the ACCTFLD parameter indicates that the scan should be performed, and if this exit is implemented and enabled, input processing will call your exit routine to perform the scan. If your exit routine passes a return code of 0 or 4 to JES2, input processing will call the existing HASPRSCN accounting field scan subroutine after your routine has executed. Note that if both routines are to be called, your routine should not duplicate HASPRSCN processing. For example, your routine should not set the fields in the JCT that are set by HASPRSCN. However, if your routine passes a return code of 8 or 12 to JES2, it causes JES2 to suppress execution of HASPRSCN. If the ACCTFLD parameter indicates that the scan should be performed but this exit is disabled, only HASPRSCN will be called; your exit routine is not called and is not given the opportunity to allow or suppress HASPRSCN execution. If the ACCTFLD parameter indicates that a scan should not be performed, your exit routine will not be called, even if this exit is enabled, and execution of HASPRSCN is also suppressed.
The ACCTFLD parameter on the JOBDEF statement indicates whether JES2 should cancel a job if the accounting field on the JOB statement is invalid or if a JCL syntax error has been detected during input processing. Note that your exit routine can affect this termination processing. For example, ACCTFLD=REQUIRED indicates that JES2 should scan the accounting field, the job should be canceled if the accounting field is invalid, and the job should be canceled if a JCL syntax error has been found. If you pass a return code of 8 to JES2, HASPRSCN is not called. Therefore, it cannot terminate a job with an invalid accounting field, even though ACCTFLD=REQUIRED. Also note that HASPRSCN scans the accounting field passed in X053ACCT. Therefore, if your routine alters this field, you affect HASPRSCN processing.
The specification of the ACCTFLD parameter is stored in the HCCT, in field CCTJOPTS. If your exit routine is meant to completely replace HASPRSCN, you may want to access this field for use by your algorithm.
Typically, use this exit, rather than Exit 52, to alter the JCT directly. If you use Exit 52 to alter the JCT, later processing might override your changes. The job exit mask and the spool partitioning mask are exceptions. See note 2 of Exit 52 for more information.
An 80-byte work area pointed to by X053JXWR in the XPL is available for use by your routine. If your routine requires additional work space, use the $GETMAIN macro to obtain storage, and the $FREMAIN macro to return it to the system when your routine has completed.
When passing a return code of 12, your exit routine can pass an installation-defined error message to JES2 to be added to the JCL data set rather than the standard error message. To send an error message, generate the message text in your exit routine, move it to area pointed to by X053JXWR, and set the X053XSEM bit in X053RESP to one.
Note: The standard error message, $HASP110, still appears in SYSLOG on this path, in addition to the installation-defined message. However, only the installation message will be placed in the JCL data set and no WTO will be issued for the installation-defined message unless Exit 53 issues the WTO itself.
If there is no accounting field on a JOB statement, the length passed by JES2 to the exit routine in R0 is zero.Your exit routine should take this possibility into account.
If you intend to use this exit to process nonstandard accounting field parameters, you should either suppress later execution of HASPRSCN or you should code your exit routine to delete nonstandard parameters before passing control to HASPRSCN. If you do neither, that is, if you allow HASPRSCN to receive the nonstandard parameters, it might cancel the job because of an illegal accounting field depending on how the ACCTFLD parameter on the JOBDEF statement is specified.
If you change the length of the accounting field, you must reload the length into field JRWACCTL.
There are three job class fields (JCTJCLAS, JCTCLASS, and JCTAXCLS) in the JCT. JCTJCLAS is the initial job execution class as set during input processing and used when building the JQE during that processing. JCTCLASS is the actual execution class. After input processing it contains the same value as JCTJCLAS, but it might be updated when the job executes if a $T command was used to update the job's class before execution. Therefore, JCTJCLAS and JCTCLASS could be different. JCTAXCLS is a copy of the actual execution class (JCTCLASS) that is propagated into the network JOB trailer. Do not use any exit routine to set the JCTAXCLS field.
If you intend to use an exit 53 routine to change the execution class of a job, be certain to set both the JCTJCLAS and JCTCLASS fields.
Accessing $NITs
The $NIT macro defines the characteristics of NJE nodes. The $NITs are arranged in a table that is indexed by the node number. The table of $NITs is in JES2 private storage and shadowed in a data space for use outside the JES2 address space. Installation exits can use three fields in the $NJEWORK work area to access the $NIT table. Installation exits can use these fields to access a $NIT without regard for what address space they are in.

Because these fields are in the $NJEWORK data area, you can address them using the ‘NJE’ prefix or the prefix for the device dependent work area in which the $NJEWORK is embedded. Therefore, you can address NJENITAD as JRWNITAD in the $JRW.
The following code accesses the origin node’s NIT in an NJE JOB receiver exit:
```
 USING NIT,R1               Est NIT addressability
 SPACE 1
$ARMODE ON,SYSSTATE=SET,INIT=CCTZEROS Enter AR mode
 SPACE 1
 LLGH  R1,JRWRDNOD          Get origin node number
 MH    R1,CCTNITSZ          Get NIT offset
 AL    R1,JRWNITBL          Get NIT address
 LAM   AR1,AR1,JRWNITAL     Get NIT ALET
```
Determining the device type
Most exits need to determine the type of device that they are being called under. The $NJEWORK area has copies of $DCT fields that can help identify the device. Which method you use depends on the condition that you are testing for.

The field NJEDEVTP (that corresponds to DCTDEVTP) is a one byte flag that can be used to test for classes of devices. A test of the DCTNET bit in NJEDEVTP indicates that the exit is being called under a networking device. A compare of the byte to DCTINR indicates that the exit is being called under an internal reader. See the $DCT for the meaning of the bits in DCTDEVTP.

NJEDEVID corresponds to DCTDEVID. This is a 3 byte value that can uniquely identify a device. This is more often used when knowing what specific device you are running under. See the $DCT for the meaning of the fields.
Do not issue a $GETMAIN storage request for subpool 0 (the default for $GETMAIN), or for subpool 240 or 250, which are translated to subpool 0 for authorized callers. Doing so would establish subpool 0 with an assigned key of 0, which can cause problems for a job step application that shares subpool 0 and requests subpool 0 storage, thereby obtaining the storage in key 0. To avoid this issue the exit should issue a $GETMAIN request for subpool 229 or 230, which are high private subpools intended for use by authorized functions, whereas subpools 0-127 are in low private subpools and are part of the user region.
Do not use subpool 240 or 250 when obtaining storage for this exit. Do not use 0-127, because this will determine the key of the subpool for the duration of the job step. Using these subpools might result in errors when the exit receives control for address spaces that are created with the KEEPRGN attribute.