Subsystem Configuration for Prestart Jobs

Separating prestart jobs across multiple subsystems can offer several benefits.

As I wrote in IBM i System Supplied Prestart Job Entries, PJEs are associated with a specific subsystem, generally QSYSWRK, QUSRWRK, and QSERVER.

The default configuration works well for small environments, but as the number of in-use prestart jobs increases, you should consider using subsystems to segregate workloads. This is most important for the host servers (particularly the database server) and the SQL server mode jobs, where large environments could have hundreds, or even thousands, of in-use prestart jobs.

Why should you consider a more complex subsystem configuration than the default? Separating prestart jobs across multiple subsystems can offer several benefits, the most important being:

• The ability to control access to the system. You can end a subsystem to prevent users from connecting to the system, while allowing other users or applications to run.
• Improved manageability. Splitting large workloads into smaller groups can make it easier to understand what applications are using what system resources. 
• Performance management. Subsystems are central to supporting multiple workloads and provide the mechanism to give more system resources to critical applications while limiting the resources to less important workloads. Taking advantage of subsystems for prestart jobs is a natural fit for improved performance management.

Before configuring multiple subsystems for your prestart jobs, you need to have a strategy for how to separate the work. How do you want to organize your prestart jobs across subsystems? Should it be by requesting workload or application? User profiles? Clients in the network? Types of prestart jobs? Or other options that may be unique in your environment?  

Once you determine how you will set up your subsystems, you must create the subsystem description, job queue, job queue entries and prestart job entries for your new subsystem(s). I won’t cover those details—refer to the documentation in Configuring a server subsystem.

The options below review how you can route work for prestart jobs and may influence your strategy for your subsystem configuration.

Host Servers, the NetServer, and the DDM/DRDA Server

This set of prestart jobs support similar subsystem configuration capabilities. 

• Default.
  The prestart jobs run in the subsystem as shipped with the OS. This works well for small environments, but as users and workload increase, you’ll want to consider moving away from the default configuration.
• Route work by client IP address.
  The ability to route work based upon the client IP address has been available for many releases. This configuration is done using Navigator for i: Network –> Servers –> IBM i Access Servers for the host servers, or Network –> Servers –> TCP/IP Servers for the NetServer and the DDM/DRDA server.

You have two choices for how you configure work to be routed by client IP address:

• All Clients
  This option is simple: All requests for the server go to the specified subsystem. This makes is easy to move all of the work for a specific server type to its own subsystem.
• Specific Clients
  In this configuration, the work requests go to different subsystems based upon the client’s remote IP address; this allows you to segregate the workload based upon your network configuration. The biggest drawback with this approach is if you have a two-tier environment where all requests come to your IBM i from the same IP address.

Regardless of which of these two options you take, you have the ability to define the alternate action, i.e., what happens if the specified subsystem is not active. You can either reject the request (my recommendation), or have the requests started in the current subsystem where the daemon job is running, which would be either QSERVER or QSYSWRK.  I don’t recommend this second option.

• Route work by requesting user profile.
  This is a relatively new feature (introduced in 2015) that allows you to route the work request by user profile, which could be a group or a supplemental group profile. Once you have your subsystem configured, you use the IBM i service  QSYS2.SET_SERVER_SBS_ROUTING procedure to configure, by user profile, the subsystem for the server job. The SET_SERVER_SBS_ROUTING service has an optional parameter, ROLLOVER, which allows you to specify the action taken if the subsystem is not active; the default is to route the request to the default subsystem (e.g., QUSRWRK). I’d recommend setting ROLLOVER to NO so that if the subsystem is not active, the request is rejected.

The QSYS2.SERVER_SBS_ROUTING service allows you to review your configuration.

Note that the IBM i NetServer isn’t supported for routing work by user profile; you’re limited to routing work by the client IP address. Also note that the secure host servers don’t support routing work by user profile. 

If you set up a configuration that routes work by both client IP address and the user profile, the IP address configuration takes precedence.

QSQSRVR Jobs

SQL Server Mode is used by applications to run SQL requests in separate jobs; the QSQSRVR jobs run in QSYSWRK by default. I’ve previously written on this topic in Subsystem Configuration for SQL Server Mode Jobs. 

• Default. 
  The jobs run in QSYSWRK. I don’t understand why these jobs were put in QSYSWRK since they run user requests, but that’s just my opinion. I recommend you have a strategy to run these jobs in some other subsystem.
• Run in the same subsystem as the requesting application. 
  This option provides the easiest solution—all you need to do is create an environment variable named QIBM_SRVRMODE_SBS with a value of *SAME—and all SQL Server mode requests will run in the same subsystem as the requesting application. 
• Run in a specific subsystem.
  Enable more granular capabilities by using JDBC driver connection properties servermode subsystem parameter or CLI connection attributes with SQLSetConnectAttr() SQL_ATTR_SERVERMODE_SUBSYSTEM parameter.
  For either of these parameters, *SAME will run the QSQSRVR jobs in the same subsystem as the requesting job; however, you can specify a subsystem name to have the QSQSRVR jobs run in a specific subsystem.

If a prestart job entry does not exist for QSQSRVR within the subsystem, the QSQSRVR job will utilize a Batch Immediate job (BCI) instead of a Prestart job (PJ); BCI jobs incur the overhead of starting the job to handle the request, so it’s wise to ensure you have your prestart job entries added.

---