What Your Subsystem Initialization Routine Can Do

One of the things that you must do to initialize your subsystem is to tell the SSI what function codes and function routines your subsystem supports. This is done by building an SSVT. The SSI provides the IEFSSVT macro to build your subsystem's SSVT. See Building the SSVT for more information.

After building your subsystem's SSVT, your subsystem initialization routine must let MVS™ know that your subsystem is active and ready to accept SSI requests.

The following are examples of other things your subsystem initialization routine can do:

It can tell MVS that your subsystem requires the services of a JES.
It can define command prefix characters for your subsystem.
It can create and anchor subsystem specific control blocks for use by its function routines.
It can specify whether the subsystem is to respond to the SETSSI command.

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

For more information, see Initializing Your Subsystem.