Programming considerations

  1. Your EXIT(nnn) and LOADmod(jxxxxxxx) initialization statements for this exit must be placed in the initialization deck ahead of those initialization statements that your exit routine is to scan. The EXIT(nnn) statement must enable (STATUS=ENABLED) the exit; the $T EXIT(nnn) command cannot be used to enable (STATUS=ENABLED) the exit later since the point of processing for Exit 19 is before the time at which the command processor is made functional.
  2. Tracing for this exit is disabled because of its sequence in the initialization process.
  3. JES2 does not have a recovery environment that is established at the processing point for Exit 19 (the JES2 ESTAE processes termination, but not recover).
  4. Because Exit 19 is called early in JES2 initialization, some main task services might not be functional and some control blocks and interfaces might not be established. The JES2 dispatcher is not yet functional, so MVS protocol should be used in Exit 19 routines (WAIT rather than $WAIT, ESTAE rather than $ESTAE, and so forth).
  5. The CONSOLE statement simulated after all other parameter input is exhausted if the CONSOLE initialization option was specified is not presented to Exit 19 exit routines.
  6. Exit 19 routines might change the initialization statement that is passed or replace it by changing the address and length in the exit parameter list. They might also indicate, through a return code, that JES2 should bypass processing of the statement (perhaps because the routine has processed the statement already). Note that JES2 writes the statement (and any later diagnostics) to the log data set and hardcopy console only after return from the exit. Therefore, the exit routines might want to log the statement that is passed from JES2, for diagnostic purposes, before changing or replacing it. The $STMTLOG macro and service routine are provided to perform the logging function.
  7. Independent of the actions of the exit routine that affect the status of the statement passed, a new initialization statement might be inserted into the parameter stream by the exit routine by returning a statement address and length in the exit parameter list. The inserted statement is processed when the current statement is completely processed. Note that the current statement is not completely processed until either it is bypassed by exit 19, successfully scanned and processed by JES2, or found to be in error by JES2 and the resultant operator interaction by JES2 is complete. Since the operator interaction might involve input of multiple new initialization statements from the operator, the inserted statement might not be processed until after later calls to Exit 19. Also, when there are multiple exit 19 routines, only one routine can perform a statement insertion. For that reason, Exit 19 routines should verify that the insertion statement address and length in the exit parameter list are zero before using those fields to insert a statement.
  8. The processing that JES2 does for each statement after calling Exit 19 is performed using the JES2 $SCAN facility and a collection of tables. The tables define the parameter input allowed and how to process it. The scan might involve multiple levels of scanning, that is, parameters that have subparameters, and so on. At each level, a new table is used. Each table is composed of two tables, an installation-defined table followed by a JES2-defined table.

    By specifying installation-defined tables, an installation can implement its own initialization parameters on existing JES2 statements, or replace the JES2 definition for existing statements or parameters. Thus this function can be accomplished without implementing Exit 19, or with an implementation of Exit 19. Also, the $SCAN facility itself can be used from an Exit 19 routine to process initialization statements.

  9. Exit 19 can be loaded and called as part of the initialization data set checker. If it is, it should avoid:
    • Services that require authorization.
    • Obtaining or updating common storage.
    • Allocating or validating devices (might not be running on correct system).
    • Updating data sets associated with a running subsystem.
    • WTORs and WTOs (use $STMTLOG for WTOs).

    To determine whether it is being called as part of initialization data set checking, it can check byte $STATUS3 bit $INCHECK in the $HCT. If it is on, then the initialization data set checker is active.