6. DATA SOURCES › 6.2 VTS Component Data Sources › 6.2.1 IBM VTS SMF Data › 6.2.1.2 Collecting SMF Type 94 Records

6.2.1.2 Collecting SMF Type 94 Records

SMF Type 94 records reflect activity from the IBM VTS
perspective and do not provide information at the z/OS system
level.  Complete hourly statistics for a particular VTS are
available from the SMF type 94 records sent to any attached
z/OS system.

Because of the "VTS perspective" of the SMF data, the CA MICS
processing of SMF type 94 records filters the data to select
one representative hour for each VTS from all z/OS systems
reporting on the VTS.

This design simplifies VTS reporting and, when data from
multiple z/OS systems is included in the input stream (which
is recommended), reduces the chance that intervals will be
missed due to downtime for a particular z/OS system.

The SYSID value stored in the CA MICS IVT Information Area
database files defaults to SYS1, but may be overridden with a
VTSSYSID statement in prefix.MICS.PARMS(VTSOPS).  See section
7.2.3.1.3 for more information about the VTSSYSID statement.

A best practice is to collect SMF type 94 records from as
many z/OS systems as practical and input all the data to the
VTS component daily update step.  The primary reason to feed
data from multiple z/OS systems is to minimize potential data
loss in the CA MICS database files. If only one z/OS system
is used as input, any downtime for that system will result in
missing data for the VTS in the CA MICS database.

If data from multiple z/OS systems is included in the input,
the only time database data will be missing is when all the
z/OS systems are down at the same time.

SMF type 94 record data volume is minimal, so inputting data
from multiple systems does not significantly impact the VTS
component daily update step execution time.

VTSUTIL Utility Job
-------------------
The prefix.MICS.CNTL(VTSUTIL) utility job can be executed to
determine which z/OS hosts are attached to each VTS.  The
primary function of the utility is to determine the
association of UI and secondary VTSs with their composite VTS
for peer-to-peer VTS implementations.  This association must
be registered in prefix.MICS.PARMS(VTSCMPID), as described in
section 7.2.3.3, if a peer-to-peer VTS is present in the
input data.

A secondary use of the utility job is to show which z/OS
systems are reporting on each VTS.  Using the utility program
for this purpose can assist in determining which z/OS systems
should be used to collect SMF data for input into the DAY096
daily update step.

To run the utility job update the //INPUTSMF DD statement to
include a days worth of SMF type 94 data collected from all
z/OS systems.

After execution, examine the //REPORT output.  The first
report generated, the IBM VTS Overview Report, lists each
VTS, the VTS type, and each z/OS system collecting data for
the VTS. Here is an example of the overview report:

+--------------------------------------------------+
|                    | SYSID LISTING               |
| VTS     VTS        |----+----+----+----+----+----+
| ID      Type       |SYS1|SYS2|PRDA|PRDB|TST1|TST2|
| -----   ---------- |----+----+----+----+----+----+
| CMP01   COMPOSITE  |    |    |    |    | XX | XX |
| V9401   -UI        |    |    |    |    | XX | XX |
| V9402   -SECONDARY |    |    |    |    | XX | XX |
| CP100   COMPOSITE  |    |    | XX | XX |    |    |
| TND11   -UI        |    |    | XX | XX |    |    |
| TND22   -SECONDARY |    |    | XX | XX |    |    |
| AAAAA   COMPOSITE  | XX | XX |    |    |    |    |
| A0002   -UI        | XX | XX |    |    |    |    |
| A0002   -SECONDARY | XX | XX |    |    |    |    |
| 89834   STANDALONE | XX | XX |    |    |    |    |
| 89835   STANDALONE | XX | XX |    |    |    |    |
+--------------------+-----------------------------+
 Figure 6-1.  VTSUTIL Sample VTS Overview Report

In the above sample, there are three peer-to-peer VTS
configurations and two standalone VTS configurations.  Each
peer-to-peer consists of a UI, a secondary, and a composite.

The report shows that the SMF data processed provides exactly
two sets of data per VTS configuration.  The z/OS systems
listed would be reasonable choices to use as input for the
DAY096 step.  With this data, if any single z/OS system was
down, SMF data from the second z/OS system would be used to
update the CA MICS database for any of the VTS
configurations.

Note: Be careful to select z/OS systems that are not likely
to be down for maintenance at the same time.