Transaction class propagation on z/OS operating systems

Service policies contain one or more transaction class definitions. The service policy creates the goal, while the job transaction class is used to connect the job to that goal. When working with z/OS resident applications, the goal defined in the service policy is only used for monitoring and reporting rather than active workload management. The transaction class also serves the purpose of providing the TCLASS value that is propagated to the request and used by Workload Manager for z/OS (WLM).

Transaction classes

Transaction classes are a subcontainer of the service policy for work being classified into the service policy that can be used for finer-grained monitoring. The relationship between service policies and transaction classes is one to many: A single service policy can have multiple transaction class definitions, but each transaction class belongs to exactly one service policy. Every service policy has a default transaction class, which in most scenarios is sufficient. Additional transaction classes are created when finer-grained monitoring is necessary for the environment. Each transaction class name must be unique within the cell.

In the batch environment each job is assigned to a job class. A job class establishes a policy for resource consumption by a set of batch jobs. If a job does not specify a job class, a default one is provided.

Service policy classification in the batch environment is controlled by a set of rules defined to the job scheduler: A rule that assigns any job to the default transaction class DEFAULT_TC.

The job scheduler evaluates the list of classification rules in order and assigns the transaction class specified by the first matching rule. Only one classification rule set per cell is supported. A default configurable transaction class, DEFAULT_TC by default, is associated with this set. If none of the classification rules match a job, then the default transaction class is applied to that job. When only a batch environment exists there is a field where you specify a transaction class name.

When a job dispatch request reaches the control region, the TCLASS is extracted from the HTTP request header and used to associate the request with a WLM for z/OS service class. An enclave is created having the indicated service class and it is dispatched using WLM to a servant region where the job is run. Queuing and prioritization to achieve service class goals is done by WLM for z/OS.

Integrating batch features in z/OS operating systems