5. PROCESSING › 5.5 Recovering from Processing Problems
5.5 Recovering from Processing Problems
This section explains how to recover from the following
processing problems:
o An abend occurred in the DAY199 or MONTH199 step
o The DAY1 Audit File is corrupted
o An entire database is corrupted
o The sharedprefix.MICS.TABLES data set is corrupted or must
be restored to run the CLOSETBL job
RECOVERING FROM AN ABEND IN THE DAY199 OR MONTH199 STEP
__ 1. Determine the reason for the abend. Check the
MICSLOG and SAS log for abend messages.
__ 2. If the abend occurred in the DAY199 step, determine
whether it occurred before or after the post to the
checkpoint data set. To do this, look at the D=nnn
field on the first line of prefix.MICS.CHECKPT.DATA.
a. If D=199, the DAY199 step abended after the post.
This means that all the files and tapes were
created properly. Because the step abended,
however, the DAY2 tape would have been
uncataloged. Make a copy of the DAY1 tape using
IEBGENER and catalog the copy as the current DAY2
GDG.
In addition, the Journal Run Status Log ISPF table
was not updated.
- To update the Journal Run Status Log ISPF
table, enter the following TSO command:
SUB 'prefix.MICS.CNTL(ACTRSJLD)
b. If D=nnn, where nnn is a number less than 199, the
DAY199 step abended before the post. Restore the
ACTAUDIT DAY1 file to its original condition prior
to restarting the step. Restore the DAY1 file by
entering the following TSO command:
SUB 'prefix.MICS.CNTL(ACTDAY1R)'
This job restores the '0' generation of the
ACTAUDIT DAY2 into the '0' generation of the DAY1
file. If your DAY1 tape file is not usable (for
example, damaged tape), you must modify the
ACTDAY1R JCL to create a new output DAY1 GDG or
use the ACTINITA job in the 'prefix.MICS.CNTL'
library to catalog a new DAY1 GDG prior to running
the ACTDAY1R.
NOTE: If an abend occurs in the MONTH199 step, it
is not necessary to restore any file unless
the input DAY1 file is damaged.
__ 3. Restart the DAILY job, the external journal file
update job, or the MONTHLY job using the normal
CA MICS restart procedure.
o Restart the DAILY job in the DAY199 step if it
abended before the post and in the DAY200 step if
it abended after the post.
o Restart the external journal file update job in
the DAY199 step if it abended before the post and
in the EXT900 step if it abended after the post.
+---------------------------------------------------+
| Reference(s): Section 4.2.5 in the CA MICS |
| Planning, Installation, Operation, and |
| Maintenance Guide |
+---------------------------------------------------+
RESTORING A CORRUPTED DAY1 AUDIT fILE
__ 1. Enter the following TSO command to restore the DAY1
file:
SUB 'prefix.MICS.CNTL(ACTDAY1R)'
This job restores the '0' generation of the ACTAUDIT
DAY2 into the '0' generation of the DAY1 file. If
your DAY1 tape file is not usable (for example,
damaged tape), you must modify the ACTDAY1R JCL to
create a new output DAY1 GDG or use the ACTINITA job
in the 'prefix.MICS.CNTL' library to catalog a new
DAY1 GDG prior to running the ACTDAY1R.
RESTORING A DATABASE FOR ACCOUNTING
If you need to restore a database due to a problem such as
corrupted data, you must perform the following additional
steps for accounting:
__ 1. Restore the database using the standard database
restore job by entering the following command:
SUB 'prefix.MICS.CNTL(RESTORE)'
__ 2. Restore the ACTAUDIT DAY1 file to the same condition
as the database status by submitting the following
TSO command:
SUB 'prefix.MICS.CNTL(ACTDAY1R)'
This job restores the '0' generation of the ACTAUDIT
DAY2 into the '0' generation of the DAY1 file. If
your DAY1 tape file is not usable (for example,
damaged tape), you must modify the ACTDAY1R JCL to
create a new output DAY1 GDG or use the ACTINITA job
in the 'prefix.MICS.CNTL' library to catalog a new
DAY1 GDG prior to running the ACTDAY1R. If you want
to restore an older GDG than the '0' version of the
DAY2 file, you will have to modify the ACTDAY1R JCL
to read -1 or an older version of the DAY2 file.
NOTE: You must ensure that sufficient GDG versions
of the DAY2 file have been saved to support
recovery. This is a JCLDEF option.
__ 3. Resume running daily or monthly jobs.
+---------------------------------------------------+
| Reference(s): Section 4.2.5 in the CA MICS |
| Planning, Installation, Operation, and |
| Maintenance Guide |
+---------------------------------------------------+
RESTORING THE SHAREDPREFIX.MICS.TABLES DATA SET
Before restoring sharedprefix.MICS.TABLES data set, consider
the following issues:
o When was the last backup taken of the files?
NOTE: The standard BACKUP job of the primary unit
database makes a backup of the data set.
o Has anyone added or changed records since the last backup?
o If you run the restore job, will anyone be locked out of
the data set?
__ 1. Restore the TABLES data set using the standard
restore job, RSTRTBLS. Submit the job as follows
from the primary unit library:
SUB 'prefix.MICS.CNTL(RSTRTBLS)'
+---------------------------------------------------+
| Reference(s): Section 4.3.3.2.11 in the CA MICS |
| Planning, Installation, Operation, and |
| Maintenance Guide |
+---------------------------------------------------+
__ 2. Because the TABLES files are generated from ISPF
tables, you may also need to restore the ISPTLIB
members as these are used to regenerate the files in
the TABLES data set. This is necessary only if you
are restoring the TABLES database in order to rerun
the CLOSETBL job or if the ISPTLIB data set was
corrupted in addition to the TABLES data set.
a. Make a copy of the RSTRTLIB job in the
prefix.MICS.CNTL data set in the primary unit and
change the SYSIN DD section of the JCL to read as
follows:
//SYSIN DD *
COPY INDD=((BKUPTLIB,R)),OUTDD=OUTTLIB
S M=(ACTADJ00,ACTADJ01,ACTBGT00,ACTBGT01)
S M=(ACTCID,ACTSEQ,ACT$IVF)
/*
The member ACTSEQ should be coded as part of the
list only if an Invoice Sequence Number has been
entered. See section 4.5.5 of the CA MICS
Accounting and Chargeback User Guide.
b. Submit the job.
