In the blog Route Db2 Requests to a Specific Subsystem, I wrote how you can use the QSYS2.SET_SERVER_SBS_ROUTING procedure to route work for database queries using the QZDASOINIT or QRWTSRVR server jobs to customized subsystems. This is a new way to route work based upon the requesting user profile that augments the other ways you can route work to subsystems.
The capability to segregate work with different subsystems is a major advantage of the IBM i operating system – it provides application isolation and allows you to control the performance characteristics in terms of CPU and memory consumption allowed by jobs in the subsystem. It also makes it easier to find and manage jobs for a specific application.
This week, I will summarize the various ways to configure work to run in specific subsystems. I don’t think I have ever since this list published in one place. And since this is a summary, the information here is brief. Please refer to linked references if you need more information.
- You can route work to subsystems using the traditional work management subsystem configuration with job queue entries, prestart job entries, workstation name/type entries, communications entries, routing entries, autostart job entries, etc…
You can configure interactive subsystems to assign users to different subsystems. The old Interactive Subsystem Configuration experience report provides a detailed example.
- For server jobs that do work on behalf of a user, specifically the IBM i Access servers, the DDM server, and the IBM i Netserver, you can route the incoming requests based upon the client IP address of the user. This configuration a server subsystem is done by using the Navigator for i Web console (there is no green screen interface). The old Subsystem Configuration experience report provides a detailed example using System i Navigator.
- You can also configure the subsystem where your FTP and SMTP requests run. By default, these TPC/IP servers runs in the QSYSWRK subsystem, but you can configure FTP or configure SMTP to run in a different subsystem.
- * You can configure the subsystem where QSQSRVR jobs run. By default, these jobs run in the QSYSWRK subsystem, however, you can configure these jobs to run in the same subsystem as the job that is requesting the work. The blog Subsystem Configuration for SQL Server Mode jobs reviews this capability, as well as the QSQSRVR Subsystem Configuration support article.
- As I wrote in the Route Db2 Requests to a Specific Subsystem post, you configure the subsystem where QZDASOINIT and QRWTSRVR requests run based upon the requesting user profile.
- You can Run an HTTP Server in its own Subsystem. If you have multiple HTTP servers, you can have each HTTP server run in its own subsystem. This support is relatively was initially provided on the 7.1 and 7.2 releases. This support is part of the base 7.2 release; for 7.1, you will need HTTP group PTF SF99368 level 30 or later.
- If you are using SSH (5733-SC1), you can configure the subsystem where the SSH daemon and its jobs run. The IBM Support article Starting the SSH Daemon in a Dedicated Subsystem Environment and the IBM Redpaper Securing Communications with OpenSSH on IBM i both review this support. (Note – although the redpaper is a bit dated, most of the information is still applicable on current releases).
* Finally, you can Change the Memory Pool in which a job runs using the Change Job Pool API. This API allows you to move an active job from one memory pool to another.
Take advantage of these ways to isolate work in subsystems to more easily manage your workloads and to make your IBM i run efficiently.
This blog post was edited to fix broken links on April 14, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.