Database Unit Execution Option Definitions

The execution options parameter statements must be specified before the MICS system is generated.
micsrm140
The execution options parameter statements enable you to:
  • Select database archive options
  • Select the method for file storage of work files that are used in the daily
    MICS
    job
  • Define the frequency of database backup.
These options must be specified before the
MICS
system is generated. If they are changed, part of the generation process must be repeated before the change takes effect. More execution options that can be changed without running any of the
MICS
generation processes are available. These parameters are discussed in Dynamic Execution Options (EXECDEF).
The database archive options include Audit Data, Weekly History Data, and Monthly History Data. Each archive option must be specified as either YES (activate and use) or NO (do not implement). Optional parameters let you execute archive processing as part of the standard WEEKLY and MONTHLY jobs or in stand-alone jobs that can execute in parallel with reporting and end-user inquiry processing. For more information about audit archiving and history archiving, see The
MICS
Audit Archive Tape and The
MICS
History Archive Tapes respectively.

ARCHIVE AUDIT

To activate the Archive Audit, specify either YES or NO. If you specify YES, then further control over the amount of data available in the Archive Audit files is available through the AUDITGDG parameter that is described here and parameters you specify in prefix.MICS.PARMS(DBMODEL). The default is YES.
Specify YES and you can also specify either STEP or JOB in the optional third positional parameter. Specify STEP includes the Archive Audit processing in the WEEK300 step of the WEEKLY operational job, Specify STEP or also allows offloading the Archive Audit processing to the stand-alone AUDIT operational job. STEP is the default.
The JOB option reduces WEEKLY operational job execution time and increase database availability by moving the Archive Audit processing to the stand-alone AUDIT job. This job allocates the
MICS database
files DISP=SHR and thus can execute concurrently with reporting, end-user inquiry, and other read-only processing. This process must complete before the next DAILY operational job is allowed to execute. If AUDIT has not completed, then the DAILY job DAYALL step abends with messages reporting that AUDIT must complete before executing DAILY.
Note:
The STEP/JOB parameter is ignored when you specify NO.
In the optional fourth positional parameter, you can specify AUTOSUBMIT or NOAUTOSUBMIT. AUTOSUBMIT indicates whether the WEEK300 step of the WEEKLY operational job does automatically write the AUDIT job to the internal reader. NOAUTOSUBMIT submits the AUDIT job externally, per your data center's production job scheduling facilities. NOAUTOSUBMIT is the default.
  • If your data center standards allow job submission through the internal reader, specifying AUTOSUBMIT ensures that the AUDIT job is submitted for execution at the proper time. Remember that the AUDIT job must complete before the next DAILY operational job can execute.
  • If you specify NOAUTOSUBMIT (or take the default) ensure that the AUDIT job is submitted for execution after the WEEKLY job completes.
  • The AUTOSUBMIT/NOAUTOSUBMIT parameter is ignored when you specify NO (no Archive Audit processing) in the second positional parameter, or if you specify STEP in the third positional parameter (perform Archive Audit processing in the WEEK300 step).
The following example ARCHIVE specification activates Archive Audit processing and specifies that the WEEKLY job's WEEK300 step automatically submit the stand-alone AUDIT operational job to perform Archive Audit processing.
ARCHIVE AUDIT YES JOB AUTOSUBMIT

ARCHIVE HISTW

To activate the Archive Weekly History, specify either YES or NO. When YES is specified, further control over the contents of this file is available through parameters you specify in prefix.MICS.PARMS(DBMODEL). The default is NO.
Specify YES and you can also specify either STEP or JOB in the optional third positional parameter. Specify STEP includes the Archive Weekly History processing in the WEEK300 step of the WEEKLY operational job. Specify STEP also allows offloading the Archive Weekly History processing to the stand-alone HISTW operational job. STEP is the default.
The JOB option reduces WEEKLY operational job execution time and increase database availability by moving the Archive Weekly History processing to the stand-alone HISTW job. This job allocates the
MICS database
files DISP=SHR and thus can execute concurrently with reporting, end-user inquiry, and other read-only processing. This process must complete before the next WEEKLY operational job is allowed to execute. If HISTW has not completed, then the WEEKLY job abends with messages reporting that HISTW must complete before executing WEEKLY.
Note:
The STEP/JOB parameter is ignored when you specify NO.
In the optional fourth positional parameter, you can specify AUTOSUBMIT or NOAUTOSUBMIT. AUTOSUBMIT indicates whether the WEEK300 step of the WEEKLY operational job does automatically write the HISTW job to the internal reader. NOAUTOSUBMIT submits the HISTW job externally, per your data center's production job scheduling facilities. NOAUTOSUBMIT is the default.
  • If your data center standards allow job submission through the internal reader, specifying AUTOSUBMIT ensures that the HISTW job is submitted for execution at the proper time. Remember that the HISTW job must complete before the next WEEKLY operational job can execute.
  • If you specify NOAUTOSUBMIT (or take the default) ensure that the HISTW job is submitted for execution after the WEEKLY job completes.
  • The AUTOSUBMIT/NOAUTOSUBMIT parameter is ignored when you specify NO (no Archive Weekly History processing) in the second positional parameter, or if you specify STEP in the third positional parameter (perform Archive Weekly History processing in the WEEK300 step).
The following example ARCHIVE specification activates Archive Weekly History processing and specifies that the WEEKLY job's WEEK300 step automatically submit the stand-alone HISTW operational job to perform Archive Weekly History processing.
ARCHIVE HISTW YES JOB AUTOSUBMIT

ARCHIVE HISTM

To activate the Archive Monthly History, specify either YES or NO. When YES is specified, further control over the contents of this file is available through parameters you specify in prefix.MICS.PARMS(DBMODEL). The default is YES.
Specify YES and you can also specify either STEP or JOB in the optional third positional parameter. Specify STEP includes the Archive Monthly History processing in the MONTH300 step of the MONTHLY operational job. Specify STEP also allows offloading the Archive Monthly History processing to the stand-alone HISTM operational job. STEP is the default.
The JOB option reduces MONTHLY operational job execution time and increase database availability by moving the Archive Monthly History processing to the stand-alone HISTM job. This job allocates the
MICS database
files DISP=SHR and thus can execute concurrently with reporting, end-user inquiry, and other read-only processing. This process must complete before the next MONTHLY operational job is allowed to execute. If HISTM has not completed, then the MONTHLY job abends with messages reporting that HISTM must complete before executing MONTHLY.
Note:
The STEP/JOB parameter is ignored when you specify NO.
In the optional fourth positional parameter, you can specify AUTOSUBMIT or NOAUTOSUBMIT. AUTOSUBMIT indicates whether the MONTH300 step of the MONTHLY operational job does automatically write the HISTM job to the internal reader. NOAUTOSUBMIT submits the HISTW job externally, per your data center's production job scheduling facilities. NOAUTOSUBMIT is the default.
  • If your data center standards allow job submission through the internal reader, specifying AUTOSUBMIT ensures that the HISTM job is submitted for execution at the proper time. Remember that the HISTM job must complete before the next MONTHLY operational job can execute.
  • If you specify NOAUTOSUBMIT (or take the default), ensure that the HISTM job is submitted for execution after the MONTHLY job completes.
  • The AUTOSUBMIT/NOAUTOSUBMIT parameter is ignored when you specify NO (no Archive Monthly History processing) in the second positional parameter, or if you specify STEP in the third positional parameter (perform Archive Monthly History processing in the MONTH300 step).
The following example ARCHIVE specification activates Archive Monthly History processing and specifies that the MONTHLY job's MONTH300 step automatically submit the stand-alone HISTM operational job to perform Archive Monthly History processing.
ARCHIVE HISTM YES JOB AUTOSUBMIT

BACKUP FREQ

This parameter tells
MICS
how often to back up the entire online database. SCHEDULE job or the SCHEDULE command of the Operational Status and Tracking facility executes this parameter. Your options are DAILY, BI-DAILY (every other day, which is really every other
MICS
update run), and WEEKLY. The default is DAILY.
Note:
We recommend BI-DAILY. The trade-off is between processing time to do the backups and processing time to do recovery if the database is destroyed. The more recent the backup, the less raw measurement data you have to reprocess to get back up-to-date.

DAYSMF FILES

It is possible for the
MICS DAILY
update job to abend for reasons other than program errors (for example, a tape I/O error).
MICS
supports a comprehensive restart facility should this occur. The intermediate files written by the DAYSMF step must not be scratched to restart the DAILY job. If you specify PERMANENT on this statement, these files are always available and there is no danger of your local disk space manager scratching them before you can restart the job. If you specify TEMPORARY, these files are allocated at the beginning of the
MICS DAILY
job and scratched at its end. They are allocated and cataloged with "permanent" OS data set names even if you specify TEMPORARY. However, they might be on disk volumes that get "cleaned" before the job can be restarted.
This parameter only has meaning if the DAILY job uses intermediate files for SMF data. For more information, see the SMFRECORDING option in Database Unit Control Definitions.
Also, this parameter has no effect on processing performed or data sets allocated by the optional incremental update facility SPLITSMF job (the stand-alone DAYSMF step) that splits data for INCRccc processing. SPLITSMF processing is controlled by the SMFRECORDING option and by the individual product INCRSPLIT USE parameter in prefix.MICS.PARMS(cccOPS).

DAYSMF OFF

To avoid reading the same SMF data records into multiple DAILY job steps, create a job that separates the records into permanent OS data sets. This process is the same as performed by the DAYSMF step except that all the components in the database unit must be provided for. The created data sets are defined to
MICS
through the INPUTccc members in prefix.MICS.PARMS.
Since you are preprocessing the SMF data, the
MICS
DAYSMF step must not be generated in the DAILY jobs. To turn off the DAYSMF step, code DAYSMF OFF in your JCLDEF member and regenerate each DAILY job stream.
This parameter applies only to the DAILY job, has no effect on the optional incremental update facility SPLITSMF job, and is unrelated to the INCRSPLIT USE parameter in prefix.MICS.PARMS(cccOPS).

DAYSMF EXCLUDE ccc ccc (component list)

Excluding a component from DAYSMF processing. For example, the DB2 data is filtered due to volume by an external process and therefore does not need to pass through the DAYSMF step. Another example, you are using the
SMF Director
split facility which has already separated the input file. To exclude one or more components, use this form of the DAYSMF parameter. This format is not applicable to Field Developed Applications (FDAs).

SMFDIRECTOR ccc ccc (component list)

(Optional) Specifies which components use an
SMF Director
duplicate split index as input in their respective DAILY update step. For each component specified on this statement, the prefix.MICS.PARMS(INPUTccc) must be updated to add the SMFDRCTR DD statement. For more information about using the
SMF Director
duplicate split indexes as input, see Integration with
SMF Director
.

EXCLUDESTEP timespan stepnumber

This optional parameter lets you exclude certain steps from the operational jobs. The timespan and stepnumber that can be specified are as follows:
Timespan: DAILY WEEKLY MONTHLY YEARLY stepnumber: 200 400 500
The 200 steps are exception analyzer database updates, the 400 steps are for reporting, and the 500 steps are for user processing. If any of these steps are not needed, excluding them from the operational jobs results in less resource consumption.
More than one stepnumber can be specified on one line, and more than one EXCLUDESTEP line is allowed. Here is an example:
EXCLUDESTEP DAILY 500 EXCLUDESTEP WEEKLY 400 500
In this example, the DAY500 step is excluded from the DAILY job, and the WEEK400 and WEEK500 steps are excluded from the WEEKLY job.
The default is to include all steps.

MONTHLY BACKUP

This parameter determines whether the MONTHLY job initiates a database backup.
YES
(Default) Example: MONTHLY BACKUP YES
NO
Specifies that the MONTHLY job does not initiate a backup. In this case, consider submitting the stand-alone BACKUPM job independently after the MONTHLY job to keep a monthly backup of your database.
Note:
When you want to use your installation's production batch job scheduling facility to perform this backup, it is necessary to specify NO.

RESTORE BACKUP

Determines whether the RESTORE job attempts to back up the database before performing the restore operation.
YES
If YES is specified and the RESTORE job cannot perform the backup because of damage to the database, the RESTORE job can be restarted at the restore step bypassing the failing backup step.
NO
(Default) Example: RESTORE BACKUP NO