(ZOS) Address space management for work requests
The product propagates the performance context of work requests using workload management (WLM) enclaves. Each transaction has its own enclave and is managed according to its service class.
The controller of a server, which workload management views as a queue manager, uses the enclave associated with a client request to manage the priority of the work. If the work has a high priority, workload management can direct the work to a high-priority servant in the server. If the work has a low priority, workload management can direct the work to a low-priority servant. The effect is to partition the work according to priority within the same server.
Enclaves can originate in several ways:
- The product uses its own set of rules to create an enclave for a client request from the network.
- Some subsystems, such as the IBM HTTP Sever, create enclaves and pass them to the application server, which, in turn, passes the enclaves on.
- The product treats batch jobs as if they were remote clients.
To communicate the performance context to workload management, we must classify the workloads in the system according to the following work qualifiers.
| Work qualifier abbreviation | Work qualifier | Corresponding product entity |
|---|---|---|
| CN | Collection name | Cluster name |
| UI | User ID | User ID under which work is running |
For more information about classification rules and workload qualifiers, refer to the topic Classifying z/OS workload and the z/OS publication z/OS MVS™ Planning: Workload Management.
In addition to client workloads, consider the performance of the product run-time servers and the business application servers. In general, server controllers act as work routers, so they must have high priority. Because workload management starts and stops servants dynamically, servants also need high priority to be initialized quickly. After the servants are initialized, they run work according to the priority of the client enclave, so the servant priority that we assign has no significance after initialization.
In summary, use the following table to set the performance goals for each class:
| If we are classifying the ... | ... assign it to: | Explanation |
|---|---|---|
| Location service daemon | SYSSTC or a high velocity, high importance STC | The system treats it as a started task, and it must route work requests quickly. |
| Controller | SYSSTC or a high velocity, high importance STC | A controller must route work quickly, but we must balance the priority of our business application server with other work in the system. |
| Servant | A lower velocity and importance STC than the controller | The servant should be assigned a lower goal
than the controller because the servant is less important than the controller.
This goal only applies during servant startup. After a server starts processing requests, it is managed according to the goals of the work being processed in the servant. |
| Application environment | Use the CB classification rules, the percentage response time goal, for example 80% of transactions complete in .25 seconds. | |
| Client applications | Assuming a long-running application, a velocity goal should be used that is relative to other work on the system. |