Establishing performance objectives

Inherent in the design of your online IMS system are your performance objectives. Establishing performance objectives is a major task requiring data gathering for the IMS workload as a whole.

1. Defining user-oriented performance objectives and priorities.

   These derive from the way an end user perceives the service provided by the system. For IMS these objectives state expectations of response time as seen by the end user at the terminal.

   When response time objectives are established, they should not only reflect the time-in-system (the elapsed time from entry of a last input message segment to the first response segment), but also the expected amount of IMS and application program processing. You should consider whether to define your criteria in terms of the average, the 90th percentile, or even worst-case response time. Your choice depends on your installation's audit controls and the nature of the specific transactions.

2. Determining how performance against these objectives is measured and reported to users.
   This includes identification of systematic differences between the measured data and what the user sees. You should investigate the differences between internal (as seen by IMS) and external (as seen by the end user) measures of response time. To do this, you can use the following tools:

   • The Transaction Response report produced by the IMS Statistics Analysis utility, which gives the following data on internal response time by transaction type:
     • Longest and shortest response
     • 25th, 50th, 75th, and 90th percentiles of the response time distribution
   • Installation-written programs, which can analyze the output of the IMS Log Analysis utility. Other programs can also provide the same type of information, and are usually tailored to satisfy the installation's requirements.
3. Understanding and documenting the current workload.

   This requires breaking down the total work into categories and, for each category, developing a workload profile (generally estimates) that include:

   • Definition of the transaction category (for example, transaction type or group of transactions). The two characteristics of the category are:
     • The IMS workload, which is generally documented by transaction profile. In a well-designed IMS online system, most transactions perform a single function and have an identifiable workload profile. Later in the process, transaction types with common profiles can be amalgamated for convenience.
     • The transaction volume. In situations where the workload to be documented is already operational, a summary of transaction volumes can be obtained from the IMS Statistical Analysis utility. (The Application Accounting Report gives transaction counts within program name.) In other cases, volumes are estimated.
   • Relative priority of category, including periods during which priority changes.
   • Resource requirements of the work:
     • Physical resources managed by the operating system (real storage, DASD I/O, terminal I/O)
     • Logical resources managed by the subsystem, such as control blocks, latches, buffers, and number of regions

   To obtain a base profile of transaction resource demands, you can start IMS on a dedicated machine and execute a few transactions to accomplish initialization and buffer pool usage. Then start the IMS Monitor and measure a sample of transaction execution.

   You can use the base transaction profile to examine the transaction workload to see if it can be reduced. Such design changes result in the greatest impact, occurring before system-wide contention. You can also compare the base profile to the transaction profile in the production environment.

4. Translating the resource requirements and volume information obtained into system-oriented objectives for each work category

   This includes statements about the transaction rates to be supported (including any peak periods) and the internal response time profiles to be achieved.

5. Confirming that the system-oriented objectives are reasonable.

   After initializing the system and monitoring its operation, you need to find out if the objectives are reasonable (given the hardware available), based upon the measurements of the workload. If the measurements differ greatly from the estimates used, you must revise the workload documentation and system-oriented objectives accordingly, or tune the system.

6. Establishing performance objectives.

   Establishing performance objectives is also a necessary prerequisite to using the z/OS® Workload Manager. Much of the information gathered when you establish performance objectives can be used as input when planning for workload management.