2. USAGE GUIDELINES › 2.1 Data Source Concepts
2.1 Data Source Concepts
This section is an overview of the TSO/MON data recording
concepts behind the key TSO/MON response and command
measurements.
TSO/MON DATA RECORDING
TSO/MON data is recorded in two SMF records, the System
Record and the Command Record.
The System Record is written to SMF on a user-defined time
interval (normally every five minutes). This interval is
referred to as the TSO/MON recording interval. Each System
Record contains TSO response, service consumption,
performance, terminal, and command count data for each TSO
user that was logged on during the recording interval. TSO
system information is reported by aggregating the
individual user measurements.
A Command Record is written to SMF after every unique
execution of a TSO command for which an installation has
requested detailed measurement data. The user-selective
process of writing Command Records to SMF is termed "command
recording." Each Command Record contains TSO response,
service, performance, terminal, program name, user
identification, and data set name information for the
unique execution of a TSO command that prompted the
generation of the Command Record.
The System Record
The method that TSO/MON uses to record TSO measurement data
is focused heavily on data accuracy and reliability. TSO/MON
ensures data reliability of the System Record by using the
recording interval concept. This minimizes the loss of
TSO/MON TSO data caused by an SMF problem or an MVS system
failure.
If the System Record for a TSO/MON recording interval is
larger than the SMF physical record size, it is split into
multiple System Records by TSO/MON, each of which will fit in
an SMF physical record. This reduces data loss due to
possible data management problems with post-processing of SMF
data as well as VSAM problems associated with the processing
of SMF records that exceeds the physical record size of the
SMF files.
The Command Record
TSO/MON provides a facility to write periodic copies of
Command Records for long running TSO commands. This feature
is termed "command checkpointing" and it serves as a
protection against data loss due to an MVS system failure.
TSO/MON DATA MEASUREMENT
It is important to understand the basic TSO/MON response
time, response event, and command measurements. Although
these particular measurements represent a small subset of the
TSO/MON data that is available, they are probably the most
misinterpreted data elements.
TSO/MON Response Time
The TSO/MON response time measure is termed a "response
event." TSO/MON response events are those events associated
with user interactions at a TSO terminal. In other words,
there is a one-to-one relationship between a terminal
interaction (ENTER, PF KEY, etc.) and a TSO/MON response
event.
A response event begins when a TSO user presses the ENTER key
or a function key. It ends when the TSO terminal keyboard
"unlocks." (Normally, when ENTER is pressed, the keyboard
becomes disabled for input from the TSO user, or "locked.")
A response event is made up of several data elements that are
individually measured and separately maintained by TSO/MON.
Refer to Figure 2-1 for a detailed representation of a
TSO/MON response event.
A.
User Host
interaction receives TSO Swap In Swap In ends VTAM
at terminal terminal user begins and User Output written accepts Terminal
depresses the interaction scheduled Address Space to VTAM buffers terminal Keyboard
ENTER or PK key from user for Swap In starts running (terminal put) output unlocks
|.................|..............................|...............|........................................|................|
| | Swap In Delay Time | Swap In Time | Command Residency | |
B.
Inbound message Outbound message
processing processing
|.................|............................... TSO/MON Response Time .................................|................|
| Network Delay A | | Network Delay B|
C.
|.............................................. User-Perceived Response Time ..............................................|
| |
Figure 2-1. Components of Response Time
Part A of Figure 2-1 shows each component of response time
from the time a TSO user begins a Terminal Interaction by
pressing a function key or the ENTER key (locking the
keyboard) until the keyboard finally "unlocks," allowing the
TSO user to prepare for the next Terminal Interaction. When
the host CPU receives the message associated with a Terminal
Interaction, the TSO user is scheduled to be swapped in to
execute the TSO user's request.
The time it takes to start the swap in process (called Swap
In Delay), and the time it takes to swap in the TSO user
(called Swap In Time), are significant performance
measurements. Swap In Delay indicates how well the TSO first
period domain and multiprogramming level (MPL--how many TSO
users are in memory and executing concurrently) constraints
are tuned. It also indicates what effect the system-wide MPL
level has on all the TSO domains. Swap In Time is a measure
of how well the swap data sets are performing and/or
configured.
The next element of response is the time it takes to execute
the TSO command requested by the TSO user. During execution
of the TSO command, messages may be written to the TSO
terminal. Finally, the TSO terminal keyboard is unlocked,
terminating the Terminal Interaction.
Part B of Figure 2-1 breaks down response time into the time
a Terminal Interaction spends in the TSO terminal network
(termed Network Delay) and the time spent in the host CPU
actually executing the TSO user's request. Note that Network
Delay occurs before and after the CPU portion of response
time. The TSO/MON Response Time measure is equal to the
amount of time a TSO Terminal Interaction spends in the host
CPU.
Part C of Figure 2-1 details the time is takes to execute a
TSO Terminal Interaction as perceived by the TSO user sitting
at the terminal. This is called User-Perceived Response.
User-Perceived Response starts when the user presses the
ENTER or a FUNCTION key and ends when the keyboard unlocks at
the termination of the TSO command; it includes both network
delay time and host processing time.
Because of the detail of TSO/MON's response-related
measurements, response time problems caused by excessive
delays in the network, MVS swapping, or system load can be
easily isolated and dealt with effectively.
THE TSO NETWORK DELAY MEASUREMENT
TSO/MON has the unique ability to capture and report TSO
network delay measurements. TSO Network Delay is sampled
when a unique series of events occur in MVS. TSO Network
Delay measurements are maintained at the TSO user and TSO
terminal level of identification. Network delay added to
TSO/MON response time measurements equals user-perceived
response time. Network delay indicates how well the TSO
terminal network is performing. By examining network delay
times, reported response problems can be isolated to
individual terminals, terminal clusters, or communication
links.
CATEGORIZING RESPONSE EVENTS
To further aid service objective reporting, TSO/MON types TSO
response events by the short, medium, and long categories.
This is called "response typing." TSO response events are
categorized as short, medium, or long according to the number
of service units consumed during the life of each response
event (referred to as "service unit response typing").
STATISTICAL RESPONSE DISTRIBUTIONS
TSO/MON maintains a statistical distribution of TSO response
times. An installation can define up to seven response
distribution threshold values to TSO/MON. TSO/MON will then
maintain response event distributions to those specifications
at the system, user, terminal, and command levels for short,
medium, and long response event types. Response
distributions provide a means to determine the consistency of
delivered TSO response time. Response distributions also are
extremely useful for tracking management response time
objectives that are based on percentages of response events
completed within a specific response time (e.g., 95% of all
the short response events completed within one second).
THINK TIME MEASUREMENTS
TSO/MON defines TSO user think time as time that is not spent
in a response event. Think time from another viewpoint is
the time a terminal keyboard remains unlocked. Think time
statistics are tremendously useful in tuning TSO logical swap
specifications and performing TSO workload analysis based on
TSO user activity. TSO users who log on but remain idle for
extended periods of time can be identified.
COMMAND COUNTS
TSO/MON counts TSO commands, subcommands, CLIST names, ISPF
Dialog Manager programs and panels, and ISPF/PDF functions
invoked by a TSO user. The unique name and the number of
times each one is executed is maintained in the System Record
for each TSO user.
PROGRAM NAME AND DATA SET NAME RECORDING
The TSO/MON Command recording feature enables you to record
the name of the program invoked by a TSO command for which
Command recording is enabled. TSO/MON defines a "program
name" as the member of a partitioned data set (PDS) that was
invoked or accessed by a TSO command. For example, a program
name can be a member of a PDS that was invoked as a program
by the TSO CALL command, executed as a CLIST by the TSO EXEC
command, deleted by the TSO DELETE command, etc. Program
names are provided only in the Command Record.
The data set name recording option provides the name of the
data set accessed by a TSO command for which Command
recording is enabled. Data set information is provided only
in the Command Record.
If detailed command recording is specified for the PDF Edit,
Browse, or Utility functions, then TSO/MON and SPFI will
capture the data set names and member names edited, browsed,
or manipulated by the TSO user. The number of data set names
and member names captured can be controlled by a TSO/MON
option. PDF suboption codes (C for Catalog, R for Rename,
etc.) are also captured for PDF Utility functions, if
appropriate, and carried with the corresponding member name.
Data set and program name information is very useful for
identifying the names and locations of programs or TSO
applications that are heavy consumers of system resources,
performing TSO application studies, and answering questions
such as, "Which TSO user accessed what program from where?",
or "Who deleted a member from this data set and when?"
