(zos)Controller and Servant WLM classifications
Applications are deployed on a server or a cluster of servers. Each server consists of a controller and one or more servants. Each controller is started by the deployment manager, or by an MVS operator command as an MVS started tasks. Each servant is started by the Workload manager (WLM) as it is needed.
We can use transaction classes to classify client workload for WLM. Transaction classification can be based on the following WLM classification criteria:
- Server name (CN) - if the server is clustered, this value is the short name for the cluster; if the server is not clustered, this value is the value specified on the server custom property, ClusterTransitionName.
- The Server instance name (SI) - this is the short name for the server. This is usually not useful because we cannot control which server instance runs a transaction within a cluster.
- User ID assigned to the transaction (UI) Transaction class (TC) - use the transaction class mapping file for the server to assign this ID to a transaction
.
Controller classification
You should classify controllers in SYSSTC or give them a high importance and velocity goal, because contollers do some of the processing required to receive work into the system, manage the HTTP transport handler, classify the work, and do other housekeeping tasks,
Important: A step in controller start-up procedures, such as BBO7ACR, invoke the BPXBATCH program to check the service levels delivered, applied, and pending, and log the results in the /properties/service/logs/applyPTF.log file. Because the BPXBATCH program is classified according the OMVS rules, instead of inheriting the service classification of the startup procedure, on a busy system several minutes might pass before BPXBATA2 gets control. We can minimize the impact of the BPXBATCH step by changing the WLM Workload Classification Rules for OMVS work to a higher service objective. In the following example, OMVS work is assigned a EBIZ_HI service class, which has an importance of 1, and Velocity of 50.
Subsystem Type . : OMVS Description . . . E_Biz Classification Rule --------Qualifier------ -------Class-------- Action Type Name Start Service Report DEFAULTS: EBIZ_DEF ________ ____ 1 TN FTPSERVE ___ EBIZ_HI ________ ____ 1 UI OMVSKERN ___ SYSSTC ________ ____ 1 TN WSSRV* ___ EBIZ_HI RPTACR <<==
Servant classification
When a servant region starts, WLM classifies the servant region as a started task, and places it in a service class and a report class based on the classification rules specified in the WLM policy. WLM uses this service class to determine the priority of the address space. The priority of an address space determines its access to system resources during the initialization of the servant region.
Each work request that the controller region receives is associated with a WLM enclave. Each of these enclaves is then associated with a WLM service class and report class. When WLM distributes the work requests from the controller region to the various servant regions, it tries to keep all of the work requests associated with the same service class together. This grouping of requests means that the work requests processed by a given servant region are associated with enclaves that are usually associated with the same service class. If all of the enclaves are associated with the same service class, it can be said that the servant region is associated with that service class.
After the servant region is initialized and starts to receive work requests, all of the dispatch threads and non-dispatch threads, such as the Java Garbage Collection (GC) threads, are managed according to the goals associated with the WLM service class of the enclaves associated with the work requests that are executing in the servant.
All of the resources that the dispatch threads consume while an enclave is associated with those threads are reported in the report class associated with the enclave. All of the resources that the threads that are not associated with an enclave consume are reported in the report class associated with servant region started task.
Best practice: You should verify the servant classification is not higher in the service class hierarchy than more important work, such as the controller and CICS, or IMS transaction servers.bprac
WLM Classification Rules for STC-type work
Here is a simple example of the WLM Classification Rules for STC-type work that covers the controller and servant started tasks:
--------Qualifier-------- -------Class-------- Action Type Name Start Service Report DEFAULTS: OPS_DEF ________ _____ 1 TN %%DMN ___ OPS_HIGH RWSDMN _____ 1 TN T5SRV* ___ OPS_MED RT5SRV _____ 1 TN WS%%%% ___ SYSSTC RWSCTLR _____ 1 TN WS%%%%S ___ OPS_HIGH RWSSRVR
Related tasks
Classifying z/OS workload