|
|
|
The parameter specifications in this section are critical.
After making changes to these parameters, you must execute
prefix.MICS.CNTL(CYCLEGEN) before your changes take effect.
If archive specifications have changed such that a file is
either activated or deactivated, you must also execute
prefix.MICS.CNTL(JCLGENU) to regenerate the corresponding job
or job step.
Data Retention Specifications tell the database how many
cycles of each file, in each supported timespan, to save both
online and in archive mode. In addition, Data Retention
Specifications also control whether or not eligible audit and
history archive files are actually created.
FILE statements must directly follow the DATABASE statement
The operands in the FILE statement are free-form and
positional. All operands are required.
Files that are not supported within a given timespan are
indicated by the presence of a 0 retention limit, while those
that are supported have a non-zero value.
Except for the archive timespans, a file that is defined as
active within a timespan must have a retention limit greater
than zero. (See Special Negative/ Hyphen Flag below.) The
sharedprefix.MICS.GENLIB(cccGENIN) member, where ccc is the
component identifier, contains FILE statements used by the
Component Generator to define a file as active or inactive
for each timespan. The retention limits defined in the
DBMODEL FILE statement should be consistent with the file
definitions contained in the cccGENIN FILE statement used to
generate the product.
The archive history timespans (wha and mha below) may have a
retention limit of zero in order to deactivate a file in any
particular unit. The audit archive timespan (aud) has a
unique set of specifications.
We recommend using the initial retention values from the Data
Retention portion of the Installation Preparation Worksheets
for the first space modeling analysis.
STATEMENT FORMAT:
FILE ccc name retx retd retw retm rety rett wha mha aud
OPERAND DESCRIPTIONS:
ccc The 3-character component identifier associated
with this file.
name The six-character CA MICS file identifier.
retx The number of days of data being retained in the
DETAIL timespan of the database for this file.
retd The number of days of data being retained in the
DAYS timespan of the database for this file.
retw The number of weeks of data being retained in the
WEEKS timespan of the database for this file. The
maximum value is 99.
retm The number of months of data being retained in the
MONTHS timespan of the database for this file.
The maximum value is 99.
rety The number of years of data being retained in the
YEARS timespan of the database for this file. The
maximum value is 99.
You may exercise further control over the contents
of the YEARS timespan using the YEARS timespan
parameter (refer to Section 2.3.2.4, Site
Characteristics (SITE)).
rett The number of levels of data being retained in the
TABLES Data Area of the database for this file.
For any given file, the values for rett MUST be the
same in all database units. The maximum value is
99.
wha The number of weeks of data being retained in the
WEEKS timespan for the weekly history archive.
The weekly history files are created with
"oldmaster + updates => newmaster" logic, where the
oldmaster is the previous week's archive tape and
the updates are this week's WEEKS files, so each
generation of this data set has all the weekly
archive data accumulated up to the date of its
creation, subject to the cutoff that you specify
with this parameter. When the new file is created,
data older than the cutoff is dropped in order to
prevent these files from growing endlessly.
The maximum value is 156. The minimum value is 0,
in which case no weekly history archive is created
for this file.
Two other parameters, ARCHIVE HISTW and HISTWGDG,
relate to the control of this process. Refer to
Sections 2.3.3.2.1.3 and 2.3.3.2.1.5 respectively
for descriptions of these parameters. In addition,
Section 4.3.13.2 also contains information about
wha, ARCHIVE HISTW, and HISTWGDG.
mha The number of months of data being retained in the
MONTHS timespan for the monthly history archive.
The monthly history files are created with
"oldmaster + updates => newmaster" logic, where the
oldmaster is the previous month's archive tape and
the updates are this month's MONTHS files, so each
generation of this data set has all the monthly
archive data accumulated up to the date of its
creation, subject to the cutoff that you specify
with this parameter. When the new file is created,
data older than the cutoff specified here is
dropped in order to prevent these files from
growing endlessly.
The maximum value is 99. The minimum value is 0,
in which case no monthly history archive is created
for this file.
Two other parameters, ARCHIVE HISTM and HISTMGDG,
relate to the control of this process. Refer to
Sections 2.3.3.2.1.3 and 2.3.3.2.1.5 for
descriptions of these parameters. In addition,
Section 4.3.13.2 also contains information about
mha, ARCHIVE HISTM, and HISTMGDG.
aud Specifies whether or not an audit archive tape is
created for this file.
- AUDIT(NO) deactivates audit archive for this
file. This parameter is used to prevent the
creation of an audit archive tape for this
file.
- AUDIT(YES) activates audit archive for this
file. This parameter is commonly used to
document that audit archive is enabled for
this file.
An audit archive tape is created from the
DETAIL timespan. If the DETAIL timespan is
deactivated, the tape is created from the
DAYS timespan.
- AUDIT(DAYS) activates audit archive for this
file specifically from the DAYS timespan.
It may be necessary to use this parameter when an
audit archive tape is already created from the
DAYS timespan of this file and the normally
deactivated DETAIL timespan is activated.
Specifying AUDIT(DAYS) continues to create the
audit archive tape from the DAYS timespan.
- AUDIT(DETAIL) activates audit archive for this
file specifically from the DETAIL timespan.
The default for the AUDIT parameter is taken from
the cccGENIN member specification in
sharedprefix.MICS.GENLIB. If you want to use this
default, no specification of the AUDIT parameter is
necessary.
Note: To create an audit archive tape, audit
archive must be enabled in both cccGENIN and in
prefix.MICS.PARMS(JCLDEF). If audit archive is
disabled at the complex or unit levels, it cannot
be enabled by specifying AUDIT(YES), AUDIT(DAYS),
or AUDIT(DETAIL).
Two other parameters, ARCHIVE AUDIT and AUDITGDG,
relate to the control of this process. Refer to
Sections 2.3.3.2.1.3 and 2.3.3.2.1.5 respectively
for descriptions of these parameters. In addition,
Section 4.3.13.2 also contains information about
aud, ARCHIVE AUDIT, and AUDITGDG.
Sample FILE Statement:
FILE TSO TSOTSO 02 33 09 06 01 00 053 024 AUDIT(NO)
Refer to the various chapters on planning, installation
definitions, or parameters in the individual product guides
for information on FILE statements.
After you complete all changes to prefix.MICS.PARMS(DBMODEL),
execute prefix.MICS.CNTL(CYCLEGEN) to put your specifications
into effect.
Special Negative/Hyphen Flag
----------------------------
Normally each component's DAYnnn job step deletes each file's
highest defined DETAIL and DAYS cycles before writing the
day's new files into the database. This is done to conserve
disk space. However, when only one cycle has been specified
for a file, in other words, when the highest cycle is the
only cycle, this delete is not done. The reason is that
there would no longer be such a file in the database if the
job step continued for a long time or if it abended before
the new cycle 01 file could be written.
The administrator of a database unit can delete the 01 cycle
even if it is the only cycle of a file. This is done by
coding a hyphen (negative sign) as a flag before the retx or
retd operand values of 1 on the FILE statement.
An example of such a FILE statement follows:
FILE DB2 DB2DSP -1 10 05 03 05 00 025 012
WARNING! Before using this option, consider the risk
involved. The only existing cycle of a database file will be
deleted long before the 00 cycle of the file is ready to take
its place. If the job abends before the new cycle 01 is
written, other jobs or users attempting to use the file will
fail until either that file is restored from backup or a
restart of the DAILY job step that abended is successfully
completed. It might be appropriate to consider and adjust
the backup frequency of that file.
Database Data Retention Definitions Worksheet
---------------------------------------------
The worksheet is organized by information area. Each file in
the area is listed by name. For each file, a line is
formatted to allow six definitions in the online database and
two in the archive database:
o The online database files quantify the number of cycles of
data that will be maintained in the DETAIL, DAYS, WEEKS,
MONTHS, and YEARS timespans and the TABLES data area.
o The two definitions for the archive database files quantify
the number of cycles of data to be retained, up to the
cutoff limit defined. The archive definitions have no
impact on the size of the database and may be specified
whether or not the weekly and/or monthly archive history
files have actually been activated (see Section 2.3.3,
CA MICS JCL Planning and Parameters, of the PIOM).
The worksheet formats provide an underscored area for the
user's definition, followed by the recommended value, shown
within parentheses. If the underscored area contains a value
of 00, the file is not supported for the indicated timespan.
To add support, you must perform database tailoring as
described in Section 6.2, Tailoring the Database, of the
System Modification Guide (SMG).
When specifying a retention limit, remember that the number
may never be zero if the file has been defined to be active
in the timespan.
EXAMPLE
The FILE statements listed below illustrate how to enter
the information.
FILE BAS ADMEXC 00 08 00 06 00 00 000 000
FILE BAS ADMIHL 00 01 00 00 00 00 000 000
FILE BAS ADMCYC 00 00 00 00 00 00 000 000
FILE BAS ADMJHL 00 01 00 00 00 00 000 000
FILE BAS ADMSPC 00 01 00 00 00 00 000 000
Note: The ADMIHL, ADMJHL, and ADMSPC specifications must be
given exactly as shown.
+--------------------------------------------------------------------------+ | INSTALLATION PREPARATION WORKSHEET: Database Data Retention Definitions | | | | PARMS Library Member is DBMODEL | | | | Reference Section: 2.3.4.1.2 | +------+-----------------------------------------------+-------------------+ | | Online Database Retention | Archive Cutoff | | File |DETAIL DAYS WEEKS MONTHS YEARS TABLES | WEEKS MONTHS | | Name | __(NA) __(NA) __(NA) __(NA) _(NA) __(NA)|___ (NA) ___ (NA) | +------+-----------------------------------------------+-------------------+ |ADMEXC| 00(00) __(15) 00(00) __(12) 0(0) 00(00) |000 (000) 000 (000)| |ADMIHL| 00(00) 01(01) 00(00) 00(00) 0(0) 00(00) |000 (000) 000 (000)| |ADMCYC| 00(00) 00(00) 00(00) 00(00) 0(0) 00(00) |000 (000) 000 (000)| |ADMJHL| 00(00) 01(01) 00(00) 00(00) 0(0) 00(00) |000 (000) 000 (000)| |ADMSPC| 00(00) 01(01) 00(00) 00(00) 0(0) 00(00) |000 (000) 000 (000)| +------+-----------------------------------------------+-------------------+
Figure 2-36. Database Data Retention Worksheet
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |