Classify HTTP requests for WLM (z/OS operating systems)
Classify HTTP requests for workload management (WLM) by first enabling WLM support in IBM HTTP server. Then, map HTTP requests to one or more WLM transaction classes.
Before you begin
- Have an understanding of workload management on the z/OS operating system, including goal achievement, throughput, response time, and turnaround time. Read the topic about what workload management is and the topic about managing workloads on the z/OS® operating system.
- Install and configure IBM HTTP Server.
- Authorize the user ID that the IBM HTTP Server runs under to the BPX.WLMSERVER RACF® resource in the FACILITY class. Give the user ID at least READ access.
Note: Any CGI runs in a separate address space from that of the requester and cannot inherit the transaction class of the parent request. The enclave information on the original request cannot propagate to the child address space. The WLM directives that allow you to classify requests in IHS do not work for CGIs and are not supported.
About this task
First, enable WLM support. Then, map HTTP requests to one or more WLM transaction classes. There are various ways to map HTTP requests. Three examples are provided.Procedure
- Enable WLM support by loading the mod_wlm module into the server.
Append the following statement to the httpd.conf
file:
LoadModule wlm_module modules/mod_wlm.so
- Map HTTP requests to one or more WLM transaction classes.
We can map the HTTP requests in various ways. This step provides three example substeps.
To classify your requests, add directives to the httpd.conf file.
In all the examples, the value of the wlmSubSysType directive corresponds to a subsystem type defined in WLM. This example uses CB, since CB is defined in WLM and is reserved for WebSphere® Application server. This directive can occur in the httpd.conf file only once. The scope is global only. The directive cannot exist within any other directives.
wlmSubSysType CB
- Map all HTTP requests to one WLM transaction class.
Applying all HTTP requests to one WLM transaction class is the simplest approach. The collection name of IHS corresponds to the collection name defined in the Name heading Qualifier part of the WLM ISPF panels. All the HTTP requests run in a WLM enclave associated with the WLM transaction class of IHSDEFLT.
wlmSubSysType CB wlmCollectionName IHS wlmTranClass IHSDEFLT
- Map two applications to two WLM transaction classes.
We can assign different WLM transaction classes to requests for different applications.
A virtual host is defined to port 9080. Two LocationMatch directives are defined, one for requests for the appABC application, and one for requests for the appXYZ application. Within each LocationMatch directive, the wlmTranClass directive is defined with different WLM transaction class names.
HTTP requests for the appABC application run in WLM enclaves associated with the IHSABCG1 WLM transaction class. HTTP requests for the appXYZ application run in WLM enclaves associated with the IHSXYZG1 WLM transaction class. Other requests are mapped to IHSDEFLT.
<VirtualHost *:9080> ServerName example.com wlmSubSysType CB wlmCollectionName IHS wlmTranClass IHSDEFLT <VirtualHost *:9080> <LocationMatch "/wlmSample/appABC/(extra|special)/data"> wlmTranClass IHSABCG1 </LocationMatch> <LocationMatch "/wlmSample/appXYZ/(extra|special)/data"> wlmTranClass IHSXYZG1 </LocationMatch> </VirtualHost>
- Map requests for a specific domain to WLM transaction classes.
We can assign different WLM transaction classes to requests that apply to a specific domain name and application.
A virtual host is defined to port 9080. Only HTTP requests that have a domain name of example.com can have a WLM transaction class assigned because the ServerName directive limits the requests to the domain name of example.com.
One LocationMatch directive is defined for requests for the appABC application. Within the LocationMatch directive, the wlmCollectionName and wlmTranClass directives are defined. Requests for the appABC application run in WLM enclaves associated with the IHSABCP1WLM transaction class.
A wlmCollectionName directive and a wlmTranClass directive are also defined outside the LocationMatch directive. Any requests that have a domain name of example.com in the URL but are not for the appABC application run in WLM enclaves associated with the WLM transaction class of IHSWSCG1. The IHSWSCG1 WLM transaction class has no corresponding WLM collection name. Thus, the wlmCollectionName directive is set to NA. A value of NA tells the IBM HTTP Server WLM module to not set any WLM collection name when creating the enclave.
wlmSubSysType CB <VirtualHost *:9080> ServerName example.com <LocationMatch "/wlmSample/appABC"> wlmCollectionName IHSMGT wlmTranClass IHSABCP1 </LocationMatch> wlmCollectionName NA wlmTranClass IHSWSCG1 </VirtualHost>
- Map all HTTP requests to one WLM transaction class.
- Workload management (WLM) directives for IBM HTTP Server
Use the wlmSubSysType, wlmCollectionName, and wlmTranClass directives to classify HTTP requests for workload management (WLM).
Related concepts
Related tasks
- Perform required z/OS system configurations
- Start and stop IBM HTTP Server
- Configure IBM HTTP Server
- Enable IBM HTTP Server for FastCGI applications
- Manage IBM HTTP Server remotely with the WebSphere Application Server administrative console
- Extending IBM HTTP Server functionality with third-party plug-in modules
- Configure IBM HTTP Server for SMF recording
- Install and configure IBM HTTP Server on the z/OS V2R2 system
Related
- What is workload management?
- Manage Workloads in z/OS
- Workload management (WLM) directives for IBM HTTP Server