4. Operation › 4.3 Operations Reference › 4.3.7 CA MICS Checkpoint File
4.3.7 CA MICS Checkpoint File
The CA MICS Checkpoint File is a permanent, physical
sequential data set where CA MICS maintains a running status
of the system's operation and database contents for an entire
unit database. The Checkpoint File is frequently referred to
as the unit checkpoint. The unit checkpoint contains a fixed
number of records. It is updated by each database update job
step in the DAILY, WEEKLY, MONTHLY, YEARLY, BACKUP, and
RESTORE operational jobs. The update takes place as the last
action of the step and only after all previous functions
within the step have successfully executed.
The Checkpoint File is concerned with ensuring database
integrity across database update job steps and update cycles.
o The unit checkpoint should not be confused with database
update restart checkpoints which are product specific,
temporary files used to save an image of the operational
environment for restart within a database update job step.
o The unit checkpoint is also separate and distinct from the
optional incremental update checkpoint files which are
product specific, permanent data sets used to ensure the
integrity of incremental update processing for a single
CA MICS data integration product. The INCRccc jobs do NOT
modify the unit checkpoint.
The checkpoint file is also updated when optional stand-alone
Archive Audit (AUDIT job), Archive Weekly History (HISTW
job), Archive Monthly History (HISTM job) processing
completes. These updates take place while the checkpoint
file is allocated DISP=SHR and use internal CA MICS ENQ/DEQ
facilities to prevent concurrent updates to the checkpoint
file.
In addition, Incremental Update INCRccc jobs may update the
checkpoint file to clear FORCE/SELECT specifications that
were established for the INCRccc job execution. This update
also allocates the checkpoint file DISP=SHR and depends on
the CA MICS ENQ/DEQ facilities to ensure data set integrity.
The following diagram illustrates the relationship of the
Checkpoint File to a database update job step in the DAILY,
WEEKLY, MONTHLY, or YEARLY operational job.
NOTE: The INCRccc jobs process the product-level incremental
update checkpoint files in a very similar manner, but
do NOT update the unit checkpoint except to clear
FORCE/SELECT specifications.
+-----------------------------------------------------------+
| |
| CA MICS Job (for example, DAILY) |
| |
| +---------------------------+ |
| | | +-------+ |
| | Step N in Job | | C | |
| | +---------------------+ | Read Only | H | |
| | | Step's First Action |<-----------------| E | |
| | +---------------------+ | | C | |
| | | Step's Processing | | | K | |
| | +---------------------+ |Update In-place| P | |
| | | Start of Aging |<---------------->| O | |
| | +---------------------+ |Update In-place| I | |
| | | SYSID/COMPONENT |<---------------->| N | |
| | | Update, If Required | | | T | |
| | +---------------------+ |Update In-place| | |
| | | Aging Completed |<---------------->| F | |
| | +---------------------+ |Update In-place| I | |
| | | Step's Last Action |<-+-------------->| L | |
| | +---------------------+ | | E | |
| | | +-------+ |
| +---------------------------+ |
| |
| |
+-----------------------------------------------------------+
The Checkpoint File is updated by each step in each of the
DAILY, WEEKLY, MONTHLY, YEARLY, BACKUP, and RESTORE jobs.
The Checkpoint File is referenced at least twice by each
step:
o The first reference is a read only access enabling the
step to determine if it is permitted to execute. If the
prerequisite step has not executed, the job stream is
aborted with a user abend 100. If the prerequisite step
has successfully executed, then the step's normal
processing functions are performed.
o The second reference occurs after all functions operate
successfully. At that point, control is passed to the
last action of the step, which again accesses the
Checkpoint File to update its status, indicating that this
step has successfully completed.
Prerequisite steps are identified in the Job Steps section of
this guide. For example, before executing DAY030, DAY020
must complete successfully if both the Batch and Operations
Analyzer and the Hardware and SCP Analyzer are installed in
the unit database.
For steps that update the database, the aging flag in the
Checkpoint File indicates that the Database is being
updated. The flag is set prior to cycle aging and cleared
when cycle aging has completed. If an abnormal termination
occurs during cycle aging, this flag notifies you that normal
restart is not allowed.
Database update steps also update the time range status
section of the Checkpoint File by recording the date range of
the data used to update the Database.
The RSR (Run Status Report) step of each operational job
updates the current process flag (D, W, M, or Y), but does
NOT alter the aging flag or the job step number fields.
Failures in the RSR step do NOT impact database update. The
database remains in updatable condition and restart is not
required.
The optional incremental update checkpoint files have the
same format as the unit checkpoint file. Each incremental
update checkpoint file is initialized as a copy of the unit
checkpoint file by the first INCRnnn job for the
corresponding product executed each day. Subsequent INCRccc
job executions update the ccc product incremental update
checkpoint in the same way that the DAYnnn steps execute the
unit checkpoint file. Then, at the end of the day, the
corresponding DAYnnn step updates the unit checkpoint file
from the incremental update checkpoint file.
Additional fields in the checkpoint are used in monitoring
and controlling stand-alone archive tape processing and to
identify DAYALL step abends due to problems in Incremental
Update processing.
o When Incremental Update is active for one or more products
in the unit, the DAILY job DAYALL step sets the IUS_FLAG
field to '...' and then verifies that all pending INCRccc
jobs are complete and that there is room in the checkpoint
file for rolling-up checkpoint information from the
incremental update checkpoint files. Error conditions are
marked with an 'I', 'U', and/or 'S' in the appropriate
column, and these flags are used in formatting the Run
Status Report output. DAYALL clears the IUS_FLAG to
blanks if no problems are encountered.
o When optional stand-alone archive tape processing is
enabled, the WEEK300 and MONTH300 steps set flags
indicating that AUDIT, HISTW, and/or HISTM operational job
execution is required. The DAILY job DAYALL step and the
first steps of the WEEKLY and/or MONTHLY jobs check these
flags to determine if prerequisite processing has
completed. Archive tape processing status is also
included in the Run Status Report.
The unit checkpoint file and incremental update checkpoint
files are documented further in the following sections.
1 - Checkpoint Restart and Termination Status Record
2 - Checkpoint Database Update Time Range Records
3 - Duplicate Data Check Process
4 - Using the Select Option for Input Data
5 - Using the Force Option for Input Data
