Subsystem Configuration for Prestart Jobs
Separating prestart jobs across multiple subsystems can offer several benefits.
By Dawn May08/03/2018
- 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.
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.
- 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.
- 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 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.
Dawn May is an IBM i consultant. She owns Dawn May Consulting, LLC in the Greater Boston area. Dawn is a former IBM senior technical staff member.