Client Access Host Server Customization
Starting in OS/400* V4R4, Client Access connections to the host server programs over TCP/IP can be configured to run in a subsystem defined by the administrator. All of the optimized servers except the database server and file server may be defined to run in a subsystem(s) other than, or in addition to, the default.
This allows for a high degree of workload division. The number of jobs of a particular type can be limited, or restricted, for all users or a subset of users. These entries can be used to modify a clients priority, expand a client's storage pool or reject the client's request. Limitations can then be placed on the number of jobs that can be run in that subsystem or on the frequency a particular prestart job is run. This functionality can aid in controlling the systems resources or in tracking system use for accounting purposes.
Before changing the behavior of the servers, let's briefly examine how the host servers work in the default environment. The TCP/IP host servers have two components: the server daemon job and the socket server jobs. The latter are prestart jobs (or batch immediate jobs) that service requests from the clients. The former is a job that listens for incoming requests for that particular server. The server daemon job either attaches the incoming request to the appropriate prestarted socket server job, or, if no job is available, submits a batch immediate job.
As of V4R4, the customizable prestart jobs are designed to run in the new QUSRWRK subsystem. If the prestarted job isn't available for some reason (such as QUSRWRK not being started), then the daemon job will start a batch immediate job in the current subsystem. The subsystem where the daemon runs is considered the current subsystem. Since V4R4 and later releases only allow for the customization of those servers whose daemons run in QSYSWRK, the batch immediate jobs would run there.
Customizing a Subsystem
Once you've determined how the workload should be divided, you're ready to customize a subsystem to run host server jobs. First, create a new subsystem description or modify an existing one to allow the host server prestart jobs to run in this subsystem. The prestart job entries can be found on QUSRWRK (DSPSBSD QUSRWRK, option 10). These descriptions convey how the defaults were set. These values-other than the program to run and the library where it is located-can be changed as desired to specify a different user profile to start under, job description, class, etc. (The remote command prestart jobs should not use any value other than 1 for the maximum number of uses, MAXUSE, parameter.)
For information on linking programs to the types of requests they service, see Chapter 2 of the manual, "AS/400 Client Access Host Servers" (SC41-5740-03). You could even copy the QUSRWRK description and use it as a starting point. If you do this, be sure to change or remove the QUSRNOMAX job queue from the copy. This is necessary because only one subsystem at a time may allocate a job queue.
Search our new 2013 Buyer's Guide.
Administrator | IBM i integration with BladeCenter and System x helps solve Windows server woes