Why Consider Multiple Subsystems?
OS/400* is shipped with a standard set of subsystems. Interactive users typically run in QBASE or QINTER; which one you use is determined by the controlling subsystem system value (QCTLSBSD). This article, which outlines how to set up interactive subsystems, assumes you're using QINTER as your interactive subsystem.
As the number of users on the system increases, a single interactive subsystem is often insufficient. By dividing users into multiple interactive subsystems, you gain several advantages, including the following:
- Improved manageability of the work on the system due to better intellectual control over which work is running in which subsystems. This allows you to understand the type of work being done in the various subsystems.
- The ability to disallow sets of users to access the system at certain times. For example, if every Friday afternoon you must bring the system to its restricted state for backup purposes, you can gradually take users offline by ending one subsystem at a time.
- 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.
- Improved error tolerance by spreading the work across multiple subsystems. This is particularly important for interactive subsystems. For example, if a network failure occurs and many sessions enter into device recovery, the interactive subsystem can become busy with the device recovery processing. This occurs because the subsystem job is the central job for managing device recovery. If hundreds of devices are affected by a network failure, they're recovered by the subsystem one at a time; such processing can negatively impact the ability for users to sign on or sign off the system. By splitting the users into multiple interactive subsystems, you can have more than one subsystem job manage the device recovery processing. Limiting the number of devices to 250 to 300 in one subsystem provides improved interactive subsystem availability and scalability.
- Improved interactive subsystem startup time. When an interactive subsystem is started, it attempts to allocate all of the devices defined by the workstation entries added to the subsystem description. As the number of devices increases, subsystem startup time may increase. You can keep subsystem startup times shorter by subdividing the work across multiple subsystems.
- Additional options for performance tuning. Several performance attributes, such as run priority, timeslice, default wait, maximum CPU and others are performance attributes specified in the class description. Storage pools and maximum jobs are specified on the subsystem description. You can tune performance by using multiple routing entries with appropriate classes within a single subsystem, or you can set up multiple subsystems with a few routing entries. Either way, you give more system resources to users doing business-critical work while fewer system resources are available for users doing less important work. Which approach you use depends on your requirements. The detailed information later in this article uses multiple subsystems with simpler configurations.
By splitting the users into multiple interactive subsystems, you can have more than one subsystem job manage the device recovery processing.
comments powered by