Programming considerations

To change affinity, set the X050SAF field in the $XPL work area using the $SETAFF macro.
To allow the job to run on any member:
```
$SETAFF  REQUEST=ANY,AFFIELD=X050SAF
```
To allow the job to run on only this member:
```
$SETAFF  REQUEST=CLEAR,AFFIELD=X050SAF

$SETAFF  REQUEST=ADD,AFFIELD=X050SAF,
         ID=CCTTOQUL
```
If MVS™ submits a job through an internal reader, it can force a job's affinity to the local member. This can occur when the automatic restart manager restarts a job. The automatic restart manager expects the job to execute on a specific member, and will change the job's affinity so the job can run on that specific member, if necessary. If the automatic restart manager has changed the job's affinity, the X0501ARM flag in the XPL is on. You can test this flag and determine whether the affinity was changed. With that information, you can then decide whether to avoid changing the affinity.

To set independent mode for a job, the installation must turn on the bit X0501IND in X050FLG1.

To put jobs that start with the characters 'IND' into independent mode:

EXIT50   $ENTRY BASE=R12,SAVE=YES      Set entry point

         LTR    R10,R10                If JCT not present
         BZ     RRET                   can't check jobname

         CLC    =C'IND',JCTJNAME       Job want independent mode?
         BNE    RRET                   No, leave flags alone
         OI     X050FLG1, X0501IND     Set independent mode

RRET     $RETURN RC=0                  Return to caller

To change the priority set X050PRIO in the XPL. The priority is contained in the 4 high-order bits of X050PRIO. For example, a value of 'C0' would be a priority 12. (See z/OS JES2 Initialization and Tuning Reference for further details on setting and changing job priority.)
- To change the execution node, update X050XNOD with the half word binary value of the node. Use the $DEST macro to convert an EBCDIC node name to the internal binary representation of the node number
- To change the job class, place the new job class in X050JCLS. This is honored only if the job is a batch job, not if it is an STC or TSU job.
- The exit can influence the next phase of the job in most circumstances. Place the next phase value in X050NEXT. X050NEXT is primed with the phase that JES2 believes is the correct next phase when the exit is called. The exit can place one of these values in X050NEXT:
  $OUTPUT
  
  Job will be placed in the OUTPUT queue unless JES2 has already determined that the job should be purged. In that case, X050NEXT is ignored.
  
  $PURGE
  
  Job will be placed in the PURGE queue.
  
  Any other phase
  
  JES2 will honor the request unless it has already determined that the job should be placed in the OUTPUT or PURGE phase.
The next phase can also be set through the return code in R15. If one or both of the specifications specify PURGE; then PURGE will be the next phase. If neither specify PURGE, but one or both specify OUTPUT; then the next phase will be OUTPUT.
Extending the JCT Control Block: You can use the $JCTX macro extension service to add, expand, locate, and delete extensions to the job control table ($JCT) control block from this exit. For example, you can use these extensions to store job-related information. Extensions that are added can be SPOOLed extensions that are available to all exits that read the JCT or local extension that are available only to input processing exits (52, 53, 54, and 50) and the $QMOD exit (51). The size of SPOOLed extensions is based on the SPOOL buffer size and is less than 3k. You can have up to 8K of local extension regardless of SPOOL buffer size. For more information, see z/OS JES2 Macros.
This exit will not be taken under the following circumstances:
- The JES2 input service processor fails the job because JES2 does not identify a JOB card within the input stream.
If you need to change the scheduling environment, use the X050SENV field in the XPL.
Setting the X050AVF response bit does NOT influence the next phase of the job. To influence the next phase of the job, you must use the documented methods.
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.