![[z/OS]](../images/ngzos.gif)
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.
- 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 very useful because you 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 that is required to receive work into the system, manage the HTTP transport handler, classify the work, and do other housekeeping tasks,
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 that are 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 that are 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 that are 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.

WLM Classification Rules for STC-type work
--------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