Work Management - Subsystems

The subsystem is where work is processed on the system. A subsystem is a single, predefined operating environment through which the system coordinates the work flow and resource use. The system can contain several subsystems, all operating independently of each other. Subsystems manage resources. All jobs, with the exception of system jobs, run within subsystems. Each subsystem can run unique operations. For instance, one subsystem may be set up to handle only interactive jobs, while another subsystem handles only batch jobs. Subsystems can also be designed to handle many types of work. The system allows you to decide the number of subsystems and what types of work each subsystem will handle.The run-time characteristics of a subsystem are defined in an object called a subsystem description.

The Controlling Subsystem

The controlling subsystem is the interactive subsystem that starts automatically when the system starts, and it is the subsystem through which the system operator controls the system via the system console. It is identified in the Controlling subsystem/library (QCTLSBSD) system value. IBM supplies two complete controlling subsystem descriptions: QBASE (the default controlling subsystem) and QCTL. Only one controlling subsystem can be active on the system at any time. When the system is in the restricted condition, most of the activity on the system has ended, and only one workstation is active. The system must be in this condition for commands such as Save System (SAVSYS) or Reclaim Storage (RCLSTG) to run. Some programs for diagnosing equipment problems also require the system to be in a restricted condition. To end this condition, you must start the controlling subsystem again. Note: There is also a batch restricted state in which one batch job can be active. When all of the subsystems, including the controlling subsystem are ended, a restricted condition is created. You can end each subsystem individually or you can use the ENDSBS SBS(*ALL) OPTION(*IMMED).

Note: The system cannot reach the restricted state until there is only one job remaining in the controlling subsystem. Sometimes it may appear as though there is a single job remaining, but the system does not go into the restricted state. In this case you need to verify that there are no suspended system request jobs, suspended group jobs, or disconnected jobs on the remaining active display. Use the Work with Active Jobs (WRKACTJOB) command and press F14=Include to display any suspended or disconnected jobs. If these jobs exist, you need to end them in order for the system to reach the restricted state. The ENDSYS and ENDSBS functions will send a CPI091C information message to the command issuer when this condition is detected.

Why Consider Multiple Subsystems?

As the number of users on the system increases, a single subsystem for a set of work is often insufficient. By dividing your users into multiple subsystems you gain several advantages.

1. Improved manageability of work

You get better control over what work is running in each subsystem. For example, for server jobs, you might want to isolate all of the database server jobs to one subsystem, the remote command server jobs to a different subsystem, the DDM server jobs to yet a different subsystem and so on. Additionally, by using multiple subsystems you can isolate groups of jobs with their own memory pools. In this way, one group does not adversely impact other jobs.

2. Reduced downtime impact for users

For example, if every Friday afternoon you must bring the system to the restricted state for backup purposes, you can gradually take users offline by ending one subsystem at a time.

3. Improved scalability and availability

By having a single subsystem do work for fewer users, the subsystem is less busy and can be more responsive to the work requests it handles.

4. Improved error tolerance in interactive subsystems

By spreading the work across multiple subsystems, should a network failure occur, multiple subsystems can manage the device recovery processing.

5. Improved interactive subsystem startup time

You can keep the subsystem startup times shorter by subdividing the work across multiple subsystems.

6. Additional options for performance tuning

By using multiple subsystems you can set up the subsystems with a small number of routing entries.

Subsystem Description

A subsystem description is a system object that contains information defining the characteristics of an operating environment controlled by the system. The system-recognized identifier for the object type is *SBSD. A subsystem description defines how, where, and how much work enters a subsystem, and which resources the subsystem uses to perform the work. An active subsystem takes on the simple name of the subsystem description.Subsystem description attributes are common overall system attributes. When you create a subsystem, the first step is to define the subsystem attributes.

Subsystem attributes include:

a)  The name of the subsystem description and the library where it is stored 

b)  All of the memory pool definitions that this subsystem uses A subsystem definition can have a maximum of 10 memory pool definitions specified. Included in the subsystem definition are:

– Pool definition identifier: This is the identifier inside the subsystem description, of the storage pool definition. – Size: This is the size of the storage pool expressed in KB (1K=1024 bytes) multiples and is the amount of main storage that the pool can use.

– Activity level: This is the maximum number of threads that can run at the same time in the pool.

c)  The maximum number of jobs that can be active in the subsystem at the same time v A text description of the subsystem description

d) The name and library of the signon display file that is used to show signon displays at work stations that are allocated to the subsystem

e) A subsystem library name that you can use if you want to specify a library that should be entered ahead of other libraries in the system portion of the library list (This parameter allows you to use a secondary language library.)

Also included in the subsystem description is information about authority levels to the subsystem. This information is kept by Security and is not stored with the other attributes of the subsystem description. You can view the subsystem description authority by using the Display Object Authority (DSPOBJAUT) command.