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.