Operating Systems

What sort of goal should the DDF service classes use? A response time goal could certainly be appropriate if you have some knowledge of what a typical response time would be for these remote DB2 queries. The DDF rules also could apply additional qualifiers to sort the queries into a couple of different service classes with different response time goals. If you have no idea what a response time goal should be, then you also can use a velocity goal. Because enclaves are work that can be separately dispatched, WLM can collect using and delay samples for them and calculate velocity. Also, because enclaves accumulate z/OS service units, a multiperiod service class could be constructed. Period one could be a response time goal; period two could use a velocity goal. That way, the short query gets good service in period one with, say, Importance=2, and the longer query drops into period two with a lower importance and a velocity goal, such as Velocity=25, Importance=4.

The remote query is running under a goal the DDF rules assigns, so what’s the value of the STC goal we assigned earlier? This goal would relate to other activities going on inside the address space, such as interactions with the network and the z/OS communications server, as well as the interactions calling WLM to create the enclave, etc. To provide good service for your DDF work, you should assign the address space to a service class with high importance and high velocity, such as Importance 1 and Velocity 50.

If the remote call to DDF is actually to execute a DB2 stored procedure, the stored procedure also would run under the original enclave inside a WLMmanaged stored procedure address space. WLM starts this address space and classifies it into a service class using the STC rules, just as described earlier with the xxxxDIST address space. If the call to execute a stored procedure is a local call to DB2, such as a Time Sharing Option (TSO) user, batch job or CICS region, there would be no enclave in existence because those workloads don’t use enclaves. In that case, DB2 creates what’s called a dependent enclave, which takes its goal from the caller. So whether the stored procedure is running in a dependent or independent enclave, it receives its goal from the caller of the stored procedure.

The WLM-managed stored procedure address space is started using a WLM application environment. Application environments are WLM’s way of managing server address spaces. DB2 stored procedures use static application environments, which are defined as part of your service policy. They contain the name of the procedure in PROCLIB that WLM should use to start the address spaces. If a shortage of server address spaces is causing work to miss its goal, that’s WLM’s cue to start another server address space if allowed in the service policy definition.

Another user of enclaves and application environments is the WebSphere Application Server (WAS) for z/OS. WAS is a Java 2 Enterprise Edition (J2EE) run-time, where Java servlets and Enterprise JavaBeans (EJBs) are executed, typically in response to an HTTP Web request. These WAS transactions arrive at a control region address space, where WLM creates and classifies an enclave into a service class using the Component Broker (CB) subsystem rules. This should sound similar to the DDF workload discussion. The enclave transactions are then queued for execution by WLM into a servant region address space. WLM starts the servant regions using application environments (see Figure 3). This should sound familiar to the DB2 stored procedure discussion, and it is, with one exception. For WAS, WLM dynamically creates the necessary application environments as needed; you don’t statically define them in your service policy.

The WAS transactions (servlets, EJBs) execute under an enclave SRB inside the servant region address spaces, using a service class goal that was assigned using the CB classification rules. The WAS address spaces are all started tasks, and need to be assigned to appropriate started task service classes with velocity goals using the STC rules. The first choice for the WAS transactions should be response time goals, though velocity goals also will work.

The IBM HTTP server running on z/OS also can be configured to use enclaves. The HTTP requests would each be classified into a service class using the IWEB subsystem rules, and typically assigned a response time goal. The HTTP server address space is a z/OS started task, and would be assigned to a service class with a velocity goal under the STC rules. The use of enclaves by the HTTP server is optional, and is determined by several directives coded in the httpd.conf configuration file of the HTTP server.

WLM service class performance and resource utilization is reported in SMF 72 records, and can be formatted into the Resource Measurement Facility (RMF) workload activity report using the RMF postprocessor. Enclave service classes also create SMF 72 records and RMF workload activity reports. You can tell that a service class is using enclaves by looking at the AVG ENC field under the transactions column (see Figure 4). This field shows the average number of enclaves that were running in a service class during the RMF reporting interval. If the only kind of work running in the service class was enclave work (the proper way to configure a service class), then the AVG field (average number of transactions running in the service class) should equal the AVG ENC field. Note also that enclave work only accumulates CPU service units, and doesn’t report page-in rates or storage. The goal achievement for the enclave service class period is reported as it’s for all service class periods.

Now let’s turn our attention to CICS and IMS. The first basic principle is the same as we’ve already discussed; that is, the CICS and IMS address spaces are z/OS started tasks, and will be assigned to a started task service class with a velocity goal using the STC rules. The difference is that CICS and IMS don’t use enclaves. CICS and IMS transactions aren’t separately manageable pieces of work to z/OS and WLM. So when a CICS or IMS transaction enters the server address space, it basically disappears to WLM. Yet we’re able to assign response time goals to CICS and IMS transactions using the CICS subsystem rules and the IMS subsystem rules. So how can WLM help a CICS or IMS transaction that’s not meeting its goal? The only thing WLM can do is help the address spaces and hope it helps the transactions inside.

WLM accomplishes this through what’s called a performance block. This is a token that flows with the transaction, collecting response time and state data as the transaction flows through multiple address spaces, such as a CICS Terminal-Owning Region (TOR) and Application-Owning Region (AOR). WLM samples the performance block to discover the response time recorded and which server address spaces were part of the transactional flow. If the response time goal is being missed, WLM can then explore whether helping one or more of the server address spaces would appear to help the transactions inside.

The observant reader might notice that at this point we appear to have a conflict, since the CICS or IMS address space has a velocity goal from the STC rules, and now it seems to be managed to the response time goals of the transactions inside. The velocity goal is now in place while the address space is initializing. Then, as soon as the transactions start to flow, the velocity goal is ignored and the address spaces are managed to the goals of the transactions inside. Of course, since the CICS and IMS transactions aren’t units of work to z/OS dispatches, velocity goals won’t work and are’t allowed for the transactional service class.

The use of CICS and IMS transactional response time goals to manage the server address spaces is optional. You could choose to simply use the velocity goals assigned via the STC or JES rules, and not bother with the added complexity of using the CICS and IMS rules to assign service classes with response time goals. This choice is specified on the STC or JES classification screen in the service policy dialogs, under the “MANAGE REGION USING GOALS OF…” column. If you choose to create service classes for your CICS or IMS transactions, then response time and other transactional data is available in SMF 72 records and in RMF workload activity reports.

You also might have a WebSphere MQ workload on your system, including some MQ server address spaces. These are, of course, z/OS started tasks, and are classified using the STC rules. WLM contains a set of classification rules for an MQ subsystem. The MQ rules were put in place a few years ago for one specific product called MQ Workflow. The MQ rules don’t apply to typical MQ messaging. WLM doesn’t manage individual MQ messages. WLM only manages the WebSphere MQ servers under the STC rules.

Finally, what about UNIX System Services (USS) daemons? If a USS daemon begins its life as a z/OS started task, then it’s classified under the STC rules and given a velocity goal. If a UNIX process creates a new process through a fork or non-local spawn, that new process runs in a new address space called a BPXAS address space. That new address space needs to be classified and assigned to a service class. That classification happens using the OMVS subsystem rules. A good example is File Transfer Protocol (FTP). The original FTP daemon is a z/OS started task, and is classified using the STC rules. FTP requests handled by the FTP daemon are forked into a new process in a BPXAS address space, which would be classified using the OMVS rules to assign a service class. So, the definition of OMVS subsystem work, to WLM, would be forked processes running in BPXAS address spaces.


So, let’s summarize the WLM classification process for transactions and servers. The STC rules are used to assign service classes with velocity goals to all the z/OS started task servers. The DDF rules classify the enclaves created for remote DB2 queries. DB2 stored procedures run in enclaves, which get their goal from their caller. WAS transactions also run in enclaves that are classified using the CB rules. HTTP server enclaves use the IWEB rules. WLM can start stored procedure address spaces and WAS servant regions using application environments. CICS and IMS transactions don’t use enclaves, but can have response time goals assigned using the CICS and IMS subsystem rules, which are then used to manage the server address spaces. OMVS rules are used to manage UNIX-forked child processes.

Make sure your current WLM service policy is using the proper classification rules and appropriate service class definitions to manage the variety of transactions and servers running on your z/OS system today. Good luck! Z z

2 Pages