Coding the Initialization Routine

Before coding your initialization routine, consider:

You can set up a control block structure for your subsystem by building a control block to hold any necessary information and anchoring that control block with the put/get function of the IEFSSI macro. See Storing Subsystem-specific Information and Retrieving Subsystem-specific Information for more information on the put/get function of the IEFSSI macro. If, for example, you are planning to use cross memory, your subsystem control block can point to your PC table.
If you have chosen to have your subsystem run in a separate address space, do not activate the subsystem until the address space is started unless you have made some other provisions for handling requests.
When you initialize your subsystem with the START command, you must consider whether you want to start your subsystem:
- Under the job entry subsystem (JES)
- Under the master subsystem.
If the operator specifies the SUB=keyword on the START command, the system uses the subsystem that the operator specifies.

If the operator does not specify the SUB=keyword on the START command, the system defaults to the subsystem that is specified on the REQDSUB parameter of the options function of the IEFSSI macro, or to the MSTR subsystem, if the operator does not specify the REQDSUB parameter of the options function or does not use the options function at all. See Defining Subsystem Options for more information on the options function of the IEFSSI macro.
If you have chosen to have your subsystem initializations run in parallel, update the IEFSSNxx parmlib member to include the BEGINPARALLEL keyword. Remember that all initialization routines specified before the BEGINPARALLEL keyword are invoked serially and all routines specified after the BEGINPARALLEL keyword are invoked in parallel. The BEGINPARALLEL keyword must be specified after the SMS entry.
Your initialization routine determines whether the subsystem can respond to the SETSSI command by using the options function of the IEFSSI macro. See z/OS MVS System Commands for more information on the SETSSI command.
Your initialization routine must be reentrant if it is used by multiple instances of your subsystem, and must reside in a library specified by LNKLST or LPA.
Your initialization routine must be APF-authorized.
Your initialization routine is entered in key 0 and supervisor state.
Your initialization routine can have any addressing mode (AMODE) and any residency mode (RMODE).
Your initialization routine should issue messages to explain unsuccessful processing using the console information passed in the JSIPL parameter list.
Your initialization routine should use standard linkage conventions.
Your initialization routine can define command prefix characters for your subsystem.
IBM® recommends that you use the command prefix facility (CPF) to register your valid command prefix characters. CPF is described in z/OS MVS Programming: Authorized Assembler Services Guide.
The environment your initialization routine runs in depends upon the way your subsystem is defined. If your subsystem is defined by:
- The keyword format of the IEFSSNxx parmlib member, your initialization routine runs in the master scheduler address space, under a permanent task if you are doing serial processing.
- The SETSSI command, your initialization routine runs in the master scheduler address space, under a transient task.
- The IEFSSI macro, your initialization routine runs in the address space and under the task of the issuer of the IEFSSI macro.
Prior to z/OS® V1R12, the subsystem initialization routines specified in parmlib member IEFSSNxx were invoked in the sequence they appeared and under a task that never terminated. From z/OS V1R12, the initialization routines are invoked in parallel after the BEGINPARALLEL keyword in parmlib member IEFSSNxx is processed, and no longer run under a permanent task when they are run in parallel. Because of this, you should examine your subsystem initialization routines to see if they allocate resources that will be freed at task termination when previously the resources would have remain held. Resources to consider:
- Data spaces created, but not deleted (particularly CADS)
- Task-related storage obtained, but not released
- ENQ obtained, but not DEQ'd
- ALESERV ADD without DELETE
- ESTAE CREATE without DELETE
- Joining XCF groups without leaving
- Connections to Coupling Facility structures obtained, but not released
- Task-level Name/Tokens created without deleting

Example 1 — Subsystem Initialization Routine (TSYSINIT) shows a coding example of a sample initialization routine.