Q4 from the OS/390 Expo and Performance Conference, October 1998, Atlanta:
Q: I am in goal mode and have been running fine with velocity goals for my CICS regions. Why should I switch to response time goals for CICS transactions?
A: As you have found, well-selected velocity goals with an appropriate importance can be as effective as response time goals. However, response time goals have some advantages over velocity goals:

• Velocity goals need to be reconsidered whenever a hardware upgrade is made to reflect the difference in velocities due to processor speed or number of CPs. Response time goals are based on end user requirements and would not necessarily change across an upgrade.
• CICS workloads with velocity goals will get storage protection only after a page delay problem is detected by WLM. CICS work with response time goals is assumed to be interactive and is given proactive protection to its working set, even before a page delay problem crops up. If you are storage constrained, this could be an important advantage of response time goals.
• With a response time goal, you are able to use a single reporting product like RMF to obtain meaningful measurement data for all your work, including response time averages and distributions for TSO, CICS, and other interactive work.

Q: We see a problem in goal mode for a high importance service class (e.g. CICS) with a fluctuating online workload. When the work dries up, its frames get stolen. Then when the workload resumes, there is a ramp-up period of poorer response time as the working set builds back up. Can anything be done to protect storage for such a workload?
A: This is known as the "sparse arrival" scenario. WLM would require some kind of an elongated history for this type of workload to prevent the stealing of resources during lulls in activity. This requirement will be considered in our future plans, but there are no plans to address this in the near term.

Q: I run a "standalone" CICS region where all the transactions run in the same address space. How can I treat these transactions differently in terms of their goals?
A: In either goal mode or compat mode, if you want to differentiate CICS transactions, you need to restructure your CICS application to have different types of transactions running in separate regions. In goal mode, when you set multiple CICS transaction goals for the various types of work, the most important work running in a region gives the other less important work running in the same region a "free ride". This same effect is seen in compat mode where you would set the IPS parms to meet the needs of the most important work in a region.
You could also investigate using CICS tuning parameters to treat work differently.

Q: When WLM is managing the CICS regions as server address spaces, where is the CICS CPU usage reported?
A: The CPU usage is reported in the service class of the CICS regions (either started tasks or jobs), not in the service class of the CICS transactions themselves.

Q: When I migrated my goal mode system to CICS 4.1, the CPU usage of the WLM address space increased noticeably. Why?
A: In CICS 4.1, WLM collects CICS delay samples. The sampling overhead is affected by the CICS MAXTASK setting. Check to see if this setting is higher than it needs to be.

Q: My distributed DB2 V4.1 workload ran fine in compatibility mode but when I switched to goal mode, response time became very erratic. What happened?
A: Probably you did not add classification rules for your distributed DB2 transactions to your WLM service definition. Unclassified distributed DB2 transactions are assigned to the 'SYSOTHER' service class which has a discretionary goal. Using the WLM application, you need to add a set of classification rules under the 'DDF' subsystem type and assign the distributed transactions to service classes with appropriate response time or velocity goals.

This is a consideration only for DB2 V4.1 and later because these levels identify DDF transactions to WLM. Compatibility mode performance was OK because the distributed DB2 transactions default to the performance group of the DDF address space, which is given good service.

In general, you should keep an eye on the SYSOTHER service class through RMF or other monitor. Any service accumulating in this service class indicates you have unclassified work in the system. You need to find out what it is and get it into a proper service class.

March, 1999
Q: I am in goal mode and recently installed the IBM HTTP Server for OS/390. How do I classify the enclaves created by the scalable Web server?
A: If you recently installed IBM's Web server and are classifying your scalable Web server transactions, be careful what documentation you use. In pre-OS/390 Release 7 versions of MVS Planning: Workload Management (GC28-1761), there are inaccurate descriptions for some of the classification qualifiers for Web server transactions. Use the corrected descriptions below.

For more information on Web server transaction classification, particularly how to use the Web server configuration file, see:

• Lotus Domino Go Webserver 4.6.1 Webmaster's Guide (SC31-8643) or
• Lotus Domino Go Webserver 5.0 Webmaster's Guide (SC31-8691)

For a practical example of using the classification qualifiers, see a new redbook entitled Capacity Planning for CICS Web-Enabled Applications on OS/390 (SG24-5168). This redbook will be available in hardcopy in March 1999.

Classification Qualifiers for the IWEB Subsystem Type

Userid

The Web server's userid (not the original requestor's userid). It is implemented this way because the requestor's userid is not available to the Web server at the time the transaction is classified. This probably has limited usefulness, since the userid is the same for most transactions. The default userid for the Web server is WEBSRV.

 

Subsystem Instance

The subsystem name from the application environment definition. (Note that this is identical to bytes 0-7 of the Subsystem Parameter qualifier.)

 

Subsystem Parameter

The actual format is:

Bytes	Description
0-7	Subsystem name
8	<blank>
9-23	Source IP address
24	<blank>
25-39	Target IP address
40	<blank>
41-46	Target port

Transaction Class

This is probably the most useful qualifier because of its flexibility. Transaction class is the arbitrary class name you specify in the APPLENV directive in the Web server configuration file. You can use the filtering function in the Web server to assign transactions to transaction classes based on the requested URL. Then in turn, the transaction classes can be assigned unique service classes via the WLM policy using the transaction class qualifier.

 

Transaction Name

The method name, for example, GET, HEAD, POST, PUT and DELETE.