Exits and the initialization data set checkers

The initialization data set checker loads all installation modules that are specified by any LOAD(xxxxxxxx) initialization statements. This allows exits to define and process any installation or vendor defined initialization statements. Because the checker is not starting a JES2 subsystem, all modules are loaded in private storage (even if the LOAD statement specifies common storage). The normal JES2 initialization exits (0, 19, and 24) are called to perform any validation processing that might be needed.

Most JES2 services are aware that the initialization data set checker is running and change their behavior. For example, $GETMAIN and $FREMAIN converts authorized subpools (including all common storage subpools) to private subpools. Processing is similar for $CPOOL. This allows most code to run without the need to know that the checker is running.

If exit code needs to know that the checker is running, then it can check:
  • $STATUS3 bit $INCHECK in the $HCT.
  • CCTFLAG0 bit CCTINCHK in the $HCCT.
  • Exit 0 is passed a Register 0 set to 12 on entry.
  • Exit 24 is passed X024COND set to X024ICHK (value of zero).
Installation and vendor code that might run during JES2 initialization should be aware that the initialization data set checker is running. When the checker is active, initialization code needs to 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).