4. Operation › 4.3 Operations Reference › 4.3.12 Special Processing Considerations › 4.3.12.5 Internal Step Restart Considerations
4.3.12.5 Internal Step Restart Considerations
Internal step restart can significantly reduce time and
resource usage to recover from daily update processing
failures. CA MICS uses this checkpoint/restart technique:
o When activated for an enabled product, the database update
job step "checkpoints" (or saves) intermediate results
(work file contents) and the operational environmental at
the end of each processing phase.
o Then, if required, the database update step can resume
execution at the beginning of the processing phase in
which the failure occurred.
o 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.
Processing Phases
Internal step restart implementation is unique to each
CA MICS Data Integration Application. The number of
processing phases and location of restart points depends on
product specific processing requirements, data architecture,
and data volume distribution.
The general processing phases are as follows:
o Read raw input data, convert to SAS format, and output to
intermediate work files. This first processing phase is
common across products. The first checkpoint is generally
taken immediately after reading all input data.
o Sort, analyze, summarize, and enhance intermediate work
file contents to create a new DETAIL cycle. This
processing is comprised of one, two, or more processing
phases.
o Summarize DETAIL data to create new DAYS cycles and to
update current week-to-date and month-to-date cycles.
This phase, DYSUM, is common to all products.
o Cutover new database cycles to production and "age"
existing cycles. This phase, DYAGE, is common to all
products.
See the product guides for more information on each product's
internal step restart implementation.
Overhead
Enabling internal step restart adds some overhead to a
product's database update job step, including the cost of
taking checkpoints and managing saved materials. Since this
overhead is relatively constant and independent of input data
volume, 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 proving very
valuable in unit database updates for your production CICS
regions. In general you will want to enable internal step
restart for those products in a unit with large input data
volume and long database update job step elapsed time. See
the individual product guides for product specific
instructions and considerations.
Cataloged Work Files
Each database update job step allocates one or more OS data
sets to hold intermediate SAS work files, including the SAS
WORK data set and the multiple work file data sets (WORK01 -
WORKnn). These are normally allocated on system "scratch"
space with a temporary, system assigned data set name. The
work data sets are deleted when the job step ends, either
successfully or with an abend.
When internal step restart is enabled, the work data sets are
allocated and cataloged with permanent data set names (for
example, prefix.MICS.cccXWORK, where ccc is the product ID)
so they will be kept for use in restart should the database
update job step abend. The work data sets are deleted when
the database update job step completes successfully.
Some site DASD allocation standards do not allow "permanent"
data sets on DASD volumes used for temporary work space. If
this is the case at your site, you may need to direct the
internal step restart data sets to a generic unit or storage
class that allows cataloged data sets. See the product
guides for required parameter syntax.
Data set allocation parameters for the WORKnn and WORK data
sets 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 you can temporarily override data set allocation
parameters for one or more dynamically allocated data sets by
using the //PARMOVRD facility. See Section 2.3.6 in this
guide for more information.
Dynamic Allocation
When internal step restart is active, dynamic allocation is
employed for the work data sets. If your site restricts
dynamic allocation of large, cataloged data sets, you may
need to direct work data set allocation to a generic unit or
storage class where dynamic allocation is allowed.
If your site automatically assigns batch job classes or
schedules work based on the amount of DASD space a job
requires, you may need to direct the CA MICS DAILY and/or
INCRccc jobs to a specific job class and processing system.
Once you enable internal step restart, your scheduling
facilities will no longer be able to determine DASD space
requirements by examining the DAILY or INCRccc job JCL.
