5. OPERATION › 5.3 Abnormal Termination Processing
5.3 Abnormal Termination Processing
VCC is designed to terminate after most abends. Recovery
routines are provided for all VCC tasks. The recovery
routines provide a means by which VTOC/catalog scan subtasks
can capture a system dump, close OPEN data sets, unallocate
VTOCs and catalogs, and properly post VCCNTRL to avoid never-
ending wait conditions.
In cases where the abend is determined to be non-recoverable,
the abending subtask is terminated. Subtask termination
generally results in job step termination unless you request
that some number of critical errors can be ignored (see
Section 5.3.1).
In those situations where the abend is determined to be
recoverable, a subtask abend is treated as a non-critical
error. For example, if a volume does not have a VTOC, an
abend S213 will be reported in the VCCVTMSG data set and the
subtask will attempt recovery from the abend. If recovery is
successful, the subtask will clean up the processing
environment, release held resources, generate error messages
as necessary, and then continue processing with the next DASD
volume to be scanned.
If an abnormal condition has occurred and the WTO(Y)
parameter is in effect, VCC termination processing will issue
WTO messages to the master console with a descriptor code of
2, informing the operator that a problem occurred and
requesting a check of the VCC output for further information
(see the documentation for message VCCCN13I in Chapter 7,
Return Codes and Messages).
You should identify and correct problems that may have caused
VCC to abend before it is run again. You can do this by
excluding a problem volume or catalog from processing. In
all cases, unless the problem is an operator CANCEL, an abend
Sx37, or an abend S213, you should report the problem to CA
Technical Support at http://ca.com/support.
The following sections describe special situations:
o Operator Cancel
o System Crash
o S0CX Abends
o SB37 and SE37 Abends
o The SNAP Output
Operator Cancel
When a console operator cancels VCC, all processing is
terminated. You may have to restart the VCC job at the
backup step to save what data has already been collected and
to turn off the "backup-required" flag in the control file.
Rerun VCC to collect the remaining data before the CA MICS
VCA DAILY processing starts.
System Crash
A system crash is hard to recognize and is beyond the scope
of VCC. Therefore, after the system comes back up and before
the CA MICS VCA DAILY processing starts, you may have to
restart the VCC job at the backup step to save the data that
has already been collected and to reset the "backup-required"
flag in the control file. You should then run VCC again to
collect the remaining data before the CA MICS VCA DAILY
processing starts. It is the responsibility of the
operations staff or the programmer who is running VCC to make
sure that this is done.
S0Cx Abends
VCC itself most likely causes these types of abends. In
these cases, the SDUMP macro is invoked to schedule a system
dump capture to a SYS1.DUMPxx data set, and the abending
subtask is terminated. The person responsible for VCC should
contact CA Technical Support for problem assistance and a
possible fix for the problem.
Sx37 Abends
These abends are caused by the inability to obtain additional
DASD extents for the VCCDATA data set. When this condition
occurs, all processing is terminated. You may have to
restart the VCC job at the backup step to save the data that
has already been collected and to turn off the
"backup-required" flag in the control file. You should
re-allocate the VCC VCCDATA data set and rerun the VCC job to
collect the remaining data before the CA MICS VCA DAILY
processing starts.
SNAP Output
VCC may issue a SNAP macro to the VCCSNAP data set if it
detects an invalid output record. This is rare. If this
condition occurs, the output should be saved and sent to CA
Technical Support for analysis.
Note that VCC will no longer write snap dumps to the VCCSNAP
data set for the affected address space during recovery
processing.
