The CA MICS Run Status Report shows critical database update
status information from the unit checkpoint file
(prefix.MICS.CHECKPT.DATA). To understand CA MICS checkpoint
facilities, see section 4.3.7, CA MICS Checkpoint File, of
this guide.
The CA MICS Run Status Report is produced several times:
o As the last report in any DAILY, WEEKLY, MONTHLY, or
YEARLY operational job.
o After database BACKUP or RESTORE jobs.
o As the last report in any INCRccc, AUDIT, HISTW and HISTM
operational job.
o After unsuccessful execution of the SCHEDULE job.
o On demand, by running the RSTATUS job.
If the Run Status Report finds the database in a
non-updatable condition, the Run Status Report step
terminates with a U0999 abend. When you find a U0999 abend in
a Run Status Report step (INCRRSR, DAYRSR, WEEKRSR, MONTHRSR,
YEARRSR, BKUPRSR, RSTRRSR, SCDRSR, or RSTATUS), see the Run
Status Report for an explanation of the database problem.
Note: The Run Status Report only processes the incremental
update checkpoint data set during execution of INCRccc
processing. During all other processing, INCRccc job status
is not reflected in the Run Status Report. Other processing
(DAILY, WEEKLY, and so on) reports on the unit checkpoint
(prefix.MICS.CHECKPT.DATA). However, if the DAYALL step of
the DAILY job aborts due to incremental update related
issues, the unit checkpoint is updated with flags that cause
the Run Status Report to document the incremental update-
related failure.
Figure 4-3 depicts the report's format. The report is
divided into multiple "report blocks."
o The first three report blocks (as shown in Figure 4-3)
always appears.
- The first block identifies the report.
- The second block identifies the overall database
status.
- The third block lists the detailed status of each of
the operational database jobs.
o More report blocks are displayed to document issues
related to incremental update, the stand-alone archive
tape processing, or both.
Information that is provided in the first three blocks of the
Run Status Report is also available through the Operational
Status and Tracking facility STATUS command.
+-----------------------------------------------------------+ | CA MICS ssssssss RUN STATUS REPORT FOR DATABASE dddddddd | | | | PROCESS: jjjjjjjj DATE: dayname,month dd,yyyy | |-----------------------------------------------------------| | | | PROCESS | SUCCESSFULLY TERMINATED | ON ddmmmyy. | | | IN PROGRESS | | | | SUCCESSFULLY INITIALIZED | | | | ABNORMALLY TERMINATED | | | | STATUS NOT DETERMINED | | | | | RESTART REQUIRED: | RESTART=(stepname.MICS) | | | | RERUN BACKUP JOB | | | | RERUN RESTORE JOB | | | | | ABEND IN AGING. CONTACT TECHNICAL SUPPORT. | | | | MULTIPLE ABNORMAL ENDS. CONTACT TECHNICAL SUPPORT. | | | | UNABLE TO DETERMINE CURRENT STATUS | | | |-----------------------------------------------------------| | | | GENERAL RUN STATUS FOR ALL PERIODS | | | | PERIOD COMPLETION DATE TERMINATION STATUS | |-----------------------------------------------------------| | | | DAILY ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | - OR - | INVALID CHECKPOINT FILE | | | | | INCRUPDT ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN INCRxxx | | | | INVALID CHECKPOINT FILE | | | | | WEEKLY ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | MONTHLY ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | YEARLY ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | BACKUP ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | RESTORE ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | AUDIT JOB ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | HISTW JOB ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | HISTM JOB ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | +-----------------------------------------------------------+
Figure 4-3. Format of CA MICS Run Status Report
FIRST REPORT BLOCK
The first block of the report contains the title and
timestamp of the report and identifies the last process of
interest at the time the report is printed. In the first
report content block:
ssssssss Represents the name of the job step from which
the report program was called.
dddddddd Is the 8-character database unit identifier
specified in the DATABASE statement of
prefix.MICS.PARMS(JCLDEF).
jjjjjjjj Is the name of the process of interest in the
current report.
DATE: Is the date on which the report was produced.
The content of the report depends on the following:
o The content of the update status record in
prefix.MICS.CHECKPT.DATA, or in the case of INCRccc, the
update status record in prefix.ccc.IUCKPT.DATA.
o The operational job step from which the Run Status Report
was executed.
o Any previous scheduling activity that is done by
Operational Status and Tracking or the CA MICS SCHEDULE
job.
SECOND REPORT BLOCK
In the second block of the report, the overall status of the
database update is given.
When all processes have successfully terminated:
o If the checkpoint data set is not at its initial state,
the general status comment in block 2 contains one of
these comments:
PROCESS SUCCESSFULLY TERMINATED ON ddmmmyy.
PROCESS IN PROGRESS ON ddmmmyy.
In the special case when a checkpoint data set flag
indicates that a backup job has begun but has not yet
ended, a second line in block 2 contains:
(UNABLE TO DETERMINE CURRENT BACKUP STATUS)
The process name in the first block of the report is
INCRUPDT, DAILY, WEEKLY, MONTHLY, or YEARLY. The process
is identified from the Run Status Report executing under
the conditions noted in the following table:
IF the AND the THEN the AND the
report was last item block 1 process
run in scheduled PROCESS name status
this step was is set to be printed is
---------- --------- ------------ ----------
DAYRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY INCOMPLETE
MONTHLY MONTHLY INCOMPLETE
YEARLY YEARLY INCOMPLETE
INCRRSR any INCRUPDT SUCCESSFUL
WEEKRSR any WEEKLY SUCCESSFUL
MONTHRSR any MONTHLY SUCCESSFUL
YEARRSR any YEARLY SUCCESSFUL
BKUPRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
RSTRRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
RSTATUS DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
AUDITRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
HISTWRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
HISTMRSR DAILY DAILY SUCCESSFUL
WEEKLY WEEKLY SUCCESSFUL
MONTHLY MONTHLY SUCCESSFUL
YEARLY YEARLY SUCCESSFUL
When a process has abnormally terminated:
o The process name in the block 1 of the report is INCRUPDT,
DAILY, WEEKLY, MONTHLY, YEARLY, BACKUP, or RESTORE.
If the abnormal termination is in a WEEK, MONTH, or YEAR
step, then the process name is WEEKLY, MONTHLY, or YEARLY,
respectively.
If the abnormal termination is in a DAY step, then the
process name is the update process last scheduled (DAILY,
WEEKLY, MONTHLY, or YEARLY).
If the abnormal termination is in an INCR step, then the
process name is INCRUPDT.
If the abnormal termination is in an AUDIT, HISTW, or
HISTM step, then the process name indicates the update
job that was run last.
o If the abending process was DAILY, WEEKLY, MONTHLY, or
YEARLY, the general status comment in block 2 contains:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
RESTART REQUIRED: RESTART=(stepname.MICS)
If the abending process was in aging at the time, an
additional line is printed:
ABEND IN AGING. CONTACT TECHNICAL SUPPORT.
o If the abending process was BACKUP, the general status
comment in block 2 contains:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
RESTART REQUIRED: RERUN BACKUP JOB
o If the abending process was RESTORE, the general status
comment in block 2 contains:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
RESTART REQUIRED: RERUN RESTORE JOB
o If the abending process was AUDIT, HISTW or HISTM, the
general status comment in block 2 contains the status
of the update job that was run last.
However, if a BACKUP job was found to be possibly
still executing, the general status comment in block 2
(using AUDIT as an example) will contain:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
(UNABLE TO DETERMINE CURRENT BACKUP STATUS)
o If prefix.MICS.CHECKPT.DATA has been destroyed, the
general status comment in block 2 will contain:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy. MULTIPLE
ABNORMAL ENDS. CONTACT TECHNICAL SUPPORT.
The Run Status Report identifies the SCHEDULEd process as
having failed if the following conditions are true:
o All detailed processes have been successfully completed
with step identifiers of 900.
o The last SCHEDULEd process was WEEKLY, MONTHLY, or YEARLY.
o The DAILY status date is later than the WEEKLY, MONTHLY,
or YEARLY status date.
It prints restart instructions to restart the last SCHEDULEd
process from prefix.MICS.RESTART.CNTL in the first step of
the WEEKLY, MONTHLY, or YEARLY process. This situation is
much easier to see with an example:
o Assume a WEEKLY process was scheduled using the
Operational Status and Tracking SCHEDULE command. This
fact is recorded in the update status record of
prefix.MICS.CHECKPT.DATA by the scheduling flags noted in
section 4.3.3.3. A successful execution of the Run Status
Report from the WEEKRSR step of the WEEKLY job clears
these flags.
o Assume that the checkpoint file shows that the DAILY
update completed on 13AUG01 and the WEEKLY update
completed on 06AUG01. If the scheduling flag has not been
cleared, the RSTATUS program senses that the WEEKLY update
never started after the last part of the DAILY update
completed successfully. Consequently, the WEEKLY process
is assumed to have abnormally terminated and restart
should be done in the first step of the WEEKLY job.
THIRD REPORT BLOCK
The third block of the CA MICS Run Status Report is the
GENERAL RUN STATUS FOR ALL PERIODS. This block shows the
DAILY, WEEKLY, MONTHLY, and YEARLY update processes, the
AUDIT, HISTW, and HISTM job processes, the BACKUP and RESTORE
database maintenance processes, the date upon which they last
completed execution, and their termination status.
Note: If the executing process was INCRccc, then the
INCRUPDT process replaces the DAILY process line.
SPECIAL CASE: AFTER THE RUN OF A CKPTINIT JOB
When generating a new database unit, the CKPTINIT job puts
the checkpoint data set in an initialized state. This state
persists until data is processed by a DAILY run for the unit
so that files are written in the database and data range
records are written in the Checkpoint File. When in that
initialized state,
o The process name in the first block of the report is
CKPTINIT.
o The general status comment in block 2 contains:
PROCESS SUCCESSFULLY INITIALIZED ON ddmmmyy.
o The termination status on all lines of block 3 contains:
SUCCESSFULLY INITIALIZED
INCREMENTAL UPDATE AND ARCHIVE TAPE ISSUES BLOCK
This report block appears when processing is aborted due to
problems with incremental update or stand-alone archive tape
processing.
Incremental update related problems are reported in the
INCRRSR step and when the DAILY job fails in the DAYALL step.
This example shows the messages that can occur in this
situation. See the DAYALL step MICSLOG listing for a
detailed explanation of the error conditions.
+-----------------------------------------------------------+
| |
| INCREMENTAL UPDATE AND ARCHIVE TAPE RELATED ISSUES: |
| |
| ONE OR MORE INCREMENTAL UPDATE (INCRccc) JOBS IS IN |
| PROGRESS OR REQUIRES RECOVERY/RESTART |
| |
| ONE OR MORE INCREMENTAL UPDATE CHECKPOINT FILES |
| WERE NOT FOUND OR COULD NOT BE ALLOCATED DISP=SHR |
| |
| THE UNIT CHECKPOINT IS NOT LARGE ENOUGH TO HOLD THE NEW|
| ENTRIES FROM THE INCR. UPDATE CHECKPOINT DATA SETS |
| |
+-----------------------------------------------------------+
If the DAILY job DAYALL step or the first step of the WEEKLY
or MONTHLY job aborts because one of the stand-alone archive
tape processing jobs (AUDIT, HISTW, or HISTM) has not yet
executed, messages describing the problem occur both in the
Run Status Report and in the failing step's MICSLOG. This
example shows the messages that can occur in this situation.
+-----------------------------------------------------------+
| |
| INCREMENTAL UPDATE AND ARCHIVE TAPE RELATED ISSUES: |
| |
| AUDIT JOB FOR THE 19MAR2001 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE AUDIT JOB AND THEN RESTART WEEKLY |
| |
| HISTW JOB FOR THE 19MAR2001 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE HISTW JOB AND THEN RESTART WEEKLY |
| |
| HISTM JOB FOR THE 03MAR2001 MONTHLY HAS NOT YET EXECUTE|
| EXECUTE THE HISTM JOB AND THEN RESTART MONTHLY |
| |
+-----------------------------------------------------------+
STAND-ALONE ARCHIVE PROCESSING WARNINGS BLOCK
This report block can appear when you enable stand-alone
archive tape processing. This block includes warnings about
pending archive tape jobs that can be required before the
next DAILY, WEEKLY, or MONTHLY job executes.
This information is provided as an early warning of potential
problems you might encounter. Verify that AUDIT, HISTW, and
HISTM jobs are scheduled for execution at proper times.
The following is an example of the archive tape warning
messages.
+-----------------------------------------------------------+
| |
| WARNING: ONE OR MORE ARCHIVE TAPE JOBS NEED TO BE RUN |
| |
| AUDIT JOB FOR THE 29FEB2013 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE AUDIT JOB BEFORE THE NEXT DAILY JOB |
| |
| HISTW JOB FOR THE 29FEB2013 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE HISTW JOB BEFORE THE NEXT WEEKLY JOB |
| |
| HISTM JOB FOR THE 29FEB2013 MONTHLY HAS NOT YET EXECUTE|
| EXECUTE THE HISTM JOB BEFORE THE NEXT MONTHLY JOB |
| |
+-----------------------------------------------------------+
|
Copyright © 2014 CA.
All rights reserved.
|
|