Why Write Your Own Subsystem?

You can extend the function of the operating system by writing and invoking your own subsystem.

Using a subsystem for an installation-defined function not provided by MVS™ requires an in-depth knowledge of procedures, problems, and goals at your installation; as well as a knowledge of MVS. You must take many things into consideration when deciding whether a subsystem is needed. Some factors to consider include:

You might have many programs that need the same functions. If you use a subsystem to supply these functions, the request is made in terms of the function needed.
You might want to take installation-specific action in response to certain events. If these events cause a broadcast SSI call, you can set up a subsystem to receive control at that time. However, if you choose to make a subsystem eligible for a broadcast request, your subsystem gets control on every request for that function. Thus, you must weigh the benefits of having the subsystem handle that function against the possible impact on performance.
The requesting program can be isolated from problems involving the subsystem.
Using subsystems to provide services allows more flexibility and compatibility. Not every change in the subsystem will require you to recompile; the interface between the requesting program and the subsystem remains the same.
You might want to use a subsystem to set up installation requirements only at initialization time. During system initialization, control passes to the subsystem initialization routines named in parmlib member IEFSSNxx. The initialization routine establishes changes defined by the installation. In this case, the initialization routine performs the function at initialization and does not set up separate function routines; the subsystem-provided programs that process the function identified by the function codes.
Note: 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.

You must decide whether you want to use this function of subsystems for this purpose. Consider that some of the control blocks built reside below 16 megabytes in common storage and, if your subsystem should fail, you may not be able to complete initialization of your system.

Do not use a subsystem to do the following:

To anchor persistent control blocks. Use the Name/Token callable services instead. Subsystems that exist only to provide an anchor degrade the performance of SSI request processing. See z/OS MVS Programming: Authorized Assembler Services Guide for more information on the Name/Token callable services.
To receive control for end-of-task and end-of-memory conditions. Use the RESMGR macro instead. Subsystems that exist only as resource managers degrade the performance of SSI request processing. See z/OS MVS Programming: Authorized Assembler Services Guide for more information on the RESMGR macro.

If you decide that you need a subsystem, see Setting Up Your Subsystem for the information necessary to accomplish that task.