The Dimensions of Service - Exploring WLM�s Solution Space

Rich Olcott Schering-Plough Corporation

3022 Jackson Memphis TN 38151 USA

The behavior of a WLM-managed MVS system is sometimes best understood by looking at the goals rather than the workloads. A WLM goal occupies a space of many di-mensions. The system administrator is free to burden the goal with an assortment of workloads, assign it a high or low importance, and set it a target that is somewhere between lenient and stringent. In execution, the goal may be met well or poorly, at a cost that may be cheap or dear. In this paper, we consider WLM�s metrics and present several maps to facilitate navigation through its multi-dimensional space.

It�s often claimed that humans are unable to think

in more than three dimensions. For proof to the con-trary, consider the apple that struck Isaac Newton�s head.1 The event occurred in 1665, at 52°55´N by 0°38´E, roughly three feet above ground level. The apple, variety �Flower of Kent,� weighed about 8 ounces and was probably somewhat past fully rip-ened.

Now visualize the apple moving two feet upward, northward and eastward while morphing to an under-ripe 4-ounce Damson plum. The change you just imagined describes a seven-dimensional trajectory: three spatial coordinates, one intensive coordinate (weight), one relative coordinate describing degree of ripeness, and two nested enumerative dimensions, species and variety. It is indeed possible to think multi-dimensionally, provided one has the right di-mensions. The WLM administrator has that opportu-nity.

WORKLOAD MANAGER

IBM�s recent MVS incarnations (OS/390, z/OS)

contain a new component, Workload Manager (WLM).2 The purpose of WLM is to simplify the task of specifying which work should be favored, under what circumstances, over which other work.

WLM�s user interface is an online application con-sisting of several dozen interrelated dialog panels for setting up work classification rules and performance goals for each kind of work. The parameterization is so rich and the underlying logic is sufficiently obscure that IBM3 and others4 have found it worthwhile to pre-pare �starter sets� of generalized WLM specifications for use by system administrators who are contemplat-ing migration to WLM operation.

In operation, WLM�s central object is the service class (SC), which comprises a collection of independ-ent units of work that have been grouped together by some identifying criterion such as responsible subsys-tem (JES, TSO, CICS, USS, Web, etc.), task name, originating user id or network location, etc. One or more SC�s are grouped into a workload. IBM recom-mends limiting the total number of SC�s to a dozen or so, but in principle the limit is arbitrary.

Each work unit in an SC is related to a specific performance goal. The goal may be throughput- or re-sponse-related; suffice it to say here that defining a non-trivial goal generally requires specifying three or more parameters. As a work unit absorbs increasing amounts of system resources, it may transition across a succession of up to eight distinct goals within the SC. Each transition threshold is specified by yet another parameter. The collection of work units between two thresholds (including �none� and �maximum�) is termed a period of the SC.

WLM�s method of operation is intimately bound up with the notion of a Control/Response (C/R) curve, such as the simple example in Figure 1. The horizontal axis represents the available range of values for a con-trol variable, say the handle position on a bathtub wa-ter faucet. The vertical axis represents the correspond-ing range of values for some measurement on the con-trolled system. For the bathtub faucet, the response variable could be the inflow in gallons per minute, or possibly the rate of rise of the water in the tub. Notice that a given system may display a bundle of C/R curves; which curve is in effect depends upon some other variable which may or not be under control. For the bathtub, we�d expect a different rate-of-rise curve for each possible value of DrainPlugInPlace(T/F).

Several regions of the C/R curve are worth men-tioning. The non-linear portion A at the top is the well-known case of �diminishing returns,� where opening the faucet wider, or increasing CPU dispatch priority, has little effect on throughput. The linear portion B in the middle generally represents an operating range where it is simple and cheap to predict the effect of a change in the control variable. The non-linear portion at the bottom C is of interest for WLM periods where insufficient traffic or a too-lax goal prevent the collec-tion of usable statistics (see below). A good audio amplifier runs in the boxed range; a transistor in a digital circuit slams back and forth between A and C.

WLM maintains an internal representation of a C/R curve for each combination of SC period and in-ternal control variable (Dispatch Priority, Storage Iso-lation, I/O Priority [if enabled], Parallel Access Volume (PAV) access [if enabled], server count [for some subsystems], etc.). Each �curve� is determined/revised empirically as execution proceeds (see below). The computational cost of maintaining the C/R curves is a major reason for minimizing the number of SCs and periods.

In WLM�s C/R curves, the Response variable is the Performance Index (PI), a target-vs-actual ratio. In general, the PI is defined in such a way that PI less than unity implies better-than-target performance for that goal. WLM�s design is to supply or withhold re-sources to a workload such that its PI stays �close� to unity.

DEPLOYING THE TARGETS It�s important to recognize the distinction between

WLM�s internal control variables, which directly control CPU and memory access, and the external perform-ance target parameters WLM exposes to the system administrator. To underline this point, we survey the external WLM goal parameters incorporating some lessons learned from study of the WLM SMF5 and SDPDS data (see Appendix A).

Every goal has attached to it an Importance (IMP) value. The administrator may explicitly assign a value between 1 (highest importance) and 5 (lowest). Inter-nally, WLM assigns IMP=0 to certain critical tasks in internal service class SYSTEM and also to the tasks externalized in service class SYSSTC. Notice that Im-portance is not Priority: the administrator assigns the former to a performance goal, whereas WLM manipu-lates the latter in order to attain the goal.

WLM offers the administrator several options for controlling a workload. Each option (goal type) has its own performance evaluation technique.

The simplest goal type, Discretionary, really sets two parameters (goal type and Importance) although the user specifies only one. For some reason, WLM in its SMF records marks Discretionary work as IMP=0. For our purposes, IMP=6 is a more meaningful Impor-tance label for this work because that is how WLM treats it -- last to be served. Because Discretionary effectively has no performance goal, there is no corre-sponding PI calculation.

The Velocity goal is designed for throughput-oriented workloads (mostly long-running tasks) and others �for which a response-oriented goal is inappro-priate.� WLM evaluates the performance of a Veloc-ity-controlled task by periodic state sampling. Some-what simplifying (see Appendix A and the documenta-tion5 for the SMF Type 72 Subtype 3 [T72/3] record), the task state is recorded as Using a WLM-controlled resource, Not-Using (i.e., waiting for) a WLM-controlled resource, or Other (i.e., blocked on an event or re-source WLM doesn�t know about or over which it has no control).

At the end of each policy adjustment interval, WLM calculates:

1) Vactual = 100*Using / (Using + NotUsing) The Velocity PI is defined as 2) PIvel = Vtarget / Vactual so that, if the actual velocity exceeds the target, PI is smaller than unity. Like many another catch-all cate-gory, the Velocity is operationally crisp even if its un-derlying philosophy is somewhat muddled.6, 7

For response-oriented workloads the administrator has a choice between Average Response Time (ART) and Percentile Response Time (PRT). ART, like Ve-

Figure 1. A generic Control/Response Curve. Note that the precise shape of the curve depends on the system under consideration.

locity, exposes but a single value parameter. PRT, on the other hand, allows the administrator to specify both the target response time (RT) and the percent-age of tasks that are to complete within that limit.

ART is a strict arithmetic mean, easy to asses and hard to trust for a workload that may contain extreme outliers. To monitor performance for an ART-managed period, WLM counts completions and sums completion times. As the end of a policy adjustment interval, WLM calculates RTactual as the simple mean. The ART PI is

3) PIART = RTactual / RTtarget

There must have been some interesting discus-

sions during the design of the PRT goal and its sup-porting software. Consider the problem. The normal way to calculate a percentile statistic is to sort the ob-servations by increasing measurement value, then start at the low end and tally counts until the target percentage is attained. The value for that observation is the percentile. Sorting is an expensive operation, to be avoided whenever possible, and the WLM design-ers were faced with having to sort thousands of task completions at each policy adjustment point.

The WLM solution is both brilliant and laden with pitfalls for the unwary system administrator. Knuth8 might call it a �pigeon-hole sort;� the SMF record documentation refers instead to a Response Time Distribution Array (RTDA). WLM maintains one such array for each period having a PRT goal. Each array contains 14 counters, each of which in turn represents the number of task completions within an RT range expressed as a fraction of the target RT (see Table 1). For instance, when a batch job completes in 75 sec-onds while running in a PRT period with a target goal

of 100 seconds, WLM adds one tally to counter #4 [range (0.7-0.8)*RT, or between 70 and 80 seconds].

The percentage of tasks meeting goal is simply the total of tallies for the first six counters [<0.5*RT through (0.9-1.0)*RT], divided by the total across the array. In fact, had the WLM designers been willing to base PIPRT on actual-vs-target �Percentage of tasks meeting goal,� they could have used a simpler, two-level RTDA. In-stead, they opted for a much more sophisticated tech-nique with subtle strengths and weaknesses.

WLM�s algorithm takes the target percentage as a given and asks, �What RT was achieved by this frac-tion of the completions?� The answer is obtained by interpolation from the measured RTDA. For example, suppose the period illustrated in Table 1 had a PRT goal of �75% complete in less than 100 seconds.� There were 2149 completions during this policy ad-justment period. WLM would need the bounding RT for the shortest 0.75*2149=1612 tasks. That RT lies somewhere between counter #5 (cumulative total 1502) and #6 (cumulative total 1647). Using interpola-tion (see also Table 4), we estimate

4) RTactual = 90 + (100�90)*(1612�1502)/145

= 97.6 sec

5) PIPRT = RTactual / RTtarget = 97.6 / 100 = 0.98

The strengths of this scheme lie in its computa-tional thriftiness, the inherent scaling to different target response times (fractions of a second for online trans-actions, hours for long batch jobs), and the robustness of the PIPRT metric. The shape of the distribution is a property of the workload, not the processing system, so changing the hardware or adding a competing work-load should at most shift the distribution left or right along the RT axis.

However, the scheme is not a cure-all. Table 2 displays two ways in which injudicious choices by the system administrator could lead to unintended conse-quences. The first case, �Lenient RT,� displays data from a CICS workload for which the administrator had negotiated a Service Level Agreement of �95% com-pletions within 1 second� and had set the workload�s PRT parameters to just those numbers.

As it happens, most of these transactions generate little or no marginal I/O after start-of-business loads the buffers. Furthermore, they have a short pathlength in the CPU. Consider that in a 50 MIPS engine, a million-instruction process will complete in 20 milliseconds. As a result, virtually the entire workload completes well within the shortest tracked interval. WLM�s RDTA logic crowds the work into counter #1 and the workload�s PI appears to be locked at 0.5 (compare segment C in Figure 1).

Table 1. An artificial example of WLM�s Response Time Distribution Array for a PRT-managed pe-riod.

# Range Range, if RT=100

Count %

1 < 0.5 RT < 50 sec 448 21 2 (0.5 - 0.6) RT 50 � 60 358 17 3 (0.6 - 0.7) RT 60 � 70 286 13 4 (0.7 - 0.8) RT 70 � 80 228 11 5 (0.8 � 0.9) RT 80 � 90 182 8 6 (0.9 � 1.0) RT 90 � 100 145 7 7 (1.0 - 1.1) RT 100 � 110 116 5 8 (1.1 � 1.2) RT 110 � 120 92 4 9 (1.2 � 1.3) RT 120 � 130 73 3 10 (1.3 � 1.4) RT 130 � 140 58 3 11 (1.4 � 1.5) RT 140 � 150 46 2 12 (1.5 � 2.0) RT 150 � 200 37 2 13 (2.0 � 4.0) RT 200 � 400 29 1 14 > 4.0 RT > 400 sec 51 2

Under WLM�s care, this particular workload will experience either feast or famine: if it gets enough resource to run at all, it will run so rapidly that WLM will consider it to be an eligible donor immediately upon expiry of a brief grace period. From the end user�s point of view the application appears to gallop, toggling at unpredictable intervals between quick and slow response times.

The lesson from this case is that setting a PRT goal is not simply, as advertised, a matter of transcrib-ing business performance requirements. For the sake of manageability, one must sometimes adjust the tar-get to approximate what the system does instead of what one wants it to do.

The second case in Table 2, �Wide Range,� represents �short� batch jobs (JOB statements speci-fied TIME=1 or equivalent, expected to use less than 60 seconds of CPU time). Here the problem is that WLM�s RTDA tracking is limited to a range from half the target RT to four times RT, but the range of job completion times is much wider than that. In fact, the central ten counters, WLM�s most sensitive predictors of workload behavior, cover only 30% of the comple-tions.

The WLM documentation wistfully recommends that workloads be collected into homogeneous group-ings, but this data represents jobs that were already selected for short execution time. Unless (until?) WLM is able to adjust a tracked RT range to accommodate the workload at hand, it will be only partially effective in using PRT to manage real batch workloads. De-spite its own faults, ART is sometimes better than PRT for managing a response-oriented workload.

In summary, WLM externalizes four different goal types, each of which has its own set of parameters and foibles. Velocity is offered as the type of last re-sort for response-oriented work that cannot be effec-tively managed with ART or PRT. PRT is WLM�s most sophisticated goal type and the one that most closely

matches the way that many installation report on deliv-ered service. However, PRT is also WLM�s most com-plex goal type and may surprise the unwary adminis-trator who sets its parameters to unrealistic values.

STRATEGIC DIRECTIONS

Clearly, if each distinct goal parameter for each SC

period represents a degree of freedom in WLM�s ex-posed solution space, its dimensionality can be huge. No wonder people get lost. But there�s another way to dissect the solution space.

Consider an individual period in a system running under WLM. The period can be considered as an ob-ject in a relatively simple space. It has a membership defined by the classification rules that populate it with work units. It has an importance that dictates how it will fare as its work contends for resources with other work in the system. It has a performance target that can be stated compactly.

We�re not done with the period, but we�ve identified sufficient dimensions so far to prepare a Goal Map, such as the one displayed in Table 3. This map is a useful tool for planning, explaining and adjusting a WLM configuration and can easily be prepared as a report or spreadsheet.9

The map is constructed starting from a list of all the workloads to be run on the system. The ordering of this list is up to the user: maps sorted by workload name or by business visibility have both proven useful. There is one report or spreadsheet row for each Service Class, and one additional row for each additional period in a multi-period SC. (A CICS transaction, for instance, cannot be transitioned between periods because its resource usage cannot [yet?] be individually moni-tored.)

The leftmost field in a row contains the SC descrip-tor, as entered into the WLM online panels. The next fields are the SC name and period number. The rest of the row is a series of by-default blank fields, one for each Importance value 0 to 6. (As noted above, we use IMP=6 for Discretionary work.) An abbreviated indi-cation of the period�s goal is placed in the appropriate Importance column.

The body of the map, the portion enclosed in heavy lines, is essentially a scatter plot of WLM goals laid out on an x-axis that represents goal importance and a y-axis that enumerates workloads. For each SC period, there is one occupied point on the map -- a rep-resentation of its performance target, plotted at its Im-portance value. Thus in Table 3, for instance, the HOTSTC workload (single-period) has an entry labeled �V=50� at IMP=2.

The map�s depiction of a system�s goal structure is not just two-dimensional. There is an implicit, some-what fuzzy, third dimension that appears when one begins comparing goals. Each plotted �point� can be viewed as a indentation whose depth reflects the work-load�s propensity to absorb system resources. Such

Table 2. Two real-data examples of RTDAs gone wrong.

# Lenient RT Wide range Count % Count % 1 12,293 97 1,608 26 2 84 1 604 10 3 47 0 252 4 4 37 0 248 4 5 29 0 261 4 6 21 0 177 3 7 21 0 106 2 8 17 0 111 2 9 13 0 119 2 10 13 0 143 2 11 6 0 137 2 12 24 0 365 6 13 26 0 621 10 14 32 0 1,429 23

comparisons are important, because WLM will attempt to direct resources in such a way that all the work-loads at the same importance level have roughly the same PI.

For instance, consider HOTJOB and HOTTSO in Table 3. Both are Velocity goals at IMP=2, but HOTTSO is assigned the higher target. Suppose there is one TSO user in HOTTSO and one batch job in HOTJOB. If both workloads are achieving their goals (PI=1.0), then HOTTSO (V=50) is the more resource-hungry because by definition it has been sampled as Using more often than has HOTJOB (V=30). Con-versely, if both workloads have the same number of Using counts, then WLM will calculate the higher PI value (see Equation 2) for HOTTSO and will tend to transfer resources from HOTJOB to HOTTSO. HOTTSO can thus be considered a more �aggressive� goal than HOTJOB if the two are expected to have similar traffic levels.

Of course, different workloads rarely have similar traffic levels. Furthermore, goals of different type can-not be compared simply on the basis of their numeric parameters. A careful analyst would hesitate to make an a priori statement comparing system loads due to, say, the 15-sec ART goal for CICPRDB, the 95%<250msec PRT goal for CICPXN, and the V=30

goal for HOTJOB. The assessment would be a sensi-tive combination of workload traffic, resource demand per task, and (for Velocity goals) even WLM�s sam-pling strategy.7

Post hoc knowledge can, however, place a firmer footing under the Goal Map�s z-dimension, which we will call �aggressiveness� and identify with the �typical� Service Unit10 (SU) demand for a period that is meeting its goal under a normal traffic load.

The SU demand at a given time for any SC period can be obtained from data field R723CSRV in the SMF Type 72/3 record (see Appendix A), from data element SECTOSRV in a NeuMICS11 performance database, from SMF T72/3 variable SERVICE in an MXG12 data-base, from an RMF13 WKLD report, or online from any of several OEM performance monitor software prod-ucts. Workload SUs are reported for most subsystems (JES, STC, TSO, etc.) but not (yet?) for CICS or IMS; for these workloads, one must suballocate the SU ab-sorption of the supporting server address space(s).

Figure 2 is a schematic attempt to depict the Goal Map�s three-dimensional character. The gray horizontal plane represents �sea level,� the system�s total supply of service units. The inclined plane represents WLM�s operating instructions. Each �pit� represents a goal,

Table 3. An example of a Goal Map, sorted alphabetically by Service Class name.

Descriptor SrvClass Per IMP=1 IMP=2 IMP=3 IMP=4 IMP=5 IMP=6

CICS Prod RmtDB2 CICPRDB 1 Ave < 15 sec

CICS Prod Xn CICPXN 1 95% < 250msec

CICS T/D Rmt DB2 CICTRDB 1 Ave < 20 sec

CICS T/D Xn CICTXM 1 95% < 250msec

Cold batch COLDJOB 1 DISC Hot batch HOTJOB 1 V = 30

High-vis STCs HOTSTC 1 V = 50 Hot TSO HOTTSO 1 V = 50

IMS Prod IMSPXN 1 95% < 250 msec

IMS T/D IMSTXN 1 95% < 250 msec

Long batch jobs JOBL 1 V = 20 JOBL 2 DISC

Medium batch jobs JOBM 1 V = 20

Short batch jobs JOBS 1 75% < 1 min

Low STC STCLOW 1 V = 15 Mid-level STC STCSTD 1 V = 50

Standard TSO TSOSTD 1 95% < 250 msec

TSOSTD 2 95% < 2 sec

TSOSTD 3 V = 30

and the pit�s �depth,� indicated by its darkness, re-flects its relative SU consumption.

Goals well below sea level have the potential to draw system resources away from goals closer to the water line. In this sketch, for instance, other workloads have absorbed all available resources so the discre-tionary work at IMP=6 will get none. The depth of any goal depends on a combination of its Importance, SU demand per task, and traffic load. Notice, for instance that the two front-most goals at IMP=2 have different depths: period-1 TSO supports much more traffic than does STCSTD.

The utility of the Goal Map arises from two proper-ties:

1. WLM satisfies goals from left to right. 2. Within an importance level, the periods

that draw the most resources are the ones that support the most tasks and/or have the most aggressive goals.

For the system described in Table 3, for instance, if resources are tight we would expect to see goals met for left-most periods HOTSTC (IMP=1) and HOTTSO (IMP=2), even if those for second-period STDTSO (IMP=3), and CICTXN (IMP=4) may be missed to some degree. Furthermore, if STCSTD is

being starved because of excessive period-1 TSO traf-fic, one solution might be to relax the period-1 TSO goal a bit.

The Goal Map provides an at-a-glance summary of every goal WLM will attempt to meet. It can serve as a planning aid, helping the analyst ensure that all work-loads will be ranked and treated properly. It can be a tuning tool, offering the administrator a framework upon which to organize his/her accumulated experi-ence and intuition about the system�s behavior. Finally, it can be a training device, providing the educator a compact diagram that conveys the essence of MVS workload management.

BATTLE RIBBONS

The Goal Map is a three-dimensional view of

planned performance. The performance analyst also needs a comparable view of service delivery, which we�ll call the Actuals Map. For a useful view of service delivery, however, we must plot six dimensions, not three. Moreover, the plot must be presented on a two-dimensional surface (paper or monitor) and, for this publication, in black and white.

Figure 2. A conceptual representation of a Goal Map as a 3-dimensional surface.

On the Actuals Map we need to enumerate each goal and show its relative Importance. At any given moment in the running system, each period absorbs some fraction of the system�s resources; we can de-scribe that load by totaling the SUs allocated to the goal�s work units. At the same moment, the period�s success in meeting its target is measured by its PI. We can describe the overall system load by summing SU absorption across all workloads. Finally, we need to show how all these performance indicators evolve with time.

In the Actuals Map (see Figure 4), we represent each workload�s activity during a specific RMF re-cording interval by a single vertical bar. The width of the bar is the elapsed time during the recording inter-val. The height of the bar is proportional to the work-load�s SU absorption, relative to the highest absorp-

tion by any workload during the same recording inter-val. (Thus, some workload in every interval will receive a 100% SU rating.) If no SUs were used, there is no bar. The �color� of the bar represents the workload�s mean PI during the recording interval: unfilled for PI within 40% either way of 1.0, gray for PI<0.6, and black for PI>1.4.

All the bars for a single workload period (goal) are arranged in a time series along a line that represents the activity of that workload during the reporting period (24 hours in Figure 4). The lines are ordered, top downward, according to the decreasing Importance (increasing IMP number) of the goals.

Finally, the bottom segment of the Actuals Map is a line of bars whose height is proportional to the total SU absorption across all workloads, relative to the maxi-mum for the day. Again, some recording interval will

Table 4.To clarify the interpolation process, this is a fragment of SAS code for computing PI from SMF data. For convenience, the T72/3 record field names are used for the input variables. RETAIN K50 0.50 K60 0.60 K70 0.70 K80 0.80 K90 0.90 KA0 1.00 KB0 1.10 KC0 1.20 KD0 1.30 KE0 1.40 KF0 1.50 K2C 2.00 K4C 4.00 KXX 6.9E8; ARRAY KNN K50 K60 K70 K80 K90 KA0 KB0 KC0 KD0 KE0 KF0 K2C K4C KXX; DROP K50 K60 K70 K80 K90 KA0 KB0 KC0 KD0 KE0 KF0 K2C K4C KXX; ARRAY RTDBNN RTDB50 RTDB60 RTDB70 RTDB80 RTDB90 RTDBA0 RTDBB0 RTDBC0 RTDBD0 RTDBE0 RTDBF0 RTDB2C RTDB4C RTDBXX ; ARRAY CUMNN CUM50 CUM60 CUM70 CUM80 CUM90 CUMA0 CUMB0 CUMC0 CUMD0 CUME0 CUMF0 CUM2C CUM4C CUMXX ; DROP CUM50 CUM60 CUM70 CUM80 CUM90 CUMA0 CUMB0 CUMC0 CUMD0 CUME0 CUMF0 CUM2C CUM4C CUMXX ; PERFINDX = 1; IF R723CRGF = '1... ....'B /* PERCENTILE RT GOAL */ THEN DO; GOALTYPE = 'RTPC'; IF R723CADF = '.0.. ....'B /* NO RT DATA AVAILABLE */ OR R723CRCP = 0 /* NO TRANSACTIONS COMPLETED */ THEN PERFINDX = .; ELSE DO; RTPTR = SMF72RTS - 3 + R723SRTX * SMF72RTL; INPUT @RTPTR RTDB50 PIB4. /* XNS WITH RT < 50% OF GOAL */ RTDB60 PIB4. /* 50% < RT < 60% OF GOAL */ [ similar lines for 70% through 400% �] RTDBXX PIB4. /* 400% OF GOAL < RT */ @ ; CUM50 = RTDB50; DO J = 2 TO 14; /* CUMULATIVE COUNTS */ CUMNN(J) = CUMNN(J-1) + RTDBNN(J); END; TGTCOUNT = R723CPCT * CUMXX / 100; IF TGTCOUNT <= CUM50 THEN PERFINDX = 0.5; ELSE IF TGTCOUNT > CUM4C THEN PERFINDX = 4; ELSE DO; DO J = 2 TO 13 UNTIL (CUMNN(J) >= TGTCOUNT); END; RTACTUAL = KNN(J-1) + (KNN(J) - KNN(J-1)) * (TGTCOUNT - CUMNN(J-1)); PERFINDX = RTACTUAL / RTDBNN(J); END; END; END;

receive a 100% rating for the day, but systems do not have a firm �maximum SU capacity� against which to compare this number. The SU is a mixture of CPU activity, I/O activity and (for some WLM declarations) memory occupancy. A CPU-bound workload will stress the system differently than an I/O-bound one; either one can affect a system-wide SU load inde-pendently of the other.

The Actuals Map includes an �SU Usage� line only to provide a rough indication of system-wide busy-ness as it relates to peaks and valleys in the workload displays. Thus in Figure 4, for instance, the �heavy� activity in STCSTD between 06:00 and 08:00 should

be assessed in the context of a very lightly-laden sys-tem.

In general, one would expect an Actuals Map to be essentially colorless near the top, with occasional patches of gray further down and (for a stressed sys-tem) blackened areas near the bottom. The fact that Figure 4 departs from that ideal (see the IMSPXN and CICPXN workloads in particular) is an indication of a need to study these workloads, possibly to be followed by system and/or goal tuning.

This Actuals Map displays some features that are worth discussing insofar as they illuminate how WLM operates. Probably the most striking is the block for period-2 JOBL between 07:00 and 17:00. The subject

Figure 4. An example of an Actuals Map. Workloads are as described in Table 3, re-ordered by Importance.

system uses a two-policy SD. The night-shift policy has but a single period for long batch jobs (JOBL). The day-shift policy splits JOBL into two periods: jobs running past the million-SU mark are demoted to pe-riod-2 JOBL, which has a Discretionary goal. The Actuals Map clearly shows the migration of the JOBL activity to period-2 when it is present.

At night, JOBL does better-than-target most of the time except during intervals near 03:00 and 23:30 when HOTJOB and STCSTD pull SUs away. None-theless, JOBL gets enough resource to meet its goal. JOBL retains its position as major SU absorber virtu-ally throughout both night and day shifts.

All of the required identifier fields and numeric values to prepare an Actuals Map are available in or can be calculated from the SMF T72/3 record (see Table 4 for the PIPRT interpolation; the other calcula-tions are straightforward transcriptions from the defini-tions). Table 4 and the program14 that generated Fig-ure 4 use the SMF field names for the purposes of this paper -- it would be a trivial (if somewhat tedious) task to alter that program to use data from NeuMICS, MXG, or any other SMF-based performance data-base.

As an aside, the Actuals Map is an example of Tufte�s �small multiples� strategy for increasing data density in a graphic.15 To reduce execution time and maximize Tufte�s data-ink ratio, the author chose to produce the graphic using the SAS-Graph16 Data Step Graphic Interface. Similar graphics could certainly be produced by other software and other techniques, such as using SAS PROC ANNOTATE to compile multiple time series plots built by SAS PROC GCHART.

CONCLUSION

There�s a big difference between �What do you

want to do?� and �What do you want to accomplish?� Early systems management tools, such as MVS� IEAIPS/IEAICS construct, defined the tuning problem in terms of resource allocation. The administrator worked in a solution space with an immense number of dimensions (tuning parameters) mapping arcane options such as domain multiprogramming level, dis-patch priorities for program code and I/O interrupts, time slicing, and half-a-dozen different uses for Ex-panded Storage. Worse, many of these parameters interact with each other and with the available hard-ware, sometimes in surprising ways. Learning those interactions was part of the tuner�s on-the-job training.

However, the system administrator�s real job is to get the computing work done in a timely manner. Us-ing WLM, the administrator specifies what the system is to accomplish, not what task gets how much of which resources. With WLM defining the problem in terms of time-to-completion and allowable delay, the administrator faces a solution space that is simpler to learn and easier to navigate.

The WLM-based tuning process starts by asking, in order:

- How can the system�s workload be seg-mented?

- What is the appropriate performance expecta-tion for each segment?

- What is the relative importance of meeting each expectation?

The answers to these questions translate smoothly (with some caveats) into specifications for WLM Ser-vice Classes, Goals, and Importance ratings.

Both the Goal Map and the Actuals Map are slices through the multi-dimensional parameter-and-metric hyperspace of Workload Manager. The maps are two-dimensional plots in which one axis spans an ordered workload list rather than the customary numeric range. Their common virtue is that they each provide the ana-lyst with a graphical summary of their respective do-mains.

The Goal Map is a strategic tool, showing at a glance how the system�s workloads and performance targets relate to each other. The Actuals Map is tacti-cal, displaying how well the goals were met and what it cost to do that. Both maps highlight the importance of Importance, the administrator�s control on which goals WLM will try hardest to meet.

The human eye is a powerful pattern detector: most people can gain more information more quickly from a visual display than from a table of numbers. As systems gain complexity, they put a premium on their administrators� ability to notice, understand and deal with anomalous behaviors rapidly and effectively. Gone are the days of efficient system management using tabulated reports. Goal-oriented performance tools, such as WLM, and sophisticated graphical tools, such as the Goal Map and the Actuals Map, will be critical equipment in the system administrator�s toolkit.

ACKNOWLEDGEMENT

The author wishes to express his gratitude to the

members of the Enterprise-Wide Capacity and Per-formance Project of SHARE, for an early critique of the thoughts in this paper; and to his Schering-Plough co-workers, the CMG Editorial Reviewer and the CMG Referees, for their thoughtful comments.

Appendix A: WLM Data

WLM exposes three useful data sources for pro-

grammatic examination. Two are documented 5 SMF records:

� Type 72 (RMF Workload Activity and Storage Data), subtype 3 -- RMF records are generated at the end of each RMF recording interval. There is one subtype 3 record for each SC or report class period in which response-oriented work completed or throughput-oriented work executed during the RMF recording interval.

� Type 99 (System Resource Manager Deci-sions), subtype 6 -- Most of the Type 99 re-cords contain trace data and are intended for generation only during a problem determina-tion effort. However, the subtype 6 records can be recorded on a continuous basis be-cause there aren�t many of them (relatively speaking) and they are only generated at the end of each SRM policy adjustment interval. Each T99/6 record contains summary data for one SC period that supported work during the policy adjustment interval.

Types 72/3 and 99/6 overlap in some of their con-tent but have two significant differences. The T99/6 record contains local- and Sysplex-level PI values as calculated at policy adjustment time; the T72/3 record does not include a PI value but does contain all the data required to calculate an average PI for the RMF recording interval. Furthermore, only the T72/3 con-tains resource consumption data.

Both kinds of SMF record share a limitation: they report only on the work that actually ran during an in-terval, and only the WLM policy in effect at the end of the interval. There is no mention of idle SCs/periods or not-in-use policies, nor any indication of the classi-fication rules that directed work into the active SCs/periods. For that information, one must proceed to the third data source, the WLM Service Definition (SD) Partitioned Data Set (SDPDS).

Each SDPDS is a free-standing MVS dataset that comprises a complete service definition (policies, classification rules, etc.). There is reason (see below) to maintain several separate SDPDS files. However, WLM works with not with an SDPDS but rather with tokenized data in a Control DataSet (CDS). WLM pa-rameters are transferred from SDPDS to CDS using the WLM online interface�s install operation; values in the CDS can derive from only one SDPDS. IBM does not consider the SDPDS to be a documented pro-gramming interface. Nonetheless, the SDPDS is a standard Interactive System Productivity Facility (ISPF17) table library and can be inspected and que-ried with standard ISPF facilities. The discussion in this paper reflects SDPDS structure and content found at WLM Function Level 6, as shipped with OS/390 V2R9.0.

Table A-1 displays a high-level summary of most of the two-dozen SDPDS tables. The first four, ATTRTAB through SPTAB, contain all the information required to prepare a multi-policy Goal Map complete with last-update User-Id and timestamp.

The SGTAB record structure clarifies how WLM implements multiple policies within a single SD. In the SGTAB, each row represents one unique combination of service class name and policy name; alternate pol-icy names appear only in rows for service classes that have overridden goals. Thus, the initially declared set of goals comprises the SD�s base policy. Each alter-nate policy is the union of the base policy and one set

Table A-1. Contents of selected SDPDS members.

Table Content Key(s) Row content

ATTRTAB Resource Group attrib-utes

None SP name, RG name, min/max values

SCTAB Service con-trols

SC name Last update id and time, etc,

SGTAB Service goals SC and SP names

Goal pa-rameters

SPTAB Policy control None SP last up-date id and time, descriptor

GMTAB Group mem-bership

Group name, qualifiers

Group de-scriptor

CRTAB Classification rules

None Subsystem, Scname, Rcname, Qualifiers, Descriptor

GRTAB Group con-trols

Group name GM last update id and time

RCTAB Report classes

RC name RC last update id and time

SSTTAB Subsystems Subsystem name

Default SC, RC; SST last update id and time

WLTAB Workloads WL name WL last update id and time

OPTTAB WLM Options None IOP(Y/N), Dynamic alias(Y/N), �

PADTAB Notepad None Ad lib text RELTAB Release None SDPDS

release level as item name

SDCTAB Service defini-tion controls

None SD name, descriptor, SRM coeffs.

AETAB Application Environment

AE name Subsystem, PROC, startparms, �

RTAB Resources for SEs

None Resource name, descriptor

SETAB Scheduling environment

SE name Descriptor

of overrides. If the same override is to be used in mul-tiple alternate policies, it must be re-entered as part of the definition of each alternate.

The next group of tables, GMTAB through WLTAB, drive WLM�s Classification Rule technology for connecting a specific task with a specific Service Class. The following set, OPTTAB through SDCTAB, describe the SD itself. The remainder of the listed ta-bles describe Application Environments (AE), which support certain task classes, and Scheduling Envi-ronments (SE), which control conditional execution. The SDPDS contains several additional tables, but the author has not been able to investigate them because all were empty in the systems that were available for study.

The fact that all the policy-related data is confined to only four tables out of two dozen means that all of the other tables are global to the SD. Altering one of the classification rules or reconfiguring a SE resource, for instance, will affect all policies. That is an obstacle to good systems management practice.

Proper change management requires (1) a posi-tive indication of which parameter set is in effect at the moment, (2) definitive tracking of what changes were put into effect at what time, and (3) an effective fall-back route. As has been remarked elsewhere, WLM as shipped provides only minimal support for these requirements. The SDPDS tables contain date/time/user identification data for the most recent update, but no indication of what was changed, nor any history of previous updates. There is a limited fallback capability, but only for policy override settings and only if the alteration was implemented as a new policy.

WLM responds to the console command

D WLM,SYSTEMS

with a message giving the name and last-update data of the active policy (from SPTAB metadata) and SD (from SDCTAB metadata). Note that the name of the SDPDS is not reported, nor is there a supported on-line way to obtain the table-level metadata for a given SDPDS. Thus, the only way to satisfy change man-agement requirement #1 is to assign a different SD name at each upgrade (e.g., with a sequential num-bering scheme) and to maintain a manual log of SD names and exactly what was altered at each stage.

In the absence of versioning within the SDPDS, requirements #2 and #3 can only be satisfied proce-durally, by rotating through multiple SDPDS files and capturing a backup of each version at the time it is put into production. Fallback then amounts to restoring a prior SDPDS and then using WLM�s online interface to install the SD and activate the desired policy.

1 See www.npl.co.uk/npl/about/newton.html for de-

tails of the incident, which occurred at Newton�s mother�s house in Woolsthorpe near Grantham in Lin-colnshire.

2 IBM issues a detailed reference for WLM with each version of the operating system. For instance, see OS/390 V2R10.0 MVS Planning: Workload Man-agement, IBM document GC28-1761-12. For a general reference, see the IBM Redbook Workload Manager Implementation and Exploitation, IBM document SG24-3526.

3 Starter set downloadable from IBM Washington Systems Center, www-1.ibm.com/servers/eserver/ zseries/zos/wlm/documents/sample/sample.html

4 C. Watson, starter set downloadable from http://www.watsonwalker.com/qsp.html

5 IBM issues a detailed reference for SMF with each version of the operating system. For instance, see IBM, OS/390 V2R10.0 System Management Facili-ties, IBM document GC28-1783-12.

6 N. J. Gunther, �The Workload Manager Velocity Metric Revealed,� SHARE 93, Session 2549 (August, 1999).

7 J. Arwe, �MVS Workload Manager Velocity Goals: What You Don�t know Can Hurt You,� CMG 96 Session INT444 (December, 1996).

8 D. E. Knuth, The Art of Computer Programming, Vol 3, Addison-Wesley, Reading MA (1973).

9 REXX code to generate a Strategy Map from a selected SDPDS will be included in the CMG2002 Handouts CD-ROM. A similar map can be generated from either T72/3 or T99/6 SMF records.

10 The MVS Service Unit is a linear combination of CPU time, number of I/O requests, and (optionally) amount of virtual storage used by the task. The linear coefficients are specified as WLM parameters.

11 Computer Associates, Inc., Islandia NT. 12 Merrill Associates, Dallas TX. 13 RMF (Resource Management Facility) is an in-

tegral component of the MVS operating system. 14 SAS code to generate an Actuals Map from SMF

T72/3 data will be included in the CMG2002 Handouts CD-ROM.

15 E. R. Tufte, The Visual Display of Quantitative Information, Graphics Press, Cheshire CN, 1983.

16 The Data Step Graphics Interface is documented for SAS 8 in SAS/Graph Software Reference, Version 8, SAS Corporation, Cary NC (2000).

17 IBM issues a set of detailed references for ISPF with each version of the operating system. For in-stance, see IBM, OS/390 V2R10.0 ISPF Dialog Devel-oper�s Guide and Reference, IBM document SC28-1273-04.

The Dimensions of Service

Exploring WLM’s Solution Space

Rich OlcottSchering-Plough Corp

CMG 2002 - Session 324

Agenda• Elements of control theory• The notion of “dimension”• Overview of WLM• A strategic tool: the Goal Map• The Attainment dimension: PI• The Cost dimension: SU absorption• A tactical tool: the Actuals Map• Another tactical tool: the CR Map

Control/Response CurveDescribes the

relationship between what you do and what you get.

Generally depends on both the controlled system and its environment.

“If you can’t measure the response curve, you can’t manage the response.”

The Notion of “Dimension”di·men·sion n. (1) A measure of spatial extent, especially width, height, or length. (2) Extent or magnitude; scope. (3) Mathematics. The least number of independent coordinates required to specify uniquely the points in a space, or the range of such a coordinate.

Management “Degrees of freedom” -the number of independent controlledvariables and response metrics.

WLM’s Bailiwick

3 Dimensions of A GoalImportance

SYSTEMS

Discretionary

Velocity

AverageResponse

Time

PercentileResponse

Time

Type

0

1 to 5

6

Value

4 Dimensions of A Period

CICPXN

TSO P1

TSO P2

SBAT

LBAT P1

LBAT P2….

Period IdImportance

0 1 2 3 4 5 6

The Goal Map

• A one-page display of goal structure• Maps the strategic dimensions:

– SC/Period Id - Importance– Goal type - Value(s)

• Each SC period goal is plotted according to its Importance and its Workload

A Sample Goal MapDESCRIPTION SRVC_CLS P IMP=1 IMP=2 IMP=3 IMP=4 IMP=5 DISC

CICS Prod Xns for MDI server CICPMDI 1 95%<20.000SCICS Production transactions CICPXN 1 95%<00.250SCICS T&D Xns for MDI server CICTMDI 1 95%<20.000S

CICS Test transactions CICTXN 1 95%<00.250SCold batch jobs COLDJOB 1 DISCRETIONARYHot batch jobs HOTJOB 1 V = 30

High-level Started Tasks HOTSTC 1 V = 50Hot TSO HOTTSO 1 V = 50

IMS Production transactions IMSPXN 1 95%<00.250SIMS Test transactions IMSTXN 1 95%<00.250S

Long batch jobs JOBL 1 V = 20Long batch jobs JOBL 2 DISCRETIONARY

>>> OVERRIDE FOR POLICY = NIGHT01...Long batch jobs JOBL 1 V = 30

<<< END OF OVERRIDE

Medium batch jobs JOBM 1 V = 20

>>> OVERRIDE FOR POLICY = NIGHT01...Medium batch jobs JOBM 1 V = 30

<<< END OF OVERRIDE

Short batch jobs JOBS 1 75%<00:01:00Low-level Started Tasks STCLOW 1 V = 15Mid-level Started Tasks STCSTD 1 V = 50

Standard TSO TSOSTD 1 95%<00.250SStandard TSO TSOSTD 2 95%<02.000SStandard TSO TSOSTD 3 V = 30

END OF SERVICE GOAL SUMMARY TABLE

Calculating PIGeneral rules:

•PI is a ratio that compares actual with target

•PI is < 1.0 iff performance is better than target

Ave RT goal: PI = RTactual / RTtarget

Velocity goal: PI = Vtarget / Vactual

A brilliant solution, but with pitfalls…

• Most shops use percentile RT goals

• Calculating any percentile is expensive

• Solution: use buckets– Goal is “p% with response time < t ”– Define PI = (RT for p%)/(t )

– Tally completions into buckets by RT

– Calculate PI by interpolation between buckets

Percentile Response Goal

PRT Buckets - The RTDA

75%ile ~108% of target==> PI = 1.08

Interpolation

Control/Response CurveWLM’s perspective on how

the system behaves

“Controlled variable” = WLM’s Internalvariables (SRM, etc.)

“Response” = PI

One curve per driver per SC period with a performance goal

Periodically re-estimated from current data

A Good Sight-picture

Case 1 - Sight Off-target

Case 1 - Lenient Goals

Case 2 - High-x Scope

Case 2 - Broad Workload

PRT versus ART• If completion rate is not “statistically

significant” (per IBM: >10 completions per 20 min), use Velocity

• ELSE use PRT except for workloads that cannot be segmented into homogeneous subsets, e.g.:– CICS “umbrella” transactions– General-purpose DDF plans

• ELSE use ART

... in WLM “Options” panel

The Cost of ServiceC1 * (“TCB” CPU seconds)

+ C2 * (“SRB” CPU seconds)

+ C3 * (IO activity)

+ C4 * (CPU * memory)

Service Units used =

C1 = CPU Coefficient * SRM constantC2 = SRB coefficient * SRM constantC3 = IOC coefficientC4 = MSO Coefficient (should be 0.000)

DESCRIPTION SRVC_CLS P IMP=1 IMP=2 IMP=3 IMP=4 IMP=5 DISC

CICS Prod Xns for MDI server CICPMDI 1 95%<20.000SCICS Production transactions CICPXN 1 95%<00.250SCICS T&D Xns for MDI server CICTMDI 1 95%<20.000S

CICS Test transactions CICTXN 1 95%<00.250SCold batch jobs COLDJOB 1 DISCRETIONARYHot batch jobs HOTJOB 1 V = 30

High-level Started Tasks HOTSTC 1 V = 50Hot TSO HOTTSO 1 V = 50

IMS Production transactions IMSPXN 1 95%<00.250SIMS Test transactions IMSTXN 1 95%<00.250S

Long batch jobs JOBL 1 V = 20Long batch jobs JOBL 2 DISCRETIONARY

>>> OVERRIDE FOR POLICY = NIGHT01...Long batch jobs JOBL 1 V = 30

<<< END OF OVERRIDE

Medium batch jobs JOBM 1 V = 20

>>> OVERRIDE FOR POLICY = NIGHT01...Medium batch jobs JOBM 1 V = 30

<<< END OF OVERRIDE

Short batch jobs JOBS 1 75%<00:01:00Low-level Started Tasks STCLOW 1 V = 15Mid-level Started Tasks STCSTD 1 V = 50

Standard TSO TSOSTD 1 95%<00.250SStandard TSO TSOSTD 2 95%<02.000SStandard TSO TSOSTD 3 V = 30

END OF SERVICE GOAL SUMMARY TABLE

The Goal Map And SU Usage

V=30V=50

The Goal Map in 3D

How to Read a Goal Map• WLM satisfies goals from left to right.• Within an importance level, WLM tends

to maintain all workloads near the same PI value.

• Within an importance level, the periods that draw the most resources are the ones with the most tasks and/or have the most aggressive goals.

T72(3), SCS section• Record per period

per RMF recording interval

• Goal type• Importance• Target value• Data for PI calc

– RT %ile Buckets

SMF DataT99(6)• Record per period

per WLM policy adjustment intvl

• Goal type• Importance• Target value• Local and Sysplex

PI’s

Lessons from SMF Data

• Generated only for in-use periods

• Reports only the in-effect policy

• In-effect classification rules are assumed, not reported

SDPDS Structure

A standard ISPF ISPTLIB-style library

Service Goal TablesxxTAB Content Key(s) Row Content

SGService goals

SC, SP names

Goal values (*)

SCService controls

SC nameSC control data (last update id and timestamp, etc.)

* - For Periods 1-8: Disc (Y/N), Importance, SRM Duration, Velocity, %ile, Hr, Min, Sec

Policy name is either the base or one alternate.

Lessons from the SDPDS

• An alternate policy is the base, plus one set of overrides.– Overrides apply to the base policy only.

• Classification rules are global to an SD.• The SDPDS is the place to go for

comprehensive knowledge of an SD.• Change mgmt and availability mgmt

must be accomplished by PDS mgmt.

Tactical Dimensions

• Service class/period identifier

• Importance

• Goal attainment (PI)

• Cost (SU absorption rate)

• Overall system load (total SU rate)

• Time

One SC Period in 3D

SU’s used relative to other SC/pd’s in intrvl

15 min

0.6 < PI < 1.4

PI <= 0.6

1.4 <= PI

Cost Time Attainment

The Actuals Map

Attainment dimension

SYSTEMS and DISC will always be

Expect high-importance lines to be

Expect patches of lower down, especially in a stressed system.

A lenient goal ==> persistent

An unmanageable goal ==> persistent

Reading An Actuals Map - 1

Reading An Actuals Map - 2Cost dimensionBar heights highlight the costliest

SC/period in each interval.“Tot SU Usage” is key to evaluating

impact of a “heavy user” at a given time.

Watch for timing correlations between different lines.

After Some Tuning...

CR “Maps”• Need to locate cross-assignments,

duplicates; identify missing items• WLM’s report

– one report per subsystem– precedence structure within Subsystem

• Alternative map structures– group work assigned to a Service Class– group work within a Report Class– line per workload, including descriptors

• Spreadsheet format– slice and dice to taste

Classification Rule TablesCR

Classifica-tion rules

NoneSubsystem, Scname, Rcname, Qualifier literals, Descriptor

GRGroup controls

Group Name GN control data

RCReport classes

RC name RC control data

SCSC controls

SC name SC control data

SGService goals

SC and SP names

SC goals

SSTSub-systems

Subsystem name

Default SC, RC; SST control data

Part of a CR CSV Extract

Using the Maps

• Strategic (especially the Goal Map)– Visualize effects of period elimination,

overrides, Importance re-assignment– Training and negotiation tool

• Tactical (especially the Actuals Map)– Goal tuning– Rule tuning– What-changed analysis

• Use 3.13 to compare before-and-after Goal and CR reports

Additional Goodies• SHOWWLM

– REXX code to prepare Goal and CR maps– Called from TSO or batch– Reads SDPDS named at call time

• SMF723– SAS code to prepare Actuals maps– Called from batch– Reads SMF data from DD-ref’d file

Both are on the CMG 2002 Handouts CD-ROM

Valedictory

Keep this message

close to your soul:

don’t mess with resources,

manage your goal.

Questions?

SMF723.TXTOPTIONS NOOVP NOCENTER;DATA SMF72HD (KEEP = ENDTS SMF72IST SYSID SMF72INT SMF72STY SMF72TRN SMF72PRS SMF72PRL SMF72PRN SMF72WMS SMF72WML SMF72WMN SMF72SSS SMF72SSL SMF72SSN SMF72RGS SMF72RGL SMF72RGN SMF72SCS SMF72SCL SMF72SCN SMF72RTS SMF72RTL SMF72RTN SMF72WRS SMF72WRL SMF72WRN SMF72CPS SMF72CPL SMF72CPN SMF72SPS SMF72SPL SMF72SPN ) T723WLMC (KEEP = ENDTS SMF72IST SYSID SMF72INT /* R723MNSP R723MTPA R723MTV_ /* */ R723MCNM R723MCPG /* R723MIDN R723MTDI R723MIDU /* */ ) T723SSSD (KEEP = ENDTS SMF72IST SYSID SMF72INT R723MCNM R723MCPG R723SCSN R723SCS_ ) T723RGSD (KEEP = ENDTS SMF72IST SYSID SMF72INT R723MCNM R723MCPG R723GGNM R723GGMN R723GGMX ) T723SCPD (KEEP = ENDTS SMF72IST SYSID SMF72INT RATE PERFINDX R723MNSP R723MDSP R723MTPA R723MIDN R723MIDD R723MTDI R723MIDU R723MSCF R723MCNM R723MCDE R723MCPG GOALTYPE R723CADF R723CPER R723CRTF R723CRGF R723CVAL R723CPCT R723CIMP R723CDUR R723CSRV R723CCPU R723CIOC R723CMSO R723CSRB R723CPIR R723CHPI R723CBPI R723CPIE R723CBPE R723CBKA R723CBKE R723CPRS R723CERS R723CTRR R723CTAT R723CRCT R723CIIT R723CHST R723CSWC R723CCRM R723CRCP R723CARC R723CNCP R723CANC R723CTET R723CXET R723CETS R723CCUS R723CTOT R723CCDE R723CCCA R723CSWI R723CMPL R723CAPR R723CACO R723CAXM R723CCIO R723CHSP R723CCHS R723CUNK R723CIDL R723CPQE R723CPQU R723CSAC R723CSRS R723CSPA R723CSPE R723CICT R723CIWT R723CIDT R723CIRC R723CTOU R723CIOU R723CIOD R723CQ R723CSPV R723CSVI R723CSHS R723CSMP R723CSSW R723CNDI R723CTDQ R723CTSA R723CIOT R723CQDT R723CADT R723CCVT R723CIQT R723CIEA R723CXEA R723CFEA RTDB50 RTDB60 RTDB70 RTDB80 RTDB90 RTDBA0 RTDBB0 RTDBC0 RTDBD0 RTDBE0 RTDBF0 RTDB2C RTDB4C RTDBXX ) T723WRSD (KEEP = ENDTS SMF72IST SYSID SMF72INT R723MCNM R723MCPG R723RTYP R723RFLG R723RESS R723RACT R723RRDY R723RIDL R723RWLO R723RWIO R723RWCO R723RWDS R723RWSL R723RWSN R723RWSS R723RWTM R723RWO R723RWMS R723RSSL R723RSSS R723RSSN R723RWNL ) T724SCPD (KEEP = ENDTS SMF72IST SYSID SMF72INT R724PNAM R724PTM R724LCNM R724PER_ R724USER R724ACTV R724ACTS R724IDLS R724PAGE R724SWAP R724OUTR R724PGIN R724DIVS R724LSSA R724PSSA R724UPRO R724UDEV R724DPRO R724DDEV

Page 1

SMF723.TXT R724DSTO R724DJES R724DHSM R724DXCF R724DENQ R724DMNT R724DMSG R724UNKN R724VALD R724LSCT R724ESCT R724PSCT R724ACTF R724IDLE R724SLOT R724DIV R724FIX R724LSCF R724LSEF R724PSEF R724VECT R724ET R724QT R724END R724TSV R724VIN R724VLC R724GPI ) T724SPPD (KEEP = ENDTS SMF72IST SYSID SMF72INT R724PNAM R724PTM R724LCNM R724PER_ R724OR1 R724OR2 R724OR3 R724OR4 R724OR5 R724OR6 R724OR7 R724OR8 R724OR9 R724OR10 R724OR11 R724OR12 R724OR13 R724OR14 R724OR15 R724OR16 R724OR17 ) ; RETAIN K50 0.50 K60 0.60 K70 0.70 K80 0.80 K90 0.90 KA0 1.00 KB0 1.10 KC0 1.20 KD0 1.30 KE0 1.40 KF0 1.50 K2C 2.00 K4C 4.00 KXX 6.9E8; ARRAY KNN K50 K60 K70 K80 K90 KA0 KB0 KC0 KD0 KE0 KF0 K2C K4C KXX; DROP K50 K60 K70 K80 K90 KA0 KB0 KC0 KD0 KE0 KF0 K2C K4C KXX; ARRAY RTDBNN RTDB50 RTDB60 RTDB70 RTDB80 RTDB90 RTDBA0 RTDBB0 RTDBC0 RTDBD0 RTDBE0 RTDBF0 RTDB2C RTDB4C RTDBXX ; ARRAY CUMNN CUM50 CUM60 CUM70 CUM80 CUM90 CUMA0 CUMB0 CUMC0 CUMD0 CUME0 CUMF0 CUM2C CUM4C CUMXX ; DROP CUM50 CUM60 CUM70 CUM80 CUM90 CUMA0 CUMB0 CUMC0 CUMD0 CUME0 CUMF0 CUM2C CUM4C CUMXX ;

INFILE SMF MISSOVER LENGTH = RECLEN COLUMN = COL; INPUT @2 SMFXXRTY PIB1. @;

IF SMFXXRTY = 72 THEN DO; INPUT @3 ENDTS SMFSTAMP8. @11 SYSID $4. @19 SMF72STY PIB2. @21 SMF72TRN PIB2. @25 SMF72PRS PIB4. /* RMF PRODUCT SECTION */ SMF72PRL PIB2. SMF72PRN PIB2. @ ; PT = COL; FORMAT ENDTS DATETIME.; /* RMF PRODUCT SECTION */ PTR = SMF72PRS - 3; IF SMF72PRN > 0 THEN DO; INPUT @PTR SMF72MFV $2. /* PRODUCT VERSION NUMBER */ SMF72PRD $8. /* PRODUCT NAME ('RMF') */ SMF72IST RMFSTAMP8./* INTERVAL START TIMESTAMP */ SMF72INT RMFDUR4. /* DURATION (MMSSTTTF) */ SMF72MFL PIB2. /* RECORD MAINT INDICATOR */ SMF72SAM PIB4. /* SAMPLE COUNT */ +2 SMF72FLA PIB2. /* FLAGS: */ /* 80X ==> RESERVED */ /* 40X ==> SKIPPED SAMPLES */ /* 20X ==> RMF MON-3 RECORD */ /* 10X ==> SYNCH'ED WITH SMF */ SMF72RLS $4. /* O/S RELEASE LEVEL */ SMF72CYC PD4. /* SAMPLE CYCLE LENGTH, MS */ SMF72MVS $4. /* MVS SOFTWARE LEVEL */ SMF72IML PIB1. /* PROCESSOR: */ /* 01X ==> 308X/908X */

Page 2

SMF723.TXT /* 02X ==> 4381 */ /* 03X ==> 3090, ES9000, 9672*/ SMF72PRF PIB1. /* PROCESSOR: */ /* 80X ==> EXPANDED STORAGE */ /* 40X ==> ESCA-ENABLED */ /* 20X ==> ES DIRECTOR */ SMF72PTN PIB1. /* PR/SM PARTITION NUMBER */ SMF72SRL PIB1. /* SMF RECORD LEVEL NUMBER */ SMF72IET TODSTAMP8./* INTERVAL EXPIRED TIME TOKEN*/ SMF72LGO TODSTAMP8./* OFFSET TO GMT */ SMF72RAO PIB4. /* OFFSET TO REASSEMBLY AREA */ SMF72RAL PIB2. /* LENGTH OF REASSEMBLY AREA */ SMF72RAN PIB2. /* REASSEMBLY AREA FLAGS */ /* 80X ==> RECORD NOT BROKEN */ /* 40X ==> RECORD IS BROKEN */ SMF72OIL PIB2. /* INTVL LENGTH, SEC. */ SMF72SYN PIB2. /* SYNCH VALUE, SEC. */ SMF72SYN PIB2. /* SYNCH VALUE, SEC. */ SMF72XNM $8. /* SYSPLEX NAME (FRM COUPLEXX)*/ SMF72SNM $8. /* SYSTEM NAME (FROM IEASYSXX)*/ @ ; FORMAT SMF72IST SMF72IET SMF72LGO DATETIME. SMF72INT TIME12.3;* OUTPUT T723RMFP;* PTR = PTR + SMF72PRL; END /* PRODUCT SECTION */ ;

IF SMF72STY = 3 THEN DO; INPUT @PT SMF72WMS PIB4. /* WORKLOAD MANAGER CONTROL SECTION */ SMF72WML PIB2. SMF72WMN PIB2. SMF72SSS PIB4. /* SERVICE CLASS SERVED DATA SECTION */ SMF72SSL PIB2. SMF72SSN PIB2. SMF72RGS PIB4. /* RESOURCE GROUP DATA SECTION */ SMF72RGL PIB2. SMF72RGN PIB2. SMF72SCS PIB4. /* SERVICE CLASS PERIOD DATA SECTION */ SMF72SCL PIB2. SMF72SCN PIB2. SMF72RTS PIB4. /* RESPONSE TIME DISTN DATA SECTION */ SMF72RTL PIB2. SMF72RTN PIB2. SMF72WRS PIB4. /* WKLD/RSRC MGR STATE DATA SECTION */ SMF72WRL PIB2. SMF72WRN PIB2. @ ;* OUTPUT SMF72HD;* N723 + 1;* IF N723 < 3 THEN LIST; /* WLM CONTROL SECTION */ PTR = SMF72WMS - 3; IF SMF72WMN > 0 THEN DO J = 1 TO SMF72WMN; INPUT @PTR R723MSCF PIB1. /* FLAGS: */ /* 80X ==> REPORT CLASS */ /* 40X ==> WKLD ACTIVITY N/A */ /* 20X ==> POLICY DATA N/A */ /* 10X ==> VEL INCL I/O DLY */ +3 R723MNSP $8. /* POLICY NAME */ R723MDSP $32. /* POLICY DESCRIPTION */ R723MTPA TODSTAMP8./* POLICY ACT'V'N TIMESTAMP */ R723MCPU PIB4. /* CPU COEFF * 10,000 */ R723MIOC PIB4. /* IOC COEFF * 10,000 */ R723MMSO PIB4. /* MSO COEFF * 10,000 */

Page 3

SMF723.TXT R723MSRB PIB4. /* SRB COEFF * 10,000 */ R723MTVL PIB4. /* WLM SAMPLE INTERVAL (MSEC) */ R723MTV_ PIB4. /* _ TIMES SAMPLING CODE RAN */ R723OPT $2. /* IEAOPTXX SUFFIX */ +2 R723MWNM $8. /* WORKLOAD GROUP NAME */ R723MWDE $32. /* WORKLOAD GROUP DESCRIPTION */ R723MCNM $8. /* SRVC/RPT CLASS NAME */ R723MCDE $32. /* SRVC/RPT CLASS DESCRIPTION */ R723MCPG PIB2. /* RPT CLS: 0; SRV CLS PERIODS*/ R723MSUB PIB1. /* _ WRS ENTRIES IN A SUBSYSTM*/ +3 R723MERF $6. /* ENQ RESIDENCY CPU FACTOR */ R723MADJ PIB4. /* ADJ FACTOR FOR CPU RATE */ R723MIDN $8. /* SERVICE DEFN NAME */ R723MIDD $32. /* SERVICE DEFN DESCRIPTION */ R723MTDI TODSTAMP8./* SD INSTALL TIMESTAMP */ R723MIDU $8. /* USERID OF SD INSTALLER */ @ ; FORMAT R723MSCF HEX2. R723MTPA R723MTDI DATETIME.;* OUTPUT T723WLMC; PTR = PTR + SMF72WML; END /* WLM SECTION */ ; /* SRVC CLASS SERVED DATA SCTN*/ PTR = SMF72SSS - 3; DO J = 1 TO SMF72SSN; INPUT @PTR R723SCSN $8. /* SERVICE CLASS SERVED NAME */ R723SCS_ PIB4. /* NUMBER OF TIMES OBSERVED */ @ ;* OUTPUT T723SSSD; PTR = PTR + SMF72SSL; END /* SSS SECTION */ ; /* RESOURCE GROUP DATA SCTN*/ PTR = SMF72RGS - 3; IF SMF72RGN > 0 THEN DO J = 1 TO SMF72RGN; INPUT @PTR R723GGNM $8. /* RESOURCE GROUP NAME */ R723GGDE $32. /* RESOURCE GROUP DESCRIPTION */ R723GGLT PIB1. /* FLAGS: */ /* 80X ==> MAX CAPACITY SPECD*/ /* 40X ==> MIN CAPACITY SPECD*/ +3 R723GGMN PIB4. /* ZERO OR MIN CAPACITY */ R723GGMX PIB4. /* ZERO OR MAX CAPACITY */ @ ; FORMAT R723GGLT HEX2.;* OUTPUT T723RGSD; PTR = PTR + SMF72RGL; END /* RG SECTION */ ; /* SRVC CLASS PERIOD DATA SCTN*/ PTR = SMF72SCS - 3; IF SMF72SCN > 0 THEN DO J = 1 TO SMF72SCN; INPUT @PTR R723SRTX PIB2. /* INDEX INTO RT BUCKET TABLE */ R723CWMX PIB2. /* INDEX INTO WRK/RM STATE TB */ R723CWMN PIB2. /* _ ENTRIES IN WRK/RM STATE T*/ +1 R723CADF PIB1. /* FLAGS: */ /* 80X ==> CONSUMPTN DATA OK */ /* 40X ==> RT DATA OK */ /* 20X ==> DELAY DATA OK */ R723CPER PIB1. /* PERIOD NUMBER */ R723CRTF PIB1. /* FLAGS: */ /* 80X ==> CVAL RT IN MSEC */ /* 40X ==> CVAL RT IN SEC */ /* 20X ==> CVAL RT IN MIN */ /* 10X ==> CVAL RT IN HOURS */ R723CRGF PIB1. /* FLAGS: */ /* 80X ==> PERCENTILE RT */

Page 4

SMF723.TXT /* 40X ==> AVERAGE RT */ /* 20X ==> VELOCITY */ /* 10X ==> DISCRETIONARY */ +1 R723CVAL PIB4. /* ZERO(DISC) OR GOAL VALUE */ R723CPCT PIB2. /* ZERO OR GOAL PERCENTILE */ R723CIMP PIB2. /* ZERO(DISC) OR IMPORTANCE */ R723CDUR PIB4. /* ZERO OR DURATION (SU'S) */ R723CSRV RB8. /* TOTAL SERVICE UNITS */ R723CCPU RB8. /* CPU SERVICE UNITS */ R723CIOC RB8. /* IOC SERVICE UNITS */ R723CMSO RB8. /* MSO SERVICE UNITS */ R723CSRB RB8. /* SRB SERVICE UNITS */ R723CPIR RB8. /* TOTAL PAGE-INS */ R723CHPI RB8. /* HIPERSPACE PAGE-INS */ R723CBPI RB8. /* BLOCK PAGE-INS FROM AUX */ R723CPIE RB8. /* PAGE-INS FROM ES */ R723CBPE RB8. /* BLOCK PAGE-INS FROM ES */ R723CBKA RB8. /* AUX BLOCKS PAGED IN */ R723CBKE RB8. /* EXP BLOCKS PAGED IN */ R723CPRS RB8. /* PAGE RESIDENCY TIME (1024US*/ R723CERS RB8. /* EXP PAG RES TIME (1024 USEC*/ R723CTRR RB8. /* IN-STG RES TIME (1024 USEC)*/ R723CTAT RB8. /* XN ACTIVE TIME (1024 USEC) */ R723CRCT RB8. /* RCT TIME (USEC) */ R723CIIT RB8. /* IO INTERRUPT TIME (USEC) */ R723CHST RB8. /* HSPACE SERVICE TIME (USEC) */ R723CSWC PIB4. /* SWAP COUNT */ R723CCRM PIB4. /* HSPACE ESO READ MISSES */ R723CRCP PIB4. /* XN COMPLETIONS THIS PERIOD */ R723CARC PIB4. /* ABNORMAL COMPLETIONS */ R723CNCP PIB4. /* NOTIFY (IWMNTFY) COMPLETES */ R723CANC PIB4. /* ABNORMAL IWMNTFY COMPLETES */ R723CTET RB8. /* XN ELAPSED TIME (1024 US) */ R723CXET RB8. /* XN EXEC TIME (1024 US) */ R723CETS RB8. /* XN ETIME SQUARED (1024 US) */ R723CCUS PIB4. /* CPU USING SAMPLES */ R723CTOT PIB4. /* TOTAL WLM EXEC DELAY SMPLS */ /* INCLUDED IN R723CTOT... */ R723CCDE PIB4. /* CPU DELAY SAMPLES */ R723CCCA PIB4. /* CPU CAPPING DELAY */ R723CSWI PIB4. /* SWAP-IN DELAY */ R723CMPL PIB4. /* MPL DELAY (OUT-AND-READY) */ R723CAPR PIB4. /* AUX PAGEIN (PRIVATE) DELAY */ R723CACO PIB4. /* AUX PAGEIN (COMMON ) DELAY */ R723CAXM PIB4. /* AUX PAGEIN (X MEM ) DELAY */ R723CCIO PIB4. /* AUX PAGEIN (VIO ) DELAY */ R723CHSP PIB4. /* AUX PAGEIN (STD HSP) DELAY */ R723CCHS PIB4. /* AUX PAGEIN (ESO HSP) DELAY */ /* NOT INCL IN R723CTOT... */ R723CUNK PIB4. /* UNKNOWN DELAY */ R723CIDL PIB4. /* IDLE (SELF-INFLICTED WAIT) */ R723CPQE PIB4. /* RESOURCE GROUP CAPPING */ R723CPQU PIB4. /* QUIESCE COUNT */ /* ADDL EXEC DELAY DATA... */ R723CSAC PIB4. /* SAMPLED ADDRESS SPACE COUNT*/ R723CSRS RB8. /* SHRD PAGE RES TIME (1024US)*/ /* INCLUDED IN R723CTOT... */ R723CSPA RB8. /* SHRD PAGE-INS FROM AUX */ R723CSPE RB8. /* SHRD PAGE-INS FROM ES */ /* ADDL RESOURCE CONSUMPTION... */ R723CICT RB8. /* NON-PAGE DASD CNNCT (128US)*/ R723CIWT RB8. /* NON-PAGE DASD Q+PEN (128US)*/ R723CIDT RB8. /* NON-PAGE DASD DISCN (128US)*/

Page 5

SMF723.TXT R723CIRC PIB4. /* NON-PAGE DASD SSCH COUNT */ /* ADDL EXEC DELAY DATA... */ R723CTOU PIB4. /* TOTAL USING SAMPLES */ R723CIOU PIB4. /* I/O USING SAMPLES */ R723CIOD PIB4. /* DASD DELAY SAMPLES */ R723CQ PIB4. /* QUEUE DELAY SAMPLES */ R723CSPV PIB4. /* SERVER PRIVATE PAGEIN SMPLS*/ R723CSVI PIB4. /* SERVER VIO PAGEIN SMPLS*/ R723CSHS PIB4. /* SERVER HSPACE PAGEIN SMPLS*/ R723CSMP PIB4. /* SERVER MPL DELAY SAMPLES */ R723CSSW PIB4. /* SERVER SWAP-IN DELAY SMPLS */ R723CNDI PIB4. /* NON-DASD I/O USE/DLY SMPLS */ R723CTDQ PIB4. /* TOT DLY SMPLS (INCL JES Q) */ R723CTSA RB8. /* TOT EXEC SAMPLES */ R723CIOT RB8. /* TOT DASD IOS DLY (128 USEC)*/ R723CQDT RB8. /* TOT QUEUE DLY (1024 USEC) */ R723CADT RB8. /* AFFINITY DLY (1024 USEC) */ R723CCVT RB8. /* JCL CONV TIME (1024 USEC) */ R723CIQT RB8. /* IPT QUEUE DLY (1024 USEC) */ R723CIEA RB8. /* LOCAL ENCLV XN TIME (1024US*/ R723CXEA RB8. /* EXPRT ENCLV XN TIME (1024US*/ R723CFEA RB8. /* FORGN ENCLV XN TIME (1024US*/ @ ; PERFINDX = 1; R723CTET = R723CTET * 1024E-6; FORMAT R723CADF R723CRTF R723CRGF HEX2.; IF R723CRGF = '1... ....'B /* PERCENTILE RT GOAL */ THEN DO; GOALTYPE = 'RTPC'; IF R723CADF = '.0.. ....'B /* NO RT DATA AVAILABLE */ OR R723CRCP = 0 /* NO TRANSACTIONS COMPLETED */ THEN PERFINDX = .; ELSE DO; RTPTR = SMF72RTS - 3 + R723SRTX * SMF72RTL; INPUT @RTPTR RTDB50 PIB4. /* XNS WITH RT < 50% OF GOAL */ RTDB60 PIB4. /* 50% < RT < 60% OF GOAL */ RTDB70 PIB4. /* 60% < RT < 70% OF GOAL */ RTDB80 PIB4. /* 70% < RT < 80% OF GOAL */ RTDB90 PIB4. /* 80% < RT < 90% OF GOAL */ RTDBA0 PIB4. /* 90% < RT < 100% OF GOAL */ RTDBB0 PIB4. /* 100% < RT < 110% OF GOAL */ RTDBC0 PIB4. /* 110% < RT < 120% OF GOAL */ RTDBD0 PIB4. /* 120% < RT < 130% OF GOAL */ RTDBE0 PIB4. /* 130% < RT < 140% OF GOAL */ RTDBF0 PIB4. /* 140% < RT < 150% OF GOAL */ RTDB2C PIB4. /* 150% < RT < 200% OF GOAL */ RTDB4C PIB4. /* 200% < RT < 400% OF GOAL */ RTDBXX PIB4. /* 400% < RT OF GOAL */ @ ; RATE = R723CRCP / SMF72INT; CUM50 = RTDB50; DO J = 2 TO 14; CUMNN(J) = CUMNN(J-1) + RTDBNN(J); END; TGTCOUNT = R723CPCT * CUMXX / 100; IF TGTCOUNT <= CUM50 THEN PERFINDX = 0.5; ELSE IF TGTCOUNT > CUM4C THEN PERFINDX = 4; ELSE DO; DO J = 2 TO 13 UNTIL (CUMNN(J) >= TGTCOUNT); END; PERFINDX = KNN(J-1) + (KNN(J) - KNN(J-1)) * (TGTCOUNT - CUMNN(J-1))/RTDBNN(J); END;

Page 6

SMF723.TXT END; END; ELSE IF R723CRGF = '.1.. ....'B THEN DO; GOALTYPE = 'RTAV'; IF R723CRCP = 0 /* NO TRANSACTIONS COMPLETED */ THEN PERFINDX = .; ELSE PERFINDX = (R723CTET / R723CRCP) / R723CVAL; END; ELSE IF R723CRGF = '..1. ....'B THEN DO; GOALTYPE = 'VEL'; IF R723CTOU = 0 THEN PERFINDX = .; ELSE PERFINDX = R723CVAL * (R723CTOU + R723CTOT) / (100 * R723CTOU); END; ELSE IF R723CRGF = '...1 ....'B THEN GOALTYPE = 'DISC'; ELSE IF R723CRGF = '.... 1...'B THEN GOALTYPE = 'SPM'; ELSE GOALTYPE = '????'; IF R723MCNM = 'SYSOTHER' THEN GOALTYPE = 'DISC'; IF GOALTYPE = 'DISC' THEN R723CIMP = 6;

LABEL R723MCNM = 'CLASS NAME'; LABEL R723CPER = 'PERIOD'; LABEL R723CSRV = 'SERVICE UNITS'; LABEL R723CRCP = 'COMPLETIONS'; LABEL R723CNCP = 'NOTFY COMP'; LABEL R723CTET = 'TOT XN ETIME'; LABEL R723CTOT = 'SAMPLES DELAY'; LABEL R723CTOU = 'SAMPLES USING'; LABEL PERFINDX = 'PI'; LABEL R723CIMP = 'IMPORTANCE'; OUTPUT T723SCPD; PTR = PTR + SMF72SCL; END /* SCP SECTION */ ; /* WRK/RSRC MGR STATE DATA */ PTR = SMF72WRS - 3; IF SMF72WRN > 0 THEN DO J = 1 TO SMF72WRN; INPUT @PTR R723RTYP $4. /* SUBSYSTEM TYPE */ R723RFLG PIB1. /* FLAGS: */ /* 80X ==> BEGIN-TO-END SMPL */ /* 40X ==> EXEC PHASE SAMPLE */ +3 R723RESS PIB4. /* _ XN STATES SAMPLED */ R723RACT PIB4. /* ACTIVE STATE SAMPLES */ R723RRDY PIB4. /* READY STATE SAMPLES */ R723RIDL PIB4. /* IDLE STATE SAMPLES */ R723RWLO PIB4. /* WAITING FOR LOCK */ R723RWIO PIB4. /* WAITING FOR I/O */ R723RWCO PIB4. /* WAITING FOR CONVERSATION */ R723RWDS PIB4. /* WAITING FOR DISTD REQUEST */ R723RWSL PIB4. /* WAITING FOR SESSION, LOCAL */ R723RWSN PIB4. /* WAITING FOR SESSION, NETWK */ R723RWSS PIB4. /* WAITING FOR SESSION, SYSPLX*/ R723RWTM PIB4. /* WAITING FOR TIMER */ R723RWO PIB4. /* WAITING FOR ANOTHER PRODUCT*/ R723RWMS PIB4. /* WAITING FOR UN-ID'D RSRC */ R723RSSL PIB4. /* WAIT FOR LOCAL CONTINUE */ R723RSSS PIB4. /* WAIT FOR SYSPLEX CONTINUE */ R723RSSN PIB4. /* WAIT FOR NETWORK CONTINUE */ +16 R723RWNL PIB4. /* WAITING FOR NEW LATCH */ @ ; FORMAT R723RFLG HEX2.;* OUTPUT T723WRSD; PTR = PTR + SMF72WRL;

Page 7

SMF723.TXT END /* WR SECTION */ ; END /* STY = 3 */ ; IF SMF72STY = 4 THEN DO; INPUT @PT SMF72CPS PIB4. /* SERVICE CLASS PERIOD DATA SECTION */ SMF72CPL PIB2. SMF72CPN PIB2. SMF72SPS PIB4. /* SWAP REASON DATA SECTION */ SMF72SPL PIB2. SMF72SPN PIB2. @ ;* OUTPUT SMF72HD;* N724 + 1;* IF N724 < 3 THEN LIST; /* SC PERIOD DATA SECTION */ PTR = SMF72CPS - 3; IF SMF72CPN > 0 THEN DO J = 1 TO SMF72CPN; INPUT @PTR R724PNAM $8. /* POLICY NAME */ R724PTM TODSTAMP8./* POLICY TIMESTAMP */ R724LCNM $8. /* SERVICE CLASS NAME */ R724PER_ PIB1. /* SERVICE CLASS PERIOD */ +3 R724USER PIB4. /* NUMBER OF USERS FOUND */ R724ACTV PIB4. /* NUMBER OF ACTIVE USERS */ R724ACTS PIB4. /* NUMBER OF ACTIVE SAMPLES */ R724IDLS PIB4. /* NUMBER OF IDLE SAMPLES */ R724PAGE PIB4. /* USERS DELAYED FOR PAGING */ R724SWAP PIB4. /* USERS DELAYED FOR SWAP-IN */ R724OUTR PIB4. /* OUT-AND-READY USERS */ R724PGIN PIB4. /* PAGE-INS */ R724DIVS PIB4. /* DIV SAMPLES */ R724LSSA PIB4. /* LOGICALLY SWAPPED SAMPLES */ R724PSSA PIB4. /* PHYSICALY SWAPPED SAMPLES */ R724UPRO PIB4. /* SAMPLES USING PROCESSOR */ R724UDEV PIB4. /* SAMPLES USING DEVICE */ R724DPRO PIB4. /* SAMPLES DELAYED PROCESSOR */ R724DDEV PIB4. /* SAMPLES DELAYED DEVICE */ R724DSTO PIB4. /* SAMPLES STORAGE DELAY */ R724DJES PIB4. /* SAMPLES JES DELAY */ R724DHSM PIB4. /* SAMPLES HSM DELAY */ R724DXCF PIB4. /* SAMPLES XCF DELAY */ R724DENQ PIB4. /* SAMPLES ENQ DELAY */ R724DMNT PIB4. /* SAMPLES MOUNT DELAY */ R724DMSG PIB4. /* SAMPLES MSG DELAY */ R724UNKN PIB4. /* SAMPLES UNKNOWN DELAY */ R724VALD PIB4. /* TOTAL VALID SAMPLES */ R724LSCT PIB4. /* "LONG" LOGICAL SWAPS */ R724ESCT PIB4. /* "LONG" SWAPS TO ES */ R724PSCT PIB4. /* "LONG" PHYSICAL SWAPS */ R724ACTF RB8. /* ACTIVE FRAMES */ R724IDLE RB8. /* IDLE FRAMES */ R724SLOT RB8. /* SLOTS USED */ R724DIV RB8. /* DIV FRAMES */ R724FIX RB8. /* FIXED FRAMES */ R724LSCF RB8. /* LOG SWAP CENTRAL FRAMES */ R724LSEF RB8. /* LOG SWAP ES FRAMES */ R724PSEF RB8. /* PHYS SWAP ES FRAMES */ R724VECT RB8. /* VECTOR TIME (USEC) */ R724ET RB8. /* ETIME (USEC), ALL COMPLETNS*/ /* (EXCL QUEUED TIME) */ R724QT RB8. /* TIME ON JES/APPC QUEUE (US)*/ R724END RB8. /* COMPLETED TRANSACTIONS */ R724TSV RB8. /* SHARED PAGE VIEWS */ R724VIN RB8. /* SHARED VALID SHARED PAGES */ R724VLC RB8. /* SHARED PAGE VALIDATIONS */

Page 8

SMF723.TXT R724GPI RB8. /* SHARED PAGE-INS FROM AUX */ @ ; FORMAT R724PTM DATETIME.;* OUTPUT T724SCPD; PTR = PTR + SMF72CPL; END /* CP SECTION */ ; /* SWAP REASON DATA SECTION */ PTR = SMF72SPS - 3; IF SMF72SPN > 0 THEN DO J = 1 TO SMF72SPN; INPUT @PTR R724OR1 PIB4. /* SAMPLES O&R DLY: TRM IPT WT*/ R724OR2 PIB4. /* SAMPLES O&R DLY: TRM OPT WT*/ R724OR3 PIB4. /* SAMPLES O&R DLY: LONG WAIT */ R724OR4 PIB4. /* SAMPLES O&R DLY: AUX SHORT */ R724OR5 PIB4. /* SAMPLES O&R DLY: RS SHORT */ R724OR6 PIB4. /* SAMPLES O&R DLY: DET LONGWT*/ R724OR7 PIB4. /* SAMPLES O&R DLY: REQ SWAP */ R724OR8 PIB4. /* SAMPLES O&R DLY: ENQ EXCH */ R724OR9 PIB4. /* SAMPLES O&R DLY: EXCH SWAP */ R724OR10 PIB4. /* SAMPLES O&R DLY: UNI SWAP */ R724OR11 PIB4. /* SAMPLES O&R DLY: TRANS SWAP*/ R724OR12 PIB4. /* SAMPLES O&R DLY: IMPRV CS */ R724OR13 PIB4. /* SAMPLES O&R DLY: IMPRV PAG */ R724OR14 PIB4. /* SAMPLES O&R DLY: MAKE ROOM */ R724OR15 PIB4. /* SAMPLES O&R DLY: APPC WAIT */ R724OR16 PIB4. /* SAMPLES O&R DLY: USS IPT WT*/ R724OR17 PIB4. /* SAMPLES O&R DLY: USS OPT WT*/ @ ;* OUTPUT T724SPPD; PTR = PTR + SMF72SPL; END /* SP SECTION */ ; END /* STY = 4 */ ; END /* RTY = 72 */ ; ELSE DELETE; RUN;

PROC SORT DATA = T723SCPD; BY ENDTS R723MCNM;

DATA _NULL_; SET T723SCPD; FILE PRINT HEADER = HEADER; LENGTH OLDSC $ 8; RETAIN NEWPAGE 0 OLDSC ' '; OLDSP = LAG1 (R723MNSP); IF R723MNSP ^= OLDSP THEN PUT _PAGE_; IF R723MCNM < OLDSC THEN NEWPAGE = 0; OLDSC = R723MCNM; IF NEWPAGE; IF R723MCPG > 0; /* EXCLUDE REPORT CLASSES */ LENGTH _DESC $ 32 TU $ 1; _DESC = RIGHT (R723MCDE); ARRAY GOALS (6) $ 12 GOAL1-GOAL6; DO J = 1 TO 6; GOALS(J) = ''; END; SELECT (GOALTYPE); WHEN ('DISC') GOALS(6) = ' DISC'; WHEN ('SPM' ) GOALS(1) = ' SPM';* 123456789012;* AVE<NNN.NNNS;* V=NN ; WHEN ('VEL' ) GOALS(R723CIMP) = ' V=' || PUT(R723CVAL,2.); WHEN ('RTAV') DO;

Page 9

SMF723.TXT LINK FIXCVAL; GOALS(R723CIMP) = 'AVE<' || PUT (R723CVAL,Z7.3) || TU; END; WHEN ('RTPC') DO; LINK FIXCVAL; GOALS(R723CIMP) = PUT (R723CPCT,2.) || '%<' || PUT (R723CVAL,Z7.3) || TU; END; OTHERWISE; END; PUT @1 _DESC $CHAR32. +1 R723MCNM $8. +1 R723CPER 1. +2 (GOAL1-GOAL6) ($14.); RETURN;

FIXCVAL: IF R723CRTF = 80X THEN DO; TU = 'S'; R723CVAL = R723CVAL / 1000; END; ELSE IF R723CRTF = 40X THEN TU = 'S'; ELSE IF R723CRTF = 20X THEN TU = 'M'; ELSE IF R723CRTF = 10X THEN TU = 'H'; IF TU = 'S' THEN DO; IF R723CVAL > 3600 THEN DO; R723CVAL = R723CVAL / 3600; TU = 'H'; END; ELSE IF R723CVAL > 60 THEN DO; R723CVAL = R723CVAL / 60; TU = 'M'; END; END; IF TU = 'M' THEN DO; IF R723CVAL > 60 THEN DO; R723CVAL = R723CVAL / 60; TU = 'H'; END; END; RETURN;

HEADER: PUT @1 'WLM SERVICE GOAL SUMMARY' // @1 'READING SMF RECORD FOR ' ENDTS // @1 'SERVICE DESCRIPTION ' R723MIDN ' = ' R723MIDD / @1 ' INSTALLED AT ' R723MTDI ' BY ' R723MIDU // @1 'IN-EFFECT SERVICE POLICY ' R723MNSP ' = ' R723MDSP / @1 ' ACTIVATED AT ' R723MTPA // @22 'DESCRIPTION SRVC_GRP P IMP=1 IMP=2 ' ' IMP=3 IMP=4 IMP=5 IMP=6' /; NEWPAGE = 1; OLDSC = R723MCNM; RETURN;

DATA A B (RENAME = (R723MCNM = RCNAME) KEEP = R723MCNM R723CSRV ENDTSQH); SET T723SCPD (KEEP = ENDTS PERFINDX R723CIMP R723CPER R723CSRV R723MCNM SYSID SMF72INT R723MSCF); ENDTSQH = '0:15:00'T * (CEIL (ENDTS / '0:15:00'T)); IF ENDTSQH - ENDTS > '00:14:00'T THEN ENDTSQH = ENDTSQH - '00:15:00'T; FORMAT ENDTSQH DATETIME.; IF R723MSCF = '1... ....'B THEN DO; IF R723MCNM =: 'BSTP' OR R723MCNM =: 'BIMS' THEN OUTPUT B;

Page 10

SMF723.TXT ELSE DELETE; END; ELSE IF R723MSCF = '...1 ....'B THEN OUTPUT A;

DATA B; SET B; SELECT (RCNAME); WHEN ('BIMSP0XX') R723MCNM = 'IMSPXN '; WHEN ('BIMST0XX') R723MCNM = 'IMSTXN '; WHEN ('BSTPP06X') R723MCNM = 'CICPMDI '; WHEN ('BSTPP0XX') R723MCNM = 'CICPXN '; WHEN ('BSTPT06X') R723MCNM = 'CICTMDI '; WHEN ('BSTPT0XX') R723MCNM = 'CICTXN '; OTHERWISE DELETE; END;

PROC SORT DATA = A; BY R723MCNM ENDTSQH;

PROC SORT DATA = B; BY R723MCNM ENDTSQH;

DATA A; MERGE A B; BY R723MCNM ENDTSQH;

PROC SORT; BY SYSID ENDTSQH R723CIMP R723MCNM R723CPER;

PROC SUMMARY; CLASS SYSID ENDTSQH; VAR R723CSRV; OUTPUT OUT = B MAX = MAXCSRV SUM = SUMCSRV;

PROC SORT DATA = B (WHERE = (_TYPE_ = 3)) OUT = B; BY SYSID ENDTSQH;

PROC SUMMARY DATA = B; CLASS SYSID; VAR SUMCSRV; OUTPUT OUT = C MAX = TOPCSRV;

DATA B; MERGE B C (WHERE = (_TYPE_ = 1)); BY SYSID; DROP _TYPE_ _FREQ_;

DATA A; MERGE A B; BY SYSID ENDTSQH; SERVINDX = R723CSRV / MAXCSRV;

PROC SORT; BY SYSID R723CIMP R723MCNM R723CPER ENDTSQH;

GOPTIONS DEVICE=GIF GSFNAME=GRAFOUT1 GSFMODE=REPLACE FTEXT=SWISS XMAX = 7IN XPIXELS = 2100 YMAX = 7IN YPIXELS = 2100 HTEXT = 10 PT COLORS = (GRAY11 GRAY22 GRAY33 GRAY44 GRAY55 GRAY66 GRAY77 GRAY88 GRAY99 GRAYAA GRAYBB GRAYCC GRAYDD GRAYEE GRAYFF);

DATA _NULL_; SET A END = EOF;

Page 11

SMF723.TXT BY SYSID R723CIMP R723MCNM R723CPER ENDTSQH; RETAIN XTOP 97 XBOTTOM 25 YTOP 97 YBOTTOM 6 CLASSES 21; RETAIN XDELTA YDELTA YRIBBON; IF R723MCNM = 'CICPMDI' THEN R723MCNM = 'CICPRDB'; IF R723MCNM = 'CICTMDI' THEN R723MCNM = 'CICTRDB'; IF _N_ = 1 THEN DO; XDELTA = (XTOP - XBOTTOM) / 96; /* WIDTH OF A 15-MINUTE INTERVAL */ YDELTA = (YTOP - YBOTTOM) / (CLASSES + 1); RC = GINIT(); RC = GRAPH('CLEAR'); RC = GSET('TEXALIGN','LEFT','BASE'); RC = GDRAW('TEXT',1,YTOP,'IMP'); RC = GDRAW('TEXT',6,YTOP,'CLASS'); RC = GDRAW('TEXT',18,YTOP,'PD'); RC = GSET('TEXALIGN','RIGHT','BASE'); RC = GDRAW('TEXT',20,YBOTTOM,'TOT SU USAGE'); RC = GSET('LINWIDTH',5); /* X-AXIS RUNS FROM XBOTTOM (= 00HOURS) TO XTOP (= 24HOURS) */ RC = GDRAW('LINE',2,XBOTTOM-2,XBOTTOM-2,YBOTTOM,YTOP); /* Y-AXIS RUNS FROM YBOTTOM TO YTOP */ RC = GDRAW('LINE',2,XBOTTOM-2,XTOP,YBOTTOM,YBOTTOM); RC = GSET('TEXALIGN','CENTER','BASE'); RC = GDRAW('TEXT',XBOTTOM-6,2,'HOUR'); RC = GDRAW('TEXT',XBOTTOM, 2,'0'); RC = GDRAW('TEXT',XBOTTOM + (XTOP-XBOTTOM)/6,2,'4'); RC = GDRAW('TEXT',XBOTTOM + 2*(XTOP-XBOTTOM)/6,2,'8'); RC = GDRAW('TEXT',XBOTTOM + 3*(XTOP-XBOTTOM)/6,2,'12'); RC = GDRAW('TEXT',XBOTTOM + 4*(XTOP-XBOTTOM)/6,2,'16'); RC = GDRAW('TEXT',XBOTTOM + 5*(XTOP-XBOTTOM)/6,2,'20'); RC = GDRAW('TEXT',XTOP, 2,'24'); YRIBBON = YTOP; SUPPRESS = 'N'; END; IF NOT (FIRST.ENDTSQH AND LAST.ENDTSQH) THEN DO; IF FIRST.ENDTSQH THEN DO; HOLDSI = SERVINDX; HOLDPI = PERFINDX; SUPPRESS = 'Y'; RETAIN SUPPRESS; END; ELSE DO; HOLDSI = MAX (HOLDSI, SERVINDX); IF HOLDSI = SERVINDX THEN HOLDPI = PERFINDX; END; IF LAST.ENDTSQH THEN DO; SERVINDX = HOLDSI; PERFINDX = HOLDPI; SUPPRESS = 'N'; END; END; IF FIRST.R723CPER THEN DO; YRIBBON = YRIBBON - YDELTA; RC = GSET('TEXALIGN','LEFT','BASE'); XSTR = PUT (R723CIMP, 1.); RC = GDRAW('TEXT',1,YRIBBON,XSTR); RC = GDRAW('TEXT',6,YRIBBON,R723MCNM); XSTR = PUT (R723CPER, 1.); RC = GDRAW('TEXT',18,YRIBBON,XSTR); END; XRIBBON = XBOTTOM + XDELTA * (TIMEPART (ENDTSQH) / '00:15:00'T);

IF SUPPRESS = 'N' AND SERVINDX > 0 THEN DO; YHEIGHT = SERVINDX * YDELTA / 2;

Page 12

SMF723.TXT IF YHEIGHT < 0.25 THEN YHEIGHT = 0.25;

IF 0.6 < PERFINDX < 1.4 THEN DO; RC = GSET('FILTYPE','HOLLOW'); RC = GSET('FILCOLOR',1 ); END; ELSE IF PERFINDX < 0.6 THEN DO; RC = GSET('FILTYPE','SOLID'); RC = GSET('FILCOLOR',12); END; ELSE DO; RC = GSET('FILTYPE','SOLID'); RC = GSET('FILCOLOR',1 ); END; RC = GDRAW('BAR',XRIBBON, YRIBBON + 1 - YHEIGHT, XRIBBON + XDELTA, YRIBBON + 1 + YHEIGHT); IF RC ^= 0 THEN PUT 'BAR' _ALL_; END; IF R723MCNM = 'SYSTEM' THEN DO; YHEIGHT = (SUMCSRV / TOPCSRV) * YDELTA; RC = GSET('FILTYPE','SOLID'); RC = GSET('FILCOLOR',1 ); RC = GDRAW('BAR',XRIBBON, YBOTTOM, XRIBBON + XDELTA, YBOTTOM + YHEIGHT); IF RC ^= 0 THEN PUT 'BAR' _ALL_; END;

IF EOF THEN DO; RC = GRAPH('UPDATE'); RC = GTERM(); END;

Page 13