iCan Blog Archive

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.

  • 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 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.

* 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.