z/VSE: 45 Years of Progress - z/VM - IBM

How the History Recorder
Operation Works
Although the raw task data is provided
by CICS, the recording and
reporting functions of the History
Recorder are subcomponents of
CICSPlex SM. If you want to view the
statistics data for recently completed
tasks, you must implement CICSPlex
SM. If you understand CICS, the task
history recording process won’t be rocket
science, and a little black magic will
help you be a power user!
Users who currently record task SMF
data will know that CICS regions cut
CICS task performance records to SMF
as they complete. The History Recorder
function simply grabs a copy of these
records and stores them in a reportable
data set that’s cyclically reused. This
means that data recorded in the CICS
history data set must be considered transient
and isn’t permanent. Each region
that’s required to report task history must
have at least two recorder data sets allocated;
their Data Definition (DD) names
will be EYUHISTA and EYUHISTB.
Additional data sets may be allocated,
and their DD names must follow in
alphabetic sequence from EYUHISTC all
the way to EYUHISTZ.
CICS will fill each data set with completed
task data. As each data set fills up,
CICS will flip to the next available data
set in alphabetic sequence and then flip
back to data set A when the last available
data set is filled. Clearly, there’s a trade-off
here between maximizing History
Recorder performance and keeping the
history records viewable for as long as
possible before a data set switch occurs.
Where disk space is at a premium for
history data recording, you can section
an area into more than two data sets:
• When only two data sets are available,
50 percent of your recorded data will
be erased each time a switch occurs;
however, system performance won’t
be denigrated by repeated data set
switching.
• When 10 data sets are defined, 10 percent
of your recorded data will be
erased with each data set switch, but
you may notice slower performance
with the more regular suspensions for
switching.
• If data retention is a priority, you
could allocate 25 history data sets. In
that instance, only 4 percent of your
history data will be overwritten with
each switch, but clearly, data set
switching will be occurring much
more often than in the two previous
instances.
It isn’t necessary to allocate history
data sets with the same size. In terms
of usability of the function, it makes
Figure 1: Monitor Definition Creation Parameters
more sense to have them identically
allocated. However, the recorder function
won’t restrict you from varying
file size allocation.
History files must be allocated as a
VSAM Relative Record Data Set (RRDS)
file—not the usual key sequenced format
required for most other CICS uses.
When a CICS task completes, CICSPlex
SM intercepts the task performance
monitor record for it and writes it to the
current, or next available, History
Recorder data set. The size of the data
set allocation and number of data sets
allocated controls the volume of data
retained. The more data sets allocated,
the longer the history data will be
reportable until it’s cyclically overwritten
with fresher history data.
History Recorder JCL Configuration
The starting point to implementing
the History Recorder is to allocate at least
two recorder data sets in each region
where recording is required. The sample
Job Control Language (JCL) to allocate
Figure 2: Monitor Definition List
4 6 • z / J o u r n a l • O c t o b e r / N o v e m b e r 2 0 1 0