4. Operation › 4.1 Overview › 4.1.4 Restart Facility

4.1.4 Restart Facility

The need to recover from problems such as system crashes,
DASD hardware errors, tape handling errors, or tape I/O
errors leads to the requirement to be able to restart CA MICS
operational jobs.  CA MICS is step restartable, meaning that
an operational job can be restarted at any step within it.
In addition, many CA MICS Data Integration Applications
support optional internal step restart.

If an error occurs during the processing of an operational
CA MICS job, CA MICS forces a user abend to abort the
execution.  After the problem has been corrected, the CA MICS
restart facility allows the job to be restarted at the step
that failed.  When activated, optional internal step restart
facilities automatically resume step execution near the point
of failure.

Step Restart

Standard step restart addresses the problem of losing
completed work when a subsequent task fails.  Each CA MICS
operational job step is self-contained such that it is
functionally independent of all other job steps.  The only
requirement is that job steps be executed in a pre-defined
order, which is controlled through the CA MICS Checkpoint
File (see Section 4.1.6).  Once a job step successfully
completes execution, the work performed in that step is
protected from loss due to failures in a subsequent step.

Internal Step Restart

Internal step restart addresses the problem of losing work
completed in a job step prior to the point of failure.
Database update jobs steps are a series of linear processing
tasks or "phases,"

  o Read raw input data, convert to SAS format, and output to
    intermediate work files.

  o Sort, analyze, summarize, and enhance intermediate work
    file contents to create a new DETAIL cycle.

  o Summarize DETAIL data to create new DAYS cycles and to
    update current week-to-date and month-to-date cycles.

  o Production cutover of new database cycles and existing
    cycle "aging."

With standard step restart, previously completed processing
must be repeated as the step always restarts at the
beginning.  With internal step restart, reprocessing
completed "phases" can be avoided.

CA MICS internal step restart utilizes a checkpoint/restart
technique.  When internal step restart is active, the
database update job step "checkpoints" (or saves)
intermediate results (work file contents) and the operational
environmental at the end of each processing phase.  Then, if
required, the database update step can resume execution at
the beginning of the processing phase in which the failure
occurred.  Restart is accomplished by restoring the
operational environment from the last checkpoint, bypassing
completed processing phases, and resuming execution using
intermediate results (work files) from the last checkpoint.

Internal step restart is implemented by product, with the
number and location of restart points dependent upon product
architecture and data volumes.  In addition, internal step
restart is activated at the product level according to your
unique installation requirements.  While internal step
restart can dramatically reduce problem recovery cost, both
in time and system resources, there is overhead associated
with taking checkpoints and managing saved materials.  Thus,
you may find that, for some products and unit database
environments, costs outweigh potential savings.  For example,
internal step restart may be of little value for a CICS unit
supporting test regions, while internal step restart may
prove very valuable in unit database updates for your
production CICS regions.

Internal step restart uses OS/390 dynamic allocation services
to create new data sets and to access existing data sets.
Data set allocation parameters are specified by product in
prefix.MICS.PARMS(cccOPS) and permanent changes to data set
allocation parameters (e.g., to increase the space allocation
for the WORK data set) require both changing the cccOPS
parameter and executing the corresponding cccPGEN job.
However, in restart situations, such as when recovering from
a production job abend, you may temporarily override data set
allocation parameters for one or more dynamically allocated
data sets by using the //PARMOVRD facility (see Section
2.3.6).

See the individual product guides for instructions and
considerations for activating internal step restart in a
specific product, and see CA MICS Planning, Installation,
Operation, and Maintenance Guide Section 2.3.6 for more
information on execution-time override of dynamic data set
allocation parameters.