3.

2 Strobe
Created By:
Nancy T Love on 11/04/98 at 03:53 PM
Category: Chapter 3. Tuning Tools

STROBE10 is a vendor program product licensed by American Express for use in determining where and
how time is spent in online subsystems or batch processing programs. In the realm of application
software efficiency, STROBE represents a detailed microscope within the performance tuners bag of
tricks. At completion of its data gathering step, STROBE produces a collection of reports that help you
determine where and how to revise a program or subsystem application to improve its throughput
efficiency. Due to feature additions to the base product licensed by American Express, STROBE can
show information specific to CICS, DB2, and IMS subsystems when they are used within the application
program monitored.
Executing a complete STROBE analysis session is a two or three step process, depending on whether
the Index function is utilized. The Index feature obtains address information from source language
compiler listing output, producing a map data set that relates programmer assigned procedure names and
statement numbers to addresses. This feature assists in the effort to locate high CPU time-consuming
portions of application program code by labeling addresses with the source code procedure names and
references. STROBE contains the Index feature and JCL procedures to support programs written in
COBOL, PL/I, FORTRAN, IBM C/370, SAS/C, Assembler language, Natural programs, and CA-IDMS
dialogs. If other data collection tools are available, STROBE can supplement its reports with that
information. Detailed information on how to use the Index feature and other special STROBE features
can be found in the *STROBE: Users Guide and the CICS, DB2 and IMS features guides.
APMpower is a workstation product designed to facilitate STROBE. In addition to initiating all of
STROBE's functionality from a PC/3270 session, it provides a graphic interface with drill-down capability,
insight to system utility (SVCs) through program descriptions and performacne improvement guidelines,
and DB2 SQL statement interactive tuning. There are a limited number of individual PC licenses for
APMpower. If your application group would like to apply for one, contact Mohammad R Alba (as noted in
the Introduction section of this manual).
*NOTE:
The lastest release of STROBE supports IBM's MVS on-line documentation system, Bookmanager.
These manuals are there.

~~~~~~~~~~

10 Programart Corporation (now a part of Compuware Corporation)

...........................

3.2.1 Basic Analysis Procedure and Reports

Created By:
Nancy T Love on 11/04/98 at 03:57 PM
Category: Chapter 3. Tuning Tools

Basic Analysis Procedure and Reports

For this discussion, well stick to the standard analysis procedure which requires only two steps. The first
step is to run the object program with a STROBE session activate (attached to it). STROBE routines
sample the application program execution by outputing program address and file activity into a sample
data set. The second step of the process is to run the STROBE Report program to analyze the sample
data. The resulting reports are called the STROBE Performance Profile and they can be directed either to
the TSO ISPF screen or sent to a printer for hardcopy. The output made up of many different report
sections. Figure 6 lists all the available report sections with a brief description of each. Note that some
reports are for specific types of monitoring sessions and will not always appear in a complete
Performance Profile.
Figure 6. Summary of STROBE Performance Profile Reports
Measurement Session Data Report Presents a description of the job environment, measurement parameters,
measurement statistics, and report parameters.
Time Distribution of Activity Level Displays a chronological record of the level of task execution and file access
Report
activities throughout the measurement session.
Resource Demand Distribution
Summarizes the usage of CPU and I/O facilities by programs executing in the
Report
measured job step.
Working Set Size Through Time
Displays a chronological record of the variations in active working set size within
Report
the address space throughout the measurement session.
Wait Time by Module Report
Identifies the modules in which the measured job step entered a wait state,
voluntarily or otherwise, and the aggregate duration of the wait in each module.
Data Set Characteristics Report
Shows the access method, record size, block size and number of buffers for each
data set accessed by programs executed in the measured job step and the
number of accesses made to each data set. If the access method is VSAM, the
report shows hiperspace buffers, the number of Request Parameter List (RPL)
strings and the number of control area and control interval splits. The report also
shows the Local Shared Resources (LSR) pool number if the data set participated
in one.
VSAM Local Shared resources
Shows information about buffer pools and is organized by LSR pool number.
Pool Statistics Report
I/O Facility Utilization Summary
For each device used by programs executed in the measured job step, this report
Report
shows the percentage of full utilization achieved during the measurement session.
Most Intensively Executed
Shows the ten procedures that used the greatest amount of CPU time.
Procedures Report
Most Extensive Inactive Storage
Identifies the ten largest areas of loaded executable code in which STROBE
Areas Report
detected no execution. This report appears only if it is specified; it is suppressed
by default.
Program Section Usage Summary Summarizes the CPU use for each control section of each load module executed
Report
in the measured job step.
Transaction Usage Summary
For transaction processing subsystems this report shows the CPU time used by

Report
Program usage by Procedure
Report
Transaction Usage by Control
Section Report

each transaction type processed during the measurement session.

Details the CPU time spent within each procedure of the programs executed in the
measured job step for system modules and user written modules.
For transaction procession subsystems this report details the CPU time spent by
each transaction type processed during the measurement session. The report is
organized by control section within module.
DASD Usage by Cylinder Report
Presents a detailed record of the time spent accessing each cylinder of each direct
access device used by programs executing in the measured job step.
Attribution of CPU Execution Time Identifies those portions of use code that are responsible for invoking system
and Attribution of CPU Wait Time
service routines (SRB CPU time)
Reports
Subsystem Attribution Reports
Special STROBE features produce attribution reports specific to the subsystem
they support.

...........................

3.2.2 How to Submit a Measurement Request

Created By:
Nancy T Love on 11/11/98 at 08:25 PM
Category: Chapter 3. Tuning Tools

How to Submit a Measurement Request

The STROBE ISPF based screens can be accessed via one of two methods. The first
method, standard on most IPC complexes, is to start with the main ISPF menu and enter
the following:
WB Workbench
WE - Programming Tools
10 - STROBE
If these menu items are not available to you, STROBE can also be invoked by going to
ISPF option 6 and entering the command STRLBDEF (roughly STRobe LiBrary DEFinition).
Either method should produce the same results and you will be presented with the main
STROBE menu as shown in Figure 7.

Figure 7. STROBE Primary Options Screen

------------------------------------------ STROBE OPTIONS
-------------------------------------------------------------Ver 1 Rel 9.4
OPTION ===>
-------------------------------------------------------------------------------------------------- PTF
LEVEL FS00775
0
1
2
3
4
5
6
M
L
T
C

USER DEFAULTS
ADD ACTIVE
ADD QUEUED
STATUS
PROFILE
INDEX
CROSS-SYSTEM
MESSAGES
LOG UTILITY
TUTORIAL
CHANGES

STROBE/ISPF user default options

Add a measurement request for an executing job
Add a measuremnt request for a job not yet executing
Monitor/change measurement requests and create profiles
Create a Profile of a STROBE measurement ssession
Create a map data set
Submit control requests on another system in the complex
Display information about a STROBE message
Perform STROBE log utility function
Display information about STROBE
Display summary of chnages in this release

EXIT

Terminate STROBE/ISPF
STROBE is a registered trademark of PROGRAMART
CORPORATION

STROBE is a CPU localized software product; it does not communicate between different
CPUs in a multi-CPU complex. Measurement requests must be queued to the same CPU
on which the application program to be analyzed will be executed. In cases where it is
impossible to foretell which CPU will execute a batch job to be analyzed, measurement
requests will have to be queued to each CPU in the complex (i.e. DIPA, DIPB and DIPC on
the IPC West complex). After the batch job step being measured has completed execution
the remaining queued requests on the other CPUs may be cancelled. Measurement
requests may be queued, modified, cancelled or profiled to/from CPUs other than the one
that you are currently logged on to by using one of two different methods.
1.

Logoff the current CPU and logon to each CPU in the complex one at a time to
perform the needed measurement request action(s).

2.

Use option 6 CROSS-SYSTEM from the STROBE main menu to cause batch jobs
to be created to perform the desired request function(s). In this case the terminal
operator is given the opportunity to supply a CPU routing statement (/*ROUTE XEQ
cpuid) on the jobcard to cause the requested action to execute on the appropriate
system.

Regardless of which one is used, separate actions are needed to establish a measurement
request on each CPU to cover the situation where it is not known which CPU will execute
the target job/step. For most cases it is likely that the second method will be the easiest to
use. Figure 8 shows the options menu which is presented when item 6 is selected from the
main menu to work with cross-system options.

Figure 8. STROBE cross-system request screen

------------------------------------------ STROBE OPTIONS - CROSS SYSTEM

OPTIONS
OPTION ===>
---------------------------------------------------------------------------------------------------------------------------------1
2
3
4
5
6

ADD ACTIVE
ADD QUEUED
CHANGE ACTIVE
CHANGE QUEUED
LIST/DELETE
JOB STREAM MENU

Add a measurement request for an executing job

Add a measuremnt request for a job not yet executing
Send a sampling control command to an active request
Change a queued measurement request
Display/delete measurement requests
Process the generated job stream

END

CANCEL

Exit without submitting the generated job stream

To request the start of a new measurement session use options 1 or 2 from the main menu
or the cross system options menu. From either menu, option 1 will create an active
measurement session for an already executing application program. Selecting this option
will present you with a screen that requires you to enter the JOBNAME, the desired length
of the STROBE monitoring session in minutes and the number of samples STROBE should
take. When the number of samples and the length of the monitoring session have been
reached the STROBE session will end.
In most cases involving batch jobs it is desirable to have the STROBE monitoring session
active for the entire duration of the targeted step within a job. In order to accomplish this a
queued request should be generated before the job to be monitored is started. This is
performed by selecting option 2 from either of the menus discussed above and results in
the display of the screen shown in Figure 9.

Figure 9. STROBE screen for adding a new analysis request

---------------------------------------------STROBE - ADD QUEUED REQUEST -------------REQ# 24 QUEUED

COMMAND
===>-----------------------------------------------------------------------------------------------------------------JOBNAME ===> THISJOB
PROGRAM ===> ---------------or STEP SPECIFICATION ===> THATSTEP
(Name, number, or step.procstep)
MEASUREMENT SESSION INFORMATION:
SESSION DURATION
===> 180
(Estimated time in minutes)
TARET SAMPLE SIZE
===> 10000 (Target number of samples)
TSO USERID TO NOTIFY

===> PLXS

(Notify when session completes)

SAMPLE DATA SET INFORMATION

DATA SET NAME PREFIX ===> STROBE
UNIT NAME ===> SYSDA VOLUME ===> ------ DISP ===> CATLG (CATLG
or KEEP)
SELECT ADDITIONAL PARAMETERS: (Y or N; Use Y only when overriding
defaults)
DATA COLLECTORS
===> N
MODULE MAPPING DATA
===> N
SESSION MANAGEMENT ===> N
OTHER PARAMETERS
===> N

To add a queued request, all information required for an active request must be supplied
with the addition of JCL procedure and/or step names. In the example screen displayed in
Figure 9 several fields have been filled out to demonstrate the creation of a queued
monitoring request. The jobname selected was THISJOB and step name THATSTEP was
specified inferring the absence of a JCL procedure name. Also, the TSO userid of PLXS
was entered and will be provided a notification when the STROBE measurement session
has ended. A session duration of 180 was given to indicate that the target job step is
expected to execute for approximately 3 hours. The session duration value and the default
target sample size value of 10,000 will be used by STROBE to determine what the initial
sampling rate should be. After providing information required by this screen the ENTER key
is pressed and the request is queued and assigned a request number as shown in the
upper right hand corner of the screen.
Warning

Always use STROBE as the data set name prefix for the sample data set. Any other high level qualifier may cause the S
session to fail RACF authority when creating the sample data set.

The STROBE Central Version facility maintains information about all active, queued and
completed measurement sessions. The STROBE request status screen shown in Figure
10 is accessed by specifying option 3 from the main menu (Figure 7). Cross-system
request numbers can be determined by specifying option 5 from the cross system options
menu (Figure 8). Caution should be exercised not to confuse duplicate monitoring session
request numbers within a complex. Request numbers assigned by STROBE are unique
only within each CPU.
Information which is displayed on the monitoring sessions status screen can be filtered so
as to display a subset of the total outstanding requests in a given CPU. To set up the
desired filtering, option 0 from the main menu should be selected to bring up the User
Default Options screen. The second option from this screen, STATUS MASK, will cause a
screen to be displayed where filtering criteria can be entered based on the ownerid
associated with each request.
Figure 10. STROBE queued requests status screen

--------------------------------------------------------- STROBE - STATUS ---------------------------------------------------------COMMAND ===>----------------------------------------------------------------------------------------------- SCROLL ===> PA

V
Q

=View
=Quit

C
D

=Change
=Delete

P
X

=Profile Report
=Delete with Data sets

=default Profile

-----------------------------------------------------------------QUEUED MEASUREMENT REQUESTS--------------------------------------------------------------REQ# -OWNERID- -ACTJOBNAME-PROGRAM-STEPNAME/STEPNUM

-TARGET
-DURATION
-RESPO
7 BESW
VSTRMFC
CACHSTAT
10000
180
CONTI
11 RCXS
TMD030
STEP2.STEP030
10000
180
CONTI
13 GHSW
CRC020
STEP2.STEP010
10000
180
CONTI
24 PLXS
THISJOB
THATSTEP
10000
180
CONTI

---------------------------------------------------------------COMPLETED MEASUREMENT REQUESTS----------------------------------------------------------REQ# -OWNERID- -ACTJOBNAME-PROGRAM-STEPNAME/STEPNUM

-TARGET
TOTAL- --EXEC
4 MYLS
RFM127
*
10000
10000
211
5 PA1234A
FWD3002
*
10000
10000
719
6 GHSW
JSM010
*
10000
10000
21

Several different options can be specified on this screen for working with the status and
characteristics of individual measurement session requests. Online help text screens are
available for descriptions of the various options or the STROBE: User's Guide may be
consulted.

...........................

3.2.3 Requesting Performance Profile Reports

Created By:
Nancy T Love on 11/16/98 at 03:30 PM
Category: Chapter 3. Tuning Tools

Requesting Performance Profile Reports

When a measured application program or batch job step has completed execution, the STROBE session
shows up on the status screen in the bottom section titled Completed Measurement Requests. This
screen (Figure 10) is the best place to start when requesting profile reports if you are logged on the same
CPU where the measurement session executed. Place the letter P on the line corresponding to the
desired measurement request. After pressing the ENTER key the screen displayed in Figure 11 will
appear with the sample data set name field filled in for you. If you already know the name of the sample
data set, it is possible to access this screen directly from the main menu by using option 4.
Figure 11. STROBE Options Screen for Requesting Performance Reports
------------------------ STROBE - PRODUCE A PERFORMANCE PROFILE
-----------------------------------OPTION ===>
-------------------------------------------------------------------------------------------------------------B - Background processing

F - Foreground processing

ENTER BLANKS TO VIEW A DATASET SELECTION LIST

SAMPLE DATA SET NAME ===> 'STROBE.THISJOB.S001D001'--------------------------------UNIT ===>
VOLUME ===> -----SPECIFY PROFILE REPORT PARAMETERS: (Y or N)
Detail Reports ===> N
Tailor Reports ===> N
N

Indexing ===>

PROFILE REPORT FORMAT ===> W ((W)ide or (N)arrow)

NUMBER OF COPIES FOR BACKGROUND REPORTS ===> --Specify a data set name to save a copy of the STROBE Profile Report:
DATA SET NAME ===>
'PLXS.THISJOB.STROBE'---------------------------------------------------UNIT ===> SYSDA
VOLUME ===> -----Specify a SYSIN data set containing parameters for the Reporter:
DATA SET NAME ===> ------------------------------------------------------------------------------------From this screen you can request that a performance profile be produced in the foreground (displayed on
the terminal) or the background (hardcopy report). The report parameters options cause additional
screens to be displayed which allow you to request other specialized reports or to compress parts of
standard reports to reduce report sizes. These options can be quite detailed and are beyond the scope of
this document. The STROBE: Users Guide should be consulted if additional information is desired. For
standard profile report leave these three fields set to N.

...........................

3.2.4 Key Elements of a Measurement Profile Report

Created By:
Nancy T Love on 11/16/98 at 03:39 PM
Category: Chapter 3. Tuning Tools

Key Elemens of a Measurement Profile Report

We've already listed all the various STROBE reports in Figure 6 that are possible to be produced from a
profile report request. Some of the reports will not be produced unless special options are requested.
There are two reports that are produced during a normal profile report execution that we consider to be
the most important sources of quick information. These represent the best places to start when
interpreting the results of a measurement session. In this section we will point out some of the more
important fields on these two different reports and discuss the meaning of the values they present.
Figure 12. STROBE Measurement Session Data Report Example
STROBE* PERFORMANCE PROFILE
PAGE 1

$$$$$$$$$$
$$$$$$$$$$$
$$$$$
$$$$$$$$$
$$$$$$$$$
$$$$$
$$$$$$$$$$$
$$$$$$$$$

DFSRRC00

06/27/96

$$$$$$$$$$$$
$$$$$$$$$$$
$$$$$$$$
$$$$$$$$$
$$$$$$$$$$$
$$$$$$$$$$$$
$$$$$$$$$$$$
$$$$$$$$$$$$$
$$$$$$$$$$$
$$$$$$$$$$$
$$$$$
$$$$$ $$$$$ $$$$$
$$$$$ $$$$$ $$$$$ $$$$$
$$$$$
$$$$$ $$$$$ $$$$$
$$$$$
$$$$$$$$$$$
$$$$$$$$$$$
$$$$$
$$$$$$$$$$$
$$$$$
$$$$$
$$$$$$$$$$
$$$$$$$$$$$
$$$$$
$$$$$$$$$$$
$$$$$
$$$$$
$$$$$ $$$$$ $$$$$
$$$$$
$$$$$ $$$$$
$$$$$$$$$$$$$
$$$$$$$$$$$$ $$$$$$$$$$$
$$$$$
$$$$$
$$$$$
$$$$$$$$$$
$$$$$$$$$$$
$$$$$$$$$$$

--------------

-------

-------------

JOB

MEASURME

MEASUREM

ENVINRON

NT

ENT

MENT

PARAMETER

STASTICS

----------------

S ------------

PROGRAM MEASURED

DFSRRC00

JOB NAME

CRC020

JOB NUMBER

JOB19843

-------------

ESTIMATED SESSION TIME

240 MIN

CPS TIME PERCENT -

TARGET SAMPLE SIZE

15,000

WAIT TIME PERCENT

REQUEST NUMBER

(q)

20.29
-

79.71

RUN MARGIN OF ERROR

.70

PCT
STEP NAME

STEP2.STEP

CPU MARGIN OF ERROR

010

DATE OF SESSION

06/21/96

TIME OF SESSION

07.43.35

1.55

PCT

SUBSYSTEM

IMS DLB 4.1

TOTAL SAMPLES TAKEN

19,592

TOTAL SAMPLES

19,592

PROCESSED
CONDITION CODE

SYSTEM -

C-0000

ESA SP5.1.0

INITIAL SAMPLING RATE

1.04/SEC

FINAL SAMPLING RATE

1.04/SEC

----------------- REPORT
PARAMETERS -----------------

CPU MODEL

9021-9X2

SYSTEM ID

DIPB

REGION SIZE BELOW 16 M

7,148K

REGION SIZE ABOVE

131,072K

SESSION TIME REPORT RESOLUTION

64 BYTES

SORTSIZE

999,999

LINES/PAGE

60

DASD 2.8%
PTF LEVEL STROBE TAPE NUMBER

CPU TIME -

333 MIN

7.48 SEC

56 MIN

16.86 SEC

WAIT TIME

220 MIN

37.29 SEC

STRETCH TIME

56 MIN

13.33 SEC

SRB TIME

2 MIN

21.61 SEC

OUT-

9.4.840/775
-

000-

PAGES IN -

S94669
PAGING RATE
EXCPS

0.00/SEC

1,575,719

89.94/SEC

SAMPLE
DATA SET
-STROBE.CR
C020.S002D0
01

*STROBE
IS LICENSED
BY
PROGRAMA
RT FOR USE
BY
AMERICAN
EXPRESS,
WEST
BEHREND
DRIVE

...........................

3.2.4.1 Measurement Session Data

Created By:
Nancy T Love on 11/17/98 at 08:41 PM
Category: Chapter 3. Tuning Tools

Measurement Session Data

The Measurement Session Data report is the first section printed in a profile report. An example of this
report from a measurement session conducted on batch job CRC020 is shown in Figure 12. Information
on this one-page report is presented as three column groupings. The first, left most column contains
general session information which should be used to verify that the correct job and job step have been
measured. You did specify the step and procstep names correctly on the Add Queued Request screen
(Figure 9) didn't you?
The middle column presents control information which is specific to this measurement session. Of
particular importance is the presence of the SUBSYSTEM field which indicates that STROBE has detected
the involvement of an IMS 4.1 subsystem during the measurement phase. As a result, STROBE will
automatically include special Subsystem Attribution Reports in the output listing that contain information
specific to IMS applications.
OKnow we get to talk about some of the cool stuff! The right most column of information contains three
fields which should always be reviewed first when reading a performance profile. Together they provide
the best first look at the overall execution of the measured job step/application program. This is where we
can catch a glimpse of the forest before we get down to tree level analysis.
CPS TIME PERCENT is the percentage of total run time during which the CPU was in use by application
tasks executing within the measured job step. A high percentage value in this field is an indication that a
job step is CPU bound and should alert you to focus attention on the CPU reports within the
measurement profile.
WAIT TIME PERCENT is the opposite of the CPS Time Percent field and represents the percentage of
total run time where the CPU was not in use. A high wait time percentage is an alert that focus should be
made on the wait time reports within the profile.
STRETCH TIME represents a concept that is sometimes tough to grasp. It is the estimated amount of
time that the CPU was unavailable to process programs executing in the address space being measured
because of demands by higher priority address spaces and by SRB processing time for all address
spaces. A simpler way to think of this is that the higher this value, the greater the contention level there
was from other workloads during the measurement interval. Another point to keep in mind, however, is
that the CPU time consumed by the STROBE measurement task itself is included in this value.
Consideration should be given to the interplay among these three values, especially as they are related to
the total session time. The various combinations in the magnitude of these indicators helps to direct
decision making choices in logical diagnostic processes as we will see in Figure 14. Is the STRETCH
TIME close to or much smaller than the WAIT TIME? Is the WAIT TIME PERCENT more than 80%?
Although you will not find many answers on the Measurement Session Data report, it is the place to go to
find the correct questions.

...........................

3.2.4.2 Time Distribution of Activity Level

Created By:
Nancy T Love on 11/17/98 at 08:47 PM
Category: Chapter 3. Tuning Tools

Time Distribution of Activity Level

This measurement profile report section can be seen as the first half of the second page in our example
analysis. It is shown in Figure 13 and appears somewhat like a horizontal bar graph. Although it seems
rather complicated, it is in fact quite simple to read and represents another forest overview location for
gathering information.
The chart represents the distribution of processing activity (CPU and I/O) over the duration of the
measured interval as a horizontal scale with 100 graduations. Each segment represents 1% of the
measurement session. Therefore, any one point on the chart corresponds to the execution of a task or
file access activity during a particular one-hundredth of the measurement session, expressed as a
proportion of all activity during that segment. STROBE rounds the values and represents them as one of
the following:
"*" indicates activity greater than 95%
a single-digit entry indicates the activity percentage in tens
"-" indicates activity less than 5% but greater than zero
a blank indicates no activity
The report limits the number of task entries to six and the number of file access activities to eleven. If
there are more than six active tasks or eleven active files, STROBE groups the least active in an entry
labeled .OTHER. Also, the report combines file access operations that STROBE cannot attribute to a
specific file access activity (such as OPEN and CLOSE activities) in a separate entry labeled .FILEMGT. If
their collective activity is low, STROBE may include them in the .OTHER line entry instead.

...........................

3.2.4.3 Resource Demand Distribution

Created By:
Nancy T Love on 11/17/98 at 08:51 PM
Category: Chapter 3. Tuning Tools

Resource Demand Distribution

Shown as the second half of the example report page in Figure 13, the Resource Demand Distribution
section summarizes the use of CPU and I/O resources in the measured job step. STROBE bases all
percentages of resource use on the total run time. The tasks and resources listed are the same as those
in the Time Distribution of Activity Level report and are listed in order of decreasing solo activity, as
indicated by the values shown in the column headed SOLO IN EITHER.
This report section is usually the first place you should start once youre ready to bring analysis of the
measurement data down to the tree top level. There are many characteristics regarding the execution of
the measured job step or task which can be learned from the Resource Demand Distribution section,
such as which files incurred the most wait time due to I/O operations and the presence of abnormal CPU
utilization on behalf of file accesses. For further descriptions on any of the report fields, consult Chapter
4, The STROBE Performance Profile, in the STROBE: Concepts and Facilities guide.
Figure 13. STROBE Resource Demand Distribution Report Example
STROBE* PERFORMANCE PROFILE
6/28/96

DFSRRC00

PAGE

** TIME DISTRIBUTION OF ACTIVITY LEVEL **

TASK OR

RESOURC

N X 10 PLUS OR MINUS 5 IS PERCENT OF FULL UTILIZATION

GREATER THAN 95% - IS LESS THAN 5%

DDNAME

* IS

.------------------------------------------------------------------------------------------------------------------------------------------------------------------.

DFSRRC00

CPU

.-

12111122122332211112122221221112113221221111222222212123333111
21121122222122112222222233132232222.
DB6077

3390

12223322333223332333333343431134333323332221222233322223432234
444444444433343222133232322322222343.
DB6451

3390

12112222322323334343333333332221232222233224333322223312112121
111111111211222132333232221223323322.
DB8856

3390

.21331112-

DB6451X

3390

DB6877X

3390

DB2440

3390

GSM0600O

3490

GSM0650O

3490

GSM0652O

3490

----

- -

- --

-441-----11----2221
--3121 -11-11-21-11

-.

. -1--11-111----1-11111111111----1-11-1------------------------- ------------ -------1--111---1--------.

. ---------1------------ --------1-1---1---1----1121---1----11-----1----11111-----1-------------------.

. 11111111-------- - - -------111--------1---------- - ---- - 11---11------ --- - ---- -------- .

. ---1-1 -- 1------1 -1---- -- ----------11---- ---11--1---1---1--1-------11----1--------------121-----1.
. ------------------- -------1------1------- --- ----------1- -12122-11- ---------- --------- ----1.
. ------1- ---------------- ----- -1---------------11-111-------- --- ----------11-111121-1---11--.

.FILEMGT
OTHER

.32- -- --------- -- ----- -- ---- - - -- - -------- ---1------ ------- ----- ----- ------ --- I/O

.-1111112111212112111-111111111-

11111111111111211111211222212221111111311111111122111112112112
111122.

0 ------ 0 ------ 1 ------ 1 ----- 2 ----- 2 ----- 3 ----- 3 ----- 4 ----- 4 ----- 5 ----- 5

----- 6 ----- 6 ----- 7 ----- 7 ----- 8 ----- 8 ----- 9 ----- 9 ----- *

0 ------ 5------ 0 ------ 5 ----- 0 ----- 5 ----- 0 ----- 5 ----- 0 ------ 5 ----- 0 ----- 5
----- 0 ----- 5 ----- 0 ----- 5 ----- 0 ----- 5 ----- 0 ----- 5 ----- *
START RUN

PERCENT OF ALLOCATED RUN TIME

END RUN

** RESOURCE DEMAND DISTRIBUTION **

TASK OR

RESOURCE

DDNAME

SERVICED

SERVICED

SERVICED

SOLO

SOLO

SOLO

CAUSING

SOLO

CAUS

BY CPU

BY I/O

BY EITHER

IN CPU

IN I/O

IN EITHER

CPU WAIT

TIME

CPU W

DFSRRC00

CPU

16.58

.00

16.58

14.43

.00

14.43

8.26

14.43

DB6077

3390

.42

26.16

26.58

.38

24.18

24.57

26.12

39.00

DB6451

3390

.27

20.87

21.10

.20

19.65

19.88

20.75

58.88

DB8856

3390

.17

4.73

4.89

.16

4.67

4.83

4.73

63.71

DB6451X

3390

.15

3.10

3.24

.12

2.97

3.10

3.03

66.81

DB6077X

3390

.33

2.51

2.84

.29

2.36

2.65

2.51

69.46

DB2440

3390

.29

1.99

2.27

.23

1.88

2.11

1.98

71.57

GSM06000

3490

.00

292

2.92

.00

1.52

1.52

1.49

73.09

GSM06500

3490

.00

2.49

2.49

.00

1.41

1.41

1.35

74.50

GSM06520

3490

.00

2.56

2.56

.00

1.40

1.40

1.41

75.910

.19

1.24

1.43

.16

1.23

1.39

2.24

77.29

1.90

9.65

11.55

1.69

5.71

7.40

5.85

84.69

.FILEMGT
OTHER

I/O

*STROBE IS LICENSED BY PROGRAMART FOR USE BY AMERICAN EXPRESS, WEST BEHREND DRIVE

We have previewed the first three sections of a STROBE measurement profile report. These three
sections are always printed for all measurment profile report requests and are usually the best place to
start when reviewing measurement results. Now let's take a look at a general process map to follow
when diagnosing the results of a measurement profile.

...........................

3.2.5 Organizing A Measurement Profile Analysis

Created By:
Nancy T Love on 11/17/98 at 09:55 PM
Category: Chapter 3. Tuning Tools

Organizing A Measurement Profile Analysis

The STROBE Performance Profile is a collection of reports that shows how a target program uses system
resources. The complete profile is generated from one measurement session. Each of the reports in the
profile shows a different aspect of resource usage. Analyzing these reports helps you to pinpoint areas of
code that are responsible for consuming CPU as well as the files or processes that cause wait. In

addition to providing feedback on how application programs affect system resources, the profile can
indicate instances in which system activity is inhibiting application program performance. The profile can
also serve as a learning tool, guiding your development of application programs so that they use
resources efficiently.
The flowchart shown in Figure 14 provides a path that many analysts find useful in locating opportunities
to improve performance. Note that the chart focuses on decreasing either CPU consumption or time
spent waiting for resources to become available. The STROBE Performance Profile contains specific
report sections that will enable you to follow either path or both of them.
Figure 14. STROBE Performance Profile Interpretation Flowchart
MEASUREMENT SESSION DATA

VALID
PROFILE?

YES

MEASUREMENT SESSION DATA

CPU

WHATS
USING
CPU?

WAIT

CPU OR
WAIT?

PROGRAM SECTION USAGE SUMMARY

WHATS
USING
WAIT?

RESOURCE DEMAND
DISTRIBUTION

INTERNAL
CONTENTION?

YES

REDUCE
CONTENTION

TIME DISTRIBUTION OF ACTIVITY LEVEL

I/O FACILITY UTILIZATION SUMMARY

NO

OVERHEAD?

YES

AVOID

FILES?

YES

PROGRAM USAGE BY PROCEDURE

ATTRIBUTION OF CPU EXECUTION
MOST INTENSIVELY EXECUTED PROCEDURES

YES

.FILEMGT?

YES

REDUCE
ACCESS

DATA SET CHARACTERISTICS

I/O FACILITY UTILIZATION SUMMARY
DASD USAGE BY CYLINDER
DATA SET CHARACTERISTICS SUPPLEMENT
VSAM LSR POOL STATISTICS

NO

NO

SOURCE
CODE?

HIGH
PHYSICAL
ACCESS?

YES

REDUCE .FILEMGT
WAIT TIME BY MODULE
TIME DISTRIBUTION OF ACTIVITY LEVEL
I/O FACILITY UTILIZATION SUMMARY
ATTRIBUTION OF CPU WAIT TIME

IMPROVE

USING INDEXED PROFILE OR COMPILE LISTING

PROGRAM USAGE BY PROCEDURE

NO

TASK WAIT?

YES

REDUCE TASK WAIT

WAIT TIME BY MODULE
ATTRIBUTION OF CPU WAIT TIME

Note: This chart was copied from the STROBE: Concepts and Facilities guide, Chapter 5:
Interpreting the STROBE Performance Profile, (C) Programart Corporation.
We made it! We've gone through the STROBE analysis process from monitoring request creation to
profile report generation. Now, let's tidy up this discussion with a few final points and recommendations
regarding the use of this powerful performance analysis tool.
For detailed application program reviews it is very helpful to have a compile listing handy. For COBOL
programs the compile should be executed with the PMAP or LIST options active to force the
production of an assembler translation listing of the program. You will find this listing quite useful
even if you do not program in assembler and the Performance Management group will require it when
asked to assist with the review of an application program.
For each activity reported in a performance profile STROBE shows percentages for both total and
solo resource usage time. The difference between these two values represents an elusive concept,
but an important one to understanding performance problems. The total time percentage represents
all the time during which the activity (I/O processing, CPU time, SRB time, etc.) used a resource.
Solo time is the percentage of time during which one and only one activity was progressing for the
measured job step. The focal issue is the degree to which activities execute concurrently within the
computer system.

Let's use a simple example to clarify this concept. Assume that we have a single program (no
subprograms) which is reading a large flat file sequentially. In most cases we would like to see a
significant difference between solo time and total time spent in processing I/Os to the input file/data
set; not necessarily huge, but significant. A significant difference could show good buffering
performance, indicating that the program is accomplishing other work concurrently with access
method I/O operations. On the other hand, if solo I/O time is almost as high as, or equal to, total I/O
time, this would indicate a possible bottleneck presented by the I/Os to the large flat file. Some type of
optimization of the data set or improved buffering would be called for by this situation.
When requesting STROBE measurement sessions specify between 10,000 (default) and 15,000
samples. Very high sample numbers add greatly to CPU time overhead and do not increase report
accuracy.
Do not STROBE programs that issue OS checkpoints as requested by the JCL parameter
CHKPT=EOV. Executing a STROBE session against one of these will cause the object program to
stop taking checkpoints. It is, however, acceptable to initiate an active STROBE session for a portion
of the execution of one of these program types; perhaps for 15 minutes within the middle of a job step
for example. In this case, the program will resume taking checkpoints when the STROBE session is
ended.
Note: IMS checkpoints are compatible with STROBE and will not be affected by a STROBE
measurement request.
Do not execute STROBE measurement requests against started tasks such as CICS, DFSMS, IMS
control regions, IMS message processing regions (MPR) or TSO. Most started tasks will incur
substantial performance degradation if a measurement session is attempted; some may even abend.
If it is felt that these types of measurement requests are needed, contact should be made with the
MVS Operating Systems Group or the Performance Management group for assistance.
STROBE sessions executed for interpretive programs such as Assist, Eztrieve and SAS will produce
little usable results. Most activity will not point to user created code and only I/O information will be of
any use at all.
For reasons similar to interpretive programs, do not execute STROBE requests for performance
utilities such as BMC's Image Copy and Sort. In addition to JES messages, most of these programs
output diagnostic messages of their own which can provide sufficient information for tuning efforts. If
these messages do not supply enough information to answer questions regarding utility performance
the Performance Management group should be contacted for assistance.

Lights! . . . Camera!! . . . Action!!! . . .

With the spotlight focused on the basic performance tuning tools you are empowered to go forth and
conquer the demons of efficient workload throughput! We have covered the basic elements of the JES
JCL listings and actions needed to drive a STROBE performance profile. We also touched on the
benefits of having an application program compile listing handy during problem analysis; preferably with a
COBOL PMAP report attached. The fourth spotlighted item has not been previously mentioned, but can
be equally important when faced with the need to decipher execution performance abnormalities.
Figure 15. Spotlight on performance analysis tools

JCL Messages
S TROBE Performance Profile
Application Pgm compile Listing
Execution History Information

The benefit of having and understanding execution history information can be hours of research time
saved. The key here is to never ignore the obvious. For example, suppose that the execution history of a
given daily batch job shows that it deviated from normal execution patterns on a specific date. Before
jumping into a STROBE measurement session it would be well worth the effort to check for variances in
data inputs and/or implications of business cycles; i.e. is the job performing year-end processing? Always
remember to take a step back from the trees and take a look at the forest as a whole!
One final point, never hesitate to call on the members of the Performance Management group team when
in doubt. We love challenges and answering questions is always a two-way learning opportunity. Now,
with tools in hand, let's venture forth to discuss how we can use them.

...........................