|
|
|
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 will
terminate 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) will report 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. It is divided into
multiple "report blocks."
o The first three report blocks (as shown in Figure 4-3)
will always appear.
- 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 Additional report blocks are displayed to document issues
related to incremental update and/or standalone archive
tape processing.
Information 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 | | | | JOB 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 ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | HISTW ddmmmyy | SUCCESSFULLY TERMINATED | | | | ABNORMALLY ENDED IN STEP xxx| | | | INVALID CHECKPOINT FILE | | | | | HISTM 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 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.
If all processes have successfully terminated:
o If the checkpoint data set is not at its initial state,
the general status comment in block 2 will contain one of
these comments:
PROCESS SUCCESSFULLY TERMINATED ON ddmmmyy.
PROCESS IN PROGRESS ON ddmmmyy.
The process identifier in the first block of the report
will be 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
If a process has abnormally terminated:
o The process identifier in the first block of the report
will be 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 will indicate 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 will
contain:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
RESTART REQUIRED: RESTART=(stepname.MICS)
If the abending process was in aging at the time, an
additional line will be printed:
ABEND IN AGING. CONTACT CA MICS PRODUCT SUPPORT.
o If the abending process was BACKUP, the general status
comment in block 2 will contain:
PROCESS ABNORMALLY TERMINATED ON ddmmmyy.
RESTART REQUIRED: RERUN BACKUP JOB
o If the abending process was RESTORE, the general status
comment in block 2 will contain:
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 will contain 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:
NO AUDIT STATUS INFORMATION
UNABLE TO DETERMINE CURRENT 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 CA MICS PRODUCT 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 JCL will clear
these flags.
o Assume that the checkpoint file shows 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. Therefore, the WEEKLY process scheduled had
abnormally terminated and restart should be done in the
first step of the WEEKLY JCL.
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 will replace 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 identifier 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 standalone archive tape
processing.
Incremental update related problems are reported in the
INCRRSR step as well as when the DAILY job fails in the
DAYALL step. The following is an example of the messages you
might encounter 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 standalone archive
tape processing jobs (AUDIT, HISTW, or HISTM) has not yet
executed, messages describing the problem will be found both
in the Run Status Report and in the failing step's MICSLOG
listing. The following is an example of the messages you
might encounter in one of these situations.
+-----------------------------------------------------------+
| |
| 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 |
| |
+-----------------------------------------------------------+
STANDALONE ARCHIVE PROCESSING WARNINGS BLOCK
This report block may appear when you enable standalone
archive tape processing. It includes warnings about pending
archive tape jobs that may be required before the next DAILY,
WEEKLY, or MONTHLY job executes.
This information is provided as an early warning of potential
problems you may encounter. When you see these messages, you
may want to verify that AUDIT, HISTW, and/or HISTM jobs are
scheduled for execution at proper times.
The following is an example of the archive tape warning
messages you might see.
+-----------------------------------------------------------+
| |
| WARNING: ONE OR MORE ARCHIVE TAPE JOBS NEED TO BE RUN |
| |
| AUDIT JOB FOR THE 29FEB2000 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE AUDIT JOB BEFORE THE NEXT DAILY JOB |
| |
| HISTW JOB FOR THE 29FEB2000 WEEKLY HAS NOT YET EXECUTED|
| EXECUTE THE HISTW JOB BEFORE THE NEXT WEEKLY JOB |
| |
| HISTM JOB FOR THE 29FEB2000 MONTHLY HAS NOT YET EXECUTE|
| EXECUTE THE HISTM JOB BEFORE THE NEXT MONTHLY JOB |
| |
+-----------------------------------------------------------+
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |