IBM i Subsystems
IBM i Subsystems are used to control jobs and functions. A subsystem description defines how, where, and how much work enters a subsystem, and which resources the subsystem uses to do the work.
IBM i is shipped with a standard set of subsystems
The following subsystems are necessary for supporting user work:
- QBASE or QCTL
- QINTER
- QCMN
- QSYSWRK
- QSERVER
- QUSRWRK
Interactive users typically run in QBASE or QINTER; which one you use is determined by the controlling subsystem system value (QCTLSBSD).
Server jobs run in QSYSWRK, QUSRWRK, and QSERVER.
The daemon jobs (the server jobs that route work requests to waiting prestart jobs) typically run in QSYSWRK and QSERVER, while the prestart server jobs that perform work on behalf of users typically run in QUSRWRK, although some of the prestart jobs also run in QSERVER.
The server jobs are configured to run in thse different subsystems, depending on their function.
Let’s look at the subsystems used for server jobs.
QSYSWRK
All of the daemon jobs (with the exception of the file server daemon job and the database server daemon job) run in this subsystem. The file server and database server daemon jobs run in the QSERVER subsystem.
QUSRWRK
This subsystem is where the server jobs run for these servers:
- Network Print
- Remote command and program call
- Central
- Data Queue
- Signon
- Database
Why would we create our own subsystems?
As the number of users on the system increases, a single subsystem for a set of work is often insufficient.
By dividing users into multiple subsystems, we gain several advantages from easier viewing of grouped processes to fine tuning memory allocation and performance based on each application.
Improved manageability of the work on the system due to better intellectual control over what work is running in what subsystems. For server jobs, we may 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, etc.
This allows us to easily identify of the type of work being done in various subsystems.
Another huge benefit is gaining the ability to block sets of users (or webservices) from system access at certain periods of time. For example, if every Friday afternoon we bring the system to the restricted state for backup purposes, you can gradually take users offline by ending one subsystem at a time.
Modular Subsystems improve 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 manages.
Modular Subsystems improve 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 very busy with the device recovery processing. This is because the subsystem job is the central job for managing device recovery.
If hundreds of devices are affected by a network failure, they are recovered by the subsystem a few 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, we can have more than one subsystem job manage the device recovery processing.
Limiting the number of devices in one subsystem supplies improved availability and scalability of the interactive subsystem.
Modular Subsystems improve interactive subsystem startup time — When an interactive subsystem is started, it tries to allocate all the devices defined by the workstation entries added to the subsystem description. As the number of devices increases, subsystem startup time may increase. We can keep subsystem startup times shorter by subdividing the work across multiple subsystems.
Modular Subsystems provides added options for performance tuning — Several performance attributes, such as run priority, time slice, 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.
We can tune performance by using multiple routing entries with appropriate classes within a single subsystem, or we can simply set up multiple subsystems with a small number of routing entries.
Either way, we give more system resources to users doing business critical work while fewer system resources are available for users doing work that is less important.
Interesting read and definitely something we should be introducing, I think, like a lot of companies modernising, there’s a bit of fear factor of breaking it or negatively impacting.