2. PERFORMANCE REPORTING ANALYSIS › 2.4 I/O Configuration Analysis › 2.4.7 Tape Drive Simulation Analysis Inquiry › 2.4.7.2 Technique Tutorial › 2.4.7.2.1 Data Limitations

2.4.7.2.1 Data Limitations

The Tape Drive Simulation Analysis inquiry is based on the
SMF data that is event driven (that is, the data record is
produced when the event occurs, such as step or interval
ending).  The Tape Drive Analysis inquiry assumes that all
events occurring during a report interval are input and
selected for the report.

This assumption may not be valid, unless the report interval
time being modeled includes the data from the report
specification time to a time period when all work (steps)
running during the report interval has ended and been
processed by the CA MICS MVS Batch and Operations Analyzer.
For example, if a step spans two generations of SMF data and
only the first generation data is known to the Tape Drive
Simulation Analysis inquiry, then the report spanning known
data may not include some of the data for that step.

This limitation is common to SMF event-driven data and can
adversely affect computations based on timespans.   To limit
the extent of this problem and improve event reporting,
interval records (Type 30 SMF records) can be enabled and
input to CA MICS. When interval accounting is enabled in both
SMF and CA MICS, this problem is limited to the loss of
information for one interval at most, rather than for the
entire job step, as could happen without Type 30 SMF records.

The existence of allocation time in a step record represents
a problem in the modeling process and for the assumption that
tape drives are allocated from step start to step end.
Allocation time as found in the CA MICS data element PGMALCTM
cannot be broken down to delineate which device allocation
contributed time to it (that is, what the allocation time was
caused by).

Tape drives may be freed by job control prior to step end.
This invalidates the assumption that drives are allocated
from step start to step end and can be corrected by coding a
user exit.

This type of limitation can best be explained by the
following example.  Let us assume a configuration of four
drives and a workload of two steps (from two separate jobs),
where Step 1 used three drives and Step 2 subsequently
requested two drives.  In this scenario, Step 2 first goes in
allocation wait.  The records processed by the drive inquiry
could reflect a total of five drives for the period when both
Step 1 and Step 2 were executing concurrently.

If, on the other hand, Step 1 had freed one drive prior to
Step 2's request, and the data was input without
modification, the drive inquiry would again reflect five for
the periods when Step 1 and Step 2 were concurrently
executing.