3. Installation › 3.5 Generate a Database Unit › 3.5.7 Finalize a Database Unit
3.5.7 Finalize a Database Unit
After the steps described in the previous sections have each
been successfully completed, the system is ready for testing
in preparation for production use. It is recommended that
the testing be conducted as described below:
1. Review the CLISTs, JCL procedures, and JCL jobs
generated during CA MICS installation. If any of
them do not meet your needs, you should not change
them directly (refer to Section 2.3.3.3, JCLGEN
Parameters for Special Requirements).
2. Review the CA MICS operational facilities/procedures
in Chapter 4, Operation, of this guide.
a. Read Section 4.1, Overview, in detail. This is
an overview of CA MICS operation and facilities.
b. Scan Section 4.2, Operational Guidelines. This
is a high-level guide or road map to CA MICS
operations. Read Section 4.2.1, Getting Started
in detail.
c. Review Section 4.3.4, Operational Status and
Tracking. You will use Operational Status and
Tracking for initial CA MICS processing.
3. Select one day's data for all the CA MICS products
that you have installed. Put this data into the
CA MICS input data sets you identified with the DD
cards you supplied in the INPUTccc members of
prefix.MICS.PARMS (refer to Sections 2.3.3.2 for
descriptions of these PARMS members).
4. If you activated incremental update for one or more
products in this unit database, run the cccIUALC job
for each of these products. The cccIUALC job
allocates the product's incremental update checkpoint
and database files.
SUB 'prefix.MICS.CNTL(cccIUALC)'
Also, if you specified
INCRDB TAPE
for one or more of these products, run the product's
cccIUGDG job to create GDG indexes for the
incremental update tape database files.
SUB 'prefix.MICS.CNTL(cccIUGDG)'
5. Initialize the checkpoint file,
'prefix.MICS.CHECKPT.DATA':
SUB 'prefix.MICS.CNTL(CKPTINIT)'
6. Invoke the CA MICS Workstation Facility (MWF),
select option 5, CA MICS Administrator Facility
(MAF), and then select option 1, Operational Status
and Tracking. The Operational Status and Tracking
display should list each active unit Database.
7. Run a DAILY job.
*************************************************************
* Note that jobs which use the MICSDU PROC (for example *
* DAYALL, DAYRSR, RESTORE, and BACKUP) include a MICSABND *
* procstep which flushes under normal operation. All *
* other jobsteps in the CA MICS operational jobs should *
* have return codes of zero. *
*************************************************************
a. Enter the Operational Status and Tracking DAILY
command in the Cmd column for the unit database.
b. The DAILY command will execute the DAILY job and
the BACKUP job. See Section 4.3.3 for more
information on DAILY processing.
c. After DAILY and BACKUP complete, use Operational
Status and Tracking to review processing status.
o Enter REFRESH command to update the display.
o Enter STATUS command to review checkpoint
status.
o Enter CHECKPT command to review the checkpoint
update date/time ranges.
o Enter HISTORY command to review the input data
that was read, processed, and/or dropped.
o Enter RSTATUS command to test the RSTATUS job.
8. If this is a test unit database, manually execute
the WEEKLY, MONTHLY, and YEARLY jobs to check out the
JCL (Refer to Section 4.3.3). If this is not a test
unit, skip this step.
SUB 'prefix.MICS.CNTL(WEEKLY)'
SUB 'prefix.MICS.CNTL(MONTHLY)'
SUB 'prefix.MICS.CNTL(YEARLY)'
Do NOT use the Operational Status and Tracking for
this exercise. The WEEKLY, MONTHLY, and YEARLY
commands execute DAILY processing in addition to the
weekly/monthly/yearly cycle close-out. DAILY
processing would reject all input as duplicate data
and terminate with a U300 abend because you have not
yet provided a second day's input data.
NOTE: If you specified any of the following
parameter combinations,
ARCHIVE AUDIT YES JOB
ARCHIVE HISTW YES JOB
ARCHIVE HISTM YES JOB
in prefix.MICS.PARMS(JCLDEF) then you may also
need to execute the stand-alone AUDIT, HISTW,
and/or HISTM jobs to perform archive tape
processing.
If you specified the AUTOSUBMIT option on the
ARCHIVE statements, then the AUDIT, HISTW,
and/or HISTM jobs will be submitted
automatically by the WEEKLY job WEEK300 step
and/or MONTHLY job MONTH300 step. Otherwise,
you will need to submit the AUDIT, HISTW,
and/or HISTM job manually.
9. The contents of the database should be examined to
ensure that the definitions and generations have all
been properly applied.
Run the database check jobs (cccCHECK) which will
produce PROC PRINT listings of the first 10 records
from the 01 cycle of all files in the DETAIL timespan
and PROC FREQ TABLES LISTs of the 01 cycle of all
files in DAYS and the 00 cycle of all files in the
WEEKS and MONTHS timespans.
These listings should be used to verify the account
code, cost center code, job group, application unit,
etc., definitions.
If this job completes with a non-zero return code,
usually 8, then one or more component database files
(for example, CICCSUnn) that should be present are
not. This is a condition that was not expected and
must be investigated since you have just run a DAILY
job in step 7 above. Check the SASLOG to determine
the files involved and the reason why, and then
decide what action to take.
10. Run a database BACKUP operation--Enter Operational
Status and Tracking BACKUP command.
11. Run a database RESTORE operation--Enter
Operational Status and Tracking RESTORE command.
12. If you need to reset the database to an empty state,
perform the following steps:
- Delete the database and checkpoint files.
prefix.MICS.CHECKPT.DATA
prefix.MICS.RESTART.CNTL
prefix.MICS.DETAIL
prefix.MICS.DAYS
prefix.MICS.WEEKS
prefix.MICS.MONTHS
prefix.MICS.YEARS
(The incremental update checkpoint and
database files, if allocated, were cleared
by the last successful DAILY job and need
not be deleted to reset the database.)
- Rerun the ALLOCATE job.
- Rerun the CKPTINIT job.
(The following steps are optional, and need
not be done if you have no GDGs in the test
database, or do not care about the extra
generations which will remain from the
previous tests.)
- Uncatalog the generation data sets for the
backup, audit, and history files.
- Rerun GDGSGEN.
13. Set-up to run CA MICS in test mode on a daily basis
(see Section 4.2.1, Getting Started).
14. Use the procedures discussed in the next section to
gradually move the CA MICS system to production
status.
