2. Planning for Installation and Use of CA MICS › 2.3 Installation Planning and Parameter Specification › 2.3.3 CA MICS JCL Planning and Parameters › 2.3.3.2 Standard JCLGEN Parameters › 2.3.3.2.1 JCL Option Definitions (JCLDEF) › 2.3.3.2.1.3 Database Unit Execution Option Definitions
2.3.3.2.1.3 Database Unit Execution Option Definitions
The execution options parameter statements enable you to
select database archive options, select the method for file
storage of work files used in the daily CA MICS job, and
define the frequency of database backup.
The options discussed in this section must be specified
before the CA MICS system is generated. If they are changed,
part of the generation process must be repeated before the
change takes effect. There are additional execution options
that may be changed without running any of the CA MICS
generation processes. These parameters are discussed in
Section 2.3.5.
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/or 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
sections 4.3.13.1 and 4.3.13.2 respectively.
ARCHIVE AUDIT:
Specify either YES or NO to indicate whether the Archive
Audit is to be activated. If you specify YES, then
further control over the amount of data available in the
Archive Audit files is available through the AUDITGDG
parameter described below and parameters you specify in
prefix.MICS.PARMS(DBMODEL). The default is YES.
If you specify YES, you can also specify either STEP or
JOB in the optional third positional parameter to
indicate whether the Archive Audit processing is to be
included in the WEEK300 step of the WEEKLY operational
job, or if Archive Audit processing is to be offloaded
to the stand-alone AUDIT operational job. STEP is the
default.
With the JOB option, you can reduce 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 CA MICS database
files DISP=SHR and thus can execute concurrently with
reporting, end-user inquiry, and other read-only
processing. It must complete before the next DAILY
operational job is allowed to execute. If AUDIT has not
completed, then the DAILY job DAYALL step will abend
with messages reporting that AUDIT must complete before
executing DAILY.
Note: The STEP/JOB parameter is ignored when you specify
NO (no Archive Audit processing).
Specify either AUTOSUBMIT or NOAUTOSUBMIT in the
optional fourth positional parameter to indicate whether
the WEEK300 step of the WEEKLY operational job will
automatically write the AUDIT job to the internal reader
(AUTOSUBMIT) or whether you will submit the AUDIT job
externally, per your data center's production job
scheduling facilities (NOAUTOSUBMIT). NOAUTOSUBMIT is
the default.
o If your data center standards allow job submission
through the internal reader, specifying AUTOSUBMIT
guarantees 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.
o If you specify NOAUTOSUBMIT (or take the default)
you must ensure that the AUDIT job is submitted for
execution after the WEEKLY job completes.
o 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). You must specify the third positional
parameter in order to specify a value for the
AUTOSUBMIT/NOAUTOSUBMIT parameter.
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:
Specify either YES or NO to indicate whether the Archive
Weekly History is to be activated or not. Note that if
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.
If YES is specified, you can specify either STEP or JOB
in the optional third positional parameter to indicate
whether the Archive Weekly History processing is to be
included in the WEEK300 step of the WEEKLY operational
job, or if Archive Weekly History processing is to be
offloaded to the stand-alone HISTW operational job.
STEP is the default.
With the JOB option, you can reduce 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 CA MICS
database files DISP=SHR and thus can execute
concurrently with reporting, end-user inquiry, and other
read-only processing. It must complete before the next
WEEKLY operational job is allowed to execute. If HISTW
has not completed, then the WEEKLY job will abend with
messages reporting that HISTW must complete before
executing WEEKLY.
Note: The STEP/JOB parameter is ignored when you specify
NO (no Archive Weekly History processing).
Specify either AUTOSUBMIT or NOAUTOSUBMIT in the
optional fourth positional parameter to indicate whether
the WEEK300 step of the WEEKLY operational job will
automatically write the HISTW job to the internal reader
(AUTOSUBMIT) or whether you will submit the HISTW job
externally, per your data center's production job
scheduling facilities (NOAUTOSUBMIT). NOAUTOSUBMIT is
the default.
o If your data center standards allow job submission
through the internal reader, specifying AUTOSUBMIT
guarantees 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.
o If you specify NOAUTOSUBMIT (or take the default)
you must ensure that the HISTW job is submitted for
execution after the WEEKLY job completes.
o 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). You must specify
the third positional parameter in order to specify
a value for the AUTOSUBMIT/NOAUTOSUBMIT parameter.
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:
Specify either YES or NO to indicate whether the Archive
Monthly History is to be activated. Note that if 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.
If YES is specified, you can specify either STEP or JOB
in the optional third positional parameter to indicate
whether the Archive Monthly History processing is to be
included in the MONTH300 step of the MONTHLY operational
job, or if Archive Monthly History processing is to be
offloaded to the stand-alone HISTM operational job.
STEP is the default.
With the JOB option, you can reduce 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 CA MICS
database files DISP=SHR and thus can execute
concurrently with reporting, end-user inquiry, and other
read-only processing. It must complete before the next
MONTHLY operational job is allowed to execute. If HISTM
has not completed, then the MONTHLY job will abend with
messages reporting that HISTM must complete before
executing MONTHLY.
Note: The STEP/JOB parameter is ignored when you specify
NO (no Archive Monthly History processing).
Specify either AUTOSUBMIT or NOAUTOSUBMIT in the
optional fourth positional parameter to indicate whether
the MONTH300 step of the MONTHLY operational job will
automatically write the HISTM job to the internal reader
(AUTOSUBMIT) or whether you will submit the HISTM job
externally, per your data center's production job
scheduling facilities (NOAUTOSUBMIT). NOAUTOSUBMIT is
the default.
o If your data center standards allow job submission
through the internal reader, specifying AUTOSUBMIT
guarantees 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.
o If you specify NOAUTOSUBMIT (or take the default),
you must ensure that the HISTM job is submitted for
execution after the MONTHLY job completes.
o 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). You must specify
the third positional parameter in order to specify
a value for the AUTOSUBMIT/NOAUTOSUBMIT parameter.
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 CA MICS how often to back up the
entire online database. Your options are DAILY,
BI-DAILY (every other day, which is really every other
CA MICS update run), and WEEKLY. The default is DAILY.
Note: We recommend BI-DAILY. The trade-off you must
make 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 will have to reprocess to get back
up-to-date).
DAYSMF FILES:
It is possible for the CA MICS DAILY update job to abend
for reasons other than program errors (for example, a
tape I/O error). CA MICS supports a comprehensive
restart facility should this occur. The intermediate
files written by the DAYSMF step must not be scratched
in order 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 CA 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 section 2.3.3.2.1.1,
"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, you may create a job that separates the
records into permanent OS data sets. This is the same
process performed by the DAYSMF step except that you
must provide for the needs of all the components in the
database unit. The data sets thus created have to be
defined to CA MICS via the INPUTccc members in
prefix.MICS.PARMS. Since you are preprocessing the SMF
data, the CA 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)
In some cases, it may be desirable to exclude a
component from DAYSMF processing. For example, the DB2
data may be so voluminous that it has already been
filtered by an external process and therefore does not
need to pass through the DAYSMF step. Or, you may be
using the CA SMF Director split facility which has
already separated the input file. Use this form of the
DAYSMF parameter to exclude one or more components (not
applicable to Field Developed Applications (FDAs)).
SMFDIRECTOR ccc ccc (component list)
This optional parameter allows you to specify which
components will use a CA 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. See section 4.10 of PIOM guide
for complete information on using the CA SMF Director
duplicate split indices as input.
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 will
perform a database backup. If NO is specified, the
MONTHLY job does not submit the backup job BACKUPM. In
this case, consider submitting the BACKUPM job
independently after the MONTHLY job to keep a monthly
backup of your database. The default is MONTHLY BACKUP
YES.
RESTORE BACKUP:
This parameter determines whether the RESTORE job will
attempt to back up the database before performing the
restore operation. 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. The
default is RESTORE BACKUP NO.
