 |
home | |
about us | |
contact us | |
|
|
|
|||||||||
|
|||||||||||
|
|
||||||||||
|
|
|
|||||||||
|
 |
|
||||||||
|
Chicago-Soft
|
Setting and Reporting TSO Service Levels by Cheryl Watson This article is reprinted with permission from Cheryl Watson's Tuning Letter, (c) Watson & Walker, Inc. The first part of the article appeared in our last issue. RESPONSE TIME USING
RMF Figure 4 shows a simple graph of all three indicators: average response time, standard deviation, and volume (transactions per minute). Notice the straight lines showing objectives of .5 seconds response time and 1.5 transactions per second. In this example, the only times that response times were exceeded occurred when the rate exceeded its objective. Some sites prefer to use the total number of transactions instead of the transaction rate. You can get the rate by dividing the number of transactions by the RMF duration. In Figure 2, the duration was 15 minutes (900 seconds), so the rate of first period TSO was 1.48 transactions per second (1335 / 900). Figure 2.
Workload Data
* PERFORMANCE * ... AVERAGE ABSORPTION, ... AVERAGE ENDED AVG TRANS
GROUP GROUP AVG TRX SERV RATE, TRANS, TRANS, TIME/ STD DEV
NUMBER PERIOD WORKLOAD LEVEL MPL #SWAPS HHH.MM.SS.TTT
002 1 ABSRPTN = 2,171 .41 1335 000.00.01.824
TRX SERV= 1,765 .33 1841 000.00.03.669
002 2 ABSRPTN = 1,223 .07 73 000.00.07.123
TRX SERV= 1,222 .07 76 000.00.02.948
002 3 ABSRPTN = 926 .07 13 000.00.12.283
TRX SERV= 926 .07 13 000.00.09.291
002 ALL ABSRPTN = 1,833 .56 1421 000.00.02.192
TRX SERV= 1,582 .48 1930 000.00.04.015
Set objectives for average response time and transaction volume (either rate or total) for first and second period TSO, as well as an objective for the percent of transactions completing in period 1. Track response time, transaction volume, standard deviation, and percents for all periods. On the plots, indicate the objective that you’ve set. Initially, all service levels should be considered internal working documents so they can be adjusted as you’re becoming more familiar with the level of service that users are getting. The next steps in setting TSO service levels are to determine end-user response time and to obtain agreement from the customer. Those two topics are too complicated and take too much time for a quick answer here. LOAD
Figure 5 RMF CPU Activity Number of ASIDS Type MIN Max AVG ---- ----- ----- ------ ... TSO 76 92 83.6 AVAILABILITY
You can also use some RMF data to come close to determining the same information. Assume that your prime shift is 8:00 am to 4:00 pm and you want TSO to be available during that period. (Unless it’s a very unusual shop, you should only use prime time for availability, not nighttimes - how many users care if the system was down at 4 am?) Simply add the RMF duration from a type 70 record (CPU activity) for the period between 8 and 4. If MVS was available during the period, the total duration should be 8 hours. If it’s less, then the system was down. Of course, that doesn’t mean that TSO is available. You could consider putting the TSO started task (terminal monitor program) in a separate performance group and add the duration when there was something in the performance group. That duration should also total 8 hours. I know, I know, that still doesn’t mean that TSO is alive and available. Well, unless you want to go to considerably more effort, this is as close as MVS comes to providing the information. TSO/MON OBJECTIVES
Figure 6.
TSO/MON Summary Report (Courtesy of LEGENT, © LEGENT, All rights reserved)
LEGENT PRODUCTION SYSTEM
T S O / M O N VERSION 5.3
TSO SUMMARY FOR SYSTEM(SYSA)
CURRENT DATE/TIME: WED JAN 22 1992 (92.022)/14:33 ZONE: PRIME TIME
OPTIONS: SUMMARY=(APPLICATIONS,SHORT=(.25,.50),MEDIUM=(1,2),LONG=(5,10),
MONTH=*,BASE=*-1)
**************************************************************************************************************************
* * DECEMBER * NOVEMBER * OCTOBER * SEPTEMBER * PERCENT CHANGE *
* MANAGEMENT INDICATOR CATEGORIES * 1991 * 1991 * 1991 * 1991 * FROM *
* * SUMMARY * SUMMARY * SUMMARY * SUMMARY * NOVEMBER 1991 *
**************************************************************************************************************************
* SERVICE FACTOR(S) * * * * * *
* AVG RESPONSE TIME (ALL FUNCTIONS) * 1.29 * 1.08 * 1.14 * 1.07 * 19.4 *
* WITHIN 0.25 SECONDS * 73.3% * 74.5% * 73.9% * 72.7% * 1.2- *
*f TSO users logged on. That data is found in the RMF type
70 CPU Activity report (see Figure 5) or the RMF Summary report. The
average and maximum logged on TSO users is a key indicator.
Defining the response time distributions is one of the most important steps in installing TSO/MON. You want to make sure that the ranges will be useful for a long time. That is, if your current responses are about one second, be sure to put a couple of sub-second responses in the distributions. Then, at a later date, you’ll have the history available to determine sub-second objectives. TSO/MON also keeps the TSO load in terms of panels, commands, responses, CPU time, etc. as seen in Figure 6. Another load indicator is shown at the bottom of the page (average and maximum number of concurrent users). You could pick any of these measurements for load objectives. I normally use number of responses, total CPU time, and average concurrent users. TSO/MON availability is a true measure of TSO activity since TSO/MON runs as a monitor of TSO. Thus, the availability, number of IPLs, number of start ups and terminations are easily available. I would track availability and number of start ups during prime shift. Notice that this site had a significant problem with availability during October. As a track of the network, I would also set a threshold for number of connect hours. Cheryl Watson's Tuning Letter is a highly-respected, impartial and very practical journal of MVS management and advice published six times a year by Watson & Walker Inc. Call 1-800-553-4562 for subscription information.
|
|
|
|||||||
 |
home · current
articles
· archives · forums · |
