Reports from the Record Selection and Validation Program

For complete examples of the reports from Record Selection and Validation, see Figure 1 and Figure 2. In this section we will repeat various lines from these examples with explanatory notes.

INTEGRATED CATALOG FORWARD RECOVERY UTILITY R1M0

CRURRSV SYSPRINT     12/17/14 (14.351)  10:39:44    PAGE 01

                 RECORD SELECTION AND VALIDATION REPORT

Each page of reports from Record Selection and Validation begins with these lines, identifying first the name, release and modification level numbers of the product writing the reports. The second line identifies the program by name and the DD name being used. The execution date is given in both Gregorian and Julian formats followed by the time at which program execution began. Report pages are numbered consecutively. The report identification appears on each page.

                         EXECUTION PARAMETERS

CATALOG NAME               CRURCAT.VUSER01
RECORD SELECTION START     11/21/14 (14.325)  16:28:30
RECORD SELECTION STOP      11/21/14 (14.325)  16:48:38
SIGNIFICANT GAP TIME       0030 MINUTES
MAXIMUM CLOCK DIFFERENCE   NONE SECONDS

Each page of report information from Record Selection and Validation lists the execution parameters. Because the results must be viewed relative to these values, review the parameters to make sure that:

The correct catalog name was specified
The start date and time correspond to the date and time of the backup data set to be used for recovery
The stop date and time correspond to the date and time when it was confirmed that the catalog was closed in preparation for recovery
The gap specification (in minutes) is smaller than the shortest time interval spanned by a single SMF data set
The multi-system clock difference (specified in seconds) is at least as large as the maximum difference between the time-of-day clocks on any two systems.

REPORT FOR ALL SYSTEMS

REPORT FOR SYSTEM T81J

Record Selection and Validation produces first a summary report for all systems and then individual reports for each system encountered in the SMF data. You should first review the report for all systems, and then only if further information or investigation is needed, proceed to the individual system reports. The report analysis is basically the same for all reports, except that the first report will tell you about the different systems encountered and provides an overall summary.

RECORD SELECTION AND VALIDATION CONDITION CODE IS 04

This is the maximum condition code encountered during program execution, for all systems or for an individual system, depending on the report being viewed.

0 ANOMALIES (LOST DATA, GAPS) DETECTED

If the count of GAPS AND/OR LOST DATA RECORDS is not zero, you should analyze the following data to locate the cause.

31 RECORDS SELECTED FOR CRURCAT.VUSER01

If the count of RECORDS SELECTED is zero, your subsequent analysis should try to determine if this could be correct. Since the numbers will vary by catalog, by elapsed time and by activity, it is not possible to present guidelines on what these numbers should be. This line should be the total of the counts below of (TYPE 6x) RECORDS SELECTED.

 2 DEFINE (TYPE 61) RECORDS SELECTED
10 DELETE (TYPE 65) RECORDS SELECTED
19 ALTER  (TYPE 66) RECORDS SELECTED

Normally you might expect somewhat equal counts for DEFINE and DELETE with a smaller count for ALTER. This example is not very representative of what you should expect to see.

01 SYSTEM(S) RECORDED CHANGES TO THIS CATALOG
   T81J

These lines appear only on the report for all systems. Look at the count for SYSTEM(S) that RECORDED CHANGES TO THIS CATALOG and beneath it, the list of system identifiers (normally more than one line). Make sure that all systems having access to the catalog are in the list. However, if a system that had access to the catalog did not update the catalog it will not be listed here. There will be a system report for such a system and you should look there to be sure that that system's data was not omitted.

FOR CATALOG CRURCAT.VUSER01

Note that the next four lines concern only the SMF records for the catalogs named here.

11/21/14 (14.325)  16:12:46.57 OLDEST SMF CATALOG RECORD FOUND

The date and time of the OLDEST SMF CATALOG RECORD FOUND should normally precede the specified recovery start time. It should also precede the next entry.

11/21/14 (14.325)  16:28:31.74 OLDEST SMF CATALOG RECORD SELECTED

The date and time of OLDEST SMF CATALOG RECORD SELECTED should usually coincide fairly closely with the specified recovery start time. If EXPORT is being used for backup, there should be an SMF record a few seconds after the specified start time, resulting from the catalog update to turn on the temporary EXPORT indicator.

If the OLDEST SMF CATALOG RECORD SELECTED precedes the specified recovery start date and time, it should be within the interval specified as the multi-system clock difference (which is used to establish an effective start time). This condition may account for spurious error messages, if records in this interval result in reprocessing changes already represented in the EXPORTed copy of the catalog.

11/21/14 (14.325)  16:47:27.94 NEWEST SMF CATALOG RECORD SELECTED

The date and time of the NEWEST SMF CATALOG RECORD SELECTED for this catalog should usually be the same as that of the NEWEST SMF CATALOG RECORD FOUND unless intermediate record collection is being done.

The date and time of each should precede the specified recovery stop time. Even though the recovery stop time is adjusted by the multi-system clock difference, the time needed to confirm that the catalog was closed for recovery should be well after the last update to the catalog.

11/21/14 (14.325)  16:47:27.94 NEWEST SMF CATALOG RECORD FOUND

The date and time of the NEWEST SMF CATALOG RECORD FOUND for this catalog should usually be the same as that of the NEWEST SMF CATALOG RECORD SELECTED, unless intermediate record collection is being done. You would normally want the most current data.

FOR ALL SMF RECORD TYPES

Note that the remainder of the report concerns SMF records of all types, not just the SMF catalog records.

11/21/14 (14.325)  16:00:03.37 OLDEST SMF RECORD FOUND (ANY TYPE)

The date and time of the OLDEST SMF RECORD FOUND should normally precede the specified recovery start time. If it does not, older SMF data has probably been omitted.

11/21/14 (14.325)  16:59:58.54 NEWEST SMF RECORD FOUND (ANY TYPE)

The date and time of the NEWEST SMF RECORD FOUND should normally be later than the specified recovery stop time, otherwise the most recent SMF data has probably been omitted.

The next several lines of the report summarize the events that you should investigate for omitted or lost SMF data.

1 SYSTEM IDENTIFIERS WERE FOUND

This count includes all systems from which SMF data was read, not just those which updated the catalogs named above.

665 TOTAL SMF RECORDS WERE READ

Based on the experience of your installation, determine whether this count is reasonable considering the number of systems and the period covered by the SMF data.

1 SMF SWITCH (TYPE 90, SUBTYPE 6) RECORDS WERE FOUND

This count is not very interesting on the "all systems" report. However, on an individual system report, it tells you how many times the SMF recording data set was switched, and therefore gives you some idea of whether all appropriate SMF data sets have been included. In addition, in the log data set you will find a message for each switch, CRU023I. The time difference between the switch records tells you how often the SMF data sets are filling up (or being switched). Based on this value, you can determine whether the SMF gap time you specified is sufficiently small to detect the absence of an SMF input data set.

0 SMF EOD (TYPE 90, SUBTYPE 7) RECORDS WERE FOUND

Again, this value is primarily of interest for a single system. The intention is that you should be able to spot periods of deliberate system inactivity and thereby resolve corresponding gaps. Look for message CRU022I in the log. Normally it will precede the message for the next event.

0 SMF IPL (TYPE 0) RECORDS WERE FOUND

This value too is primarily of interest for a single system. The IPL may be a planned one or it may be the result of an interruption. Look for message CRU021I in the log. The SMF record for a planned IPL will normally be preceded by a record for EOD. The accompanying gap in SMF recording (if any) is thus explained and can be disregarded.

If no EOD record precedes the IPL record, there is a good chance that there has been a system interruption and SMF records may have been lost. If the time between the interruption and the IPL exceeds the gap time, an accompanying gap message should be expected. Otherwise, this IPL record may be the only indication of lost SMF data. Consequently, each IPL should be understood, referring to your problem management records and to the system log as necessary to establish the time of any accompanying interruption.

0 SMF LOST DATA (TYPE 7) RECORDS WERE FOUND

The next line gives the count of SMF LOST DATA RECORDS FOUND. This value is primarily of interest for a single system. Look for message CRU202I for that system in the log. The dumped record accompanying that message contains the beginning date and time of the resulting gap in SMF records and also the number of records lost. You will normally want to proceed with the ICFRU, using the SMF data you do have.

  0 FORWARD GAPS IN SINGLE-SYSTEM SMF RECORDS LONGER THAN
    0030 MINUTES WERE FOUND

Any gaps that appear should be resolved from the single system reports. A FORWARD GAP condition is recognized when the date and time for the current record is later than the previous record for that system by an interval longer than the gap time you specified. Each such event is signaled by message CRU201I in the log. It is most frequently not associated with a lost data condition, but rather with a normal or planned period of system inactivity.

If accompanied by a normal EOD and IPL sequence or if the interval is during a time when this system is normally inactive, the gap is accounted for an may be ignored. If the gap is not accounted for in this way, look for omissions in the SMF input data. Even if all input data is present, it may not have been presented in sequence by data set. In this case, there should be an accompanying BACKWARD GAP (see below).

If the gap cannot be explained by any of the previous reasons, you should assume that SMF data has been lost. You will normally want to proceed with the ICFRU, using the SMF data you do have.

  0 BACKWARD GAPS IN SINGLE-SYSTEM SMF RECORDS LONGER THAN
    0030 MINUTES WERE FOUND

A BACKWARD GAP condition is recognized when the date and time for the current record is earlier than the previous record for that system by an interval longer than the gap time you specified. The event is signaled by message CRU200I in the log. It typically results from concatenating newer SMF dump data sets in front of older ones. Thus the principal use of this count and its companion message is the resolution of forward gaps.

It could also be caused by reusing a partially filled SMF recording data set before it has been dumped (or emptied). Thus it might accompany a system interruption, which resulted in the use of an SMF recording data set other than the one active at the time of interruption. In this last case you might expect to find an IPL record after the backward gap.