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.1 Database Unit Control Definitions
2.3.3.2.1.1 Database Unit Control Definitions
The control definitions define which CA MICS products are to
be used, the name of the database, which products (for which
SMF is an optional data source) will take their input from
SMF, and the data set names' qualifiers or prefixes to be
used for data set naming and cataloging.
COMPLEXPARMS:
This optional statement controls the parameter sharing
status. 'YES' indicates that parameter sharing will be
active; 'NO' deactivates parameter sharing. If used,
this must be the first statement in JCLDEFC.
For more information about JCLGEN Parameter Sharing, see
section 2.3.3.2.1.8.
DATABASE:
A DATABASE statement must be provided. The first
parameter is the database name, a 1- to 8-character name
used to identify the database during generation. The
name should begin with an alphabetic character and
cannot contain any special values or imbedded blanks.
The second parameter, following the database name, is a
1-character JCL procedure identifier called the Database
Identifier. Valid values are A-Z and 0-9. This
identifier must be specified; a blank is NOT a valid
identifier.
Note: You should not use numeric database identifiers
(0-9) until you have exhausted all possible
alphabetic identifiers (A-Z). Due to syntax
restrictions on ddnames and SAS names, special
constructs are required for numeric units. For
example, MICF allocates the A unit DAYS timespan
with the ddname ADAYS and references this ddname
by the &AHARD macro variable (for the Hardware
Information Area). However, for the 5 unit, the
ddname and macro variable are N5DAYS and &_5HARD.
The identifier is appended to the names of the following
JCL procedures created by JCLGEN:
MICSDB - Access database DISP=OLD
MICSDU - Batch TSO Execution
MICSNDB - Invoke SAS without database allocation
MICSSHR - Access database DISP=SHR
It is necessary to have different JCL procedures for
each CA MICS database unit at an installation. To
prevent two databases from using the same procedure
identifier, a table of previously used identifiers is
maintained in sharedprefix.MICS.GENLIB(DBTABLE). This
table is checked to see whether the identifier specified
has been used with a different PREFIX statement. If the
identifier has been previously used with a different
PREFIX statement, JCLGEN processing is immediately
terminated.
Since the DBTABLE is in sharedprefix.MICS.GENLIB, the
duplicate procedure protection extends only to CA MICS
unit databases in a complex. It is the responsibility
of the CA MICS System Administrator to ensure the
uniqueness of the procedure identifier, when multiple
databases do not share the same shareprefix.MICS.GENLIB
library. For techniques on using alternate procedure
names for multiple complexes sharing a single PROCLIB,
see section 2.3.3.3.2.3.
The third keyword parameter on the DATABASE statement is
the database type. The possible values are PRIMARY,
UNIT, SPECIAL, or TEST. For preliminary testing
purposes, a TEST database unit may be installed without
defining a PRIMARY database unit. However, the first
production database unit installed in a database complex
should have PRIMARY specified. Only the PRIMARY
database backs up the complex level data libraries.
Other database units may then be designated as UNIT,
SPECIAL, or TEST.
Information from TEST database units is not included in
CA MICS Accounting and Chargeback processing if at least
one UNIT or PRIMARY unit in the complex contains CA MICS
Accounting and Chargeback. TEST units are also treated
differently by JCLGEN. SPECIAL databases are temporary
databases for special studies or other uses.
COMPONENTS:
One or more COMPONENTS statements must be provided to
specify which CA MICS products should be included in the
CA MICS unit. The parameters for component
identification are the standard 3-character product
identifiers.
Products that do not have processing activity at the
database unit level (e.g., no step in the DAILY job),
can be specified but they are ignored in JCLGEN
processing. PER and STG are examples of such products.
All components are optional, but at least one must be
selected. Note the following special considerations:
o BAS (CA MICS Platform) is not specified on the
COMPONENTS statement, but is automatically included
in every database unit.
o The ACT identifier for CA MICS Accounting and
Chargeback may not be specified in a SPECIAL
database unit.
o If you want to include sharedprefix.MICS.CAPACITY
in the PRIMARY unit database BACKUP process, you
can specify the CAP component on the COMPONENTS
statement in the PRIMARY database unit. Otherwise,
there is NO need to specify the CAP component on
any COMPONENTS statement. Note, CAP is only valid
when the third keyword of the DATABASE statement is
PRIMARY (indicating the PRIMARY unit).
No processing support is included in the generated
system for products that are not specified in the
COMPONENTS statement.
SMFRECORDING:
Many CA MICS products that take input from external
non-SMF log files also support the standard SMF data set
as an optional data source. If your site uses SMF data
rather than or in addition to external non-SMF log data,
you must code one or more SMFRECORDING statements in the
JCLDEF member of the prefix.MICS.PARMS data set. Valid
values include AST, CICS, HSM, IDM, SNT, and VCA. For
more information on products that can use SMFRECORDING,
see the product guides.
If more than one CA MICS product that takes input from
SMF is specified on the COMPONENTS statement described
earlier in this section, a job step named DAYSMF is
generated as the second step of the DAILY job. DAYSMF
splits the SMF input file (defined by
prefix.MICS.PARMS(INPUTRDR)) into multiple work files,
one for each CA MICS product which takes its input from
SMF. The ddname of INPUTSMF is used to address the work
file in DAILY job steps for products that input such
work files.
If only one CA MICS product uses SMF input, JCLGEN does
not create a DAYSMF step to split the SMF input file.
Rather, the SMF file that is defined in
prefix.MICS.PARMS(INPUTRDR) goes directly into the DAILY
job step for that one product, improving CA MICS
performance in this special case.
If you are using the optional incremental update
facility, you may choose to execute a stand-alone
version of the DAYSMF step (the SPLITSMF job) to
pre-select input data for your INCRccc jobs. The
SPLITSMF job dynamically allocates and populates a data
set for each CA MICS product which takes its input from
SMF AND which has been marked with the INCRSPLIT USE
option in prefix.MICS.PARMS(cccOPS). The ddname of
INPUTSMF is used to address the input file in the
INCRccc jobs.
If CICS is specified on the SMFRECORDING statement, a DD
statement for ddname INPUTSMF is generated by JCLGEN
according to the above rules. The DAY040 step may also
take input from non-SMF files defined in
prefix.MICS.PARMS(INPUTCIC) even when SMF input is used
(depending on the parameters that are specified on the
CICOPTS statements in prefix.MICS.PARMS(CICOPS)). If
CICS is not specified on the SMFRECORDING statement,
then the only input available to the CICS (DAY040) step
in the CA MICS DAILY update job will be that supplied
by DD statements in prefix.MICS.PARMS(INPUTCIC). (The
ddnames must also be identified in
prefix.MICS.PARMS(CICOPS)).
If VCA is specified on the SMFRECORDING statement, a DD
statement for ddname INPUTSMF is generated by JCLGEN
according to the above rules. The DAY090 step may also
take input from non-SMF files defined in
prefix.MICS.PARMS(INPUTVCA) even when SMF input is also
used. All input for the VCA Analyzer is taken from the
INPUTSMF DD statement. If SMF and non-SMF data are
mixed, the INPUTVCA member must contain only the DD
statements to be concatenated to the INPUTSMF DD
statement made by JCLGEN. If VCA is not specified on
the SMFRECORDING statement, the only input available to
the DAY090 step in the CA MICS DAILY update job will be
that supplied by DD statements in
prefix.MICS.PARMS(INPUTVCA). This DD statement must
define the ddname INPUTSMF.
In the appropriate product guide, see the chapter on
planning, installation definitions, or parameters for more
information on the options for the product.
PREFIX:
The PREFIX statement is used to identify the data sets
associated with a CA MICS database unit; therefore,
this statement is required. Since there may be more
than one CA MICS database at your site, the prefix must
be unique and cannot have the same value as the
SHAREDPREFIX. A table of prefixes and the value of
sharedprefix is maintained in
sharedprefix.MICS.GENLIB(DBTABLE). A prefix can consist
of more than one node (qualifier), but cannot exceed 14
characters in length. The prefix is used to complete
the data set names for the following data sets:
prefix.MICS.CHECKPT.DATA
prefix.MICS.CNTL
prefix.MICS.IMSSUS1
prefix.MICS.IMSSUS2
prefix.MICS.MODEL
prefix.MICS.MUOLIB
prefix.MICS.PARMS
prefix.MICS.RESTART.CNTL
prefix.MICS.USER.SOURCE
prefix.MICS.SPECIAL.SOURCE
prefix.MICS.DETAIL
prefix.MICS.DAYS
prefix.MICS.WEEKS
prefix.MICS.MONTHS
prefix.MICS.YEARS
An additional qualifier (MICS.) will be added behind
your prefix value unless you specify the optional
NOMICSLEVEL parameter following your prefix value. See
the "Generation of CA MICS Data Set Names" discussion
below for further details.
TAPEPREFIX:
The TAPEPREFIX statement is optional. It is used to
uniquely identify tape data sets created by CA MICS.
The prefix can consist of more than one node
(qualifier), but cannot exceed 14 characters in length.
If this statement is not specified or left blank, the
tape data sets will have the same prefix defined on the
PREFIX statement.
Note: Many (GDG) data sets will be cataloged under this
index. If the prefix is a TSO user ID, it may impair
that user's use of the LISTCAT command due to the
voluminous output.
The TAPEPREFIX statement is used to form the name of the
following CA MICS data sets:
tapeprefix.MICS.AUDIT.iiifff.GggggV00
tapeprefix.MICS.BACKUP.tttttt.GggggV00
tapeprefix.MICS.BACKUP.CHECKPT.GggggV00
tapeprefix.MICS.HISTW.iiifff.GggggV00
tapeprefix.MICS.HISTM.iiifff.GggggV00
tapeprefix.MICS.MBACKUP.tttttt.GggggV00
tapeprefix.MICS.MBACKUP.CHECKPT.GggggV00
Note: In the list above, iiifff represents a
CA MICS file name and tttttt is a time-span or can
be SCREENS, TABLES, CAPACITY, CIMANAGE, or ISPTLIB.
Generation of CA MICS Data Set Names
You can specify whether or not ".MICS." follows the
sharedprefix, prefix, and tapeprefix levels when data set
names are generated. If you want ".MICS." appended to any of
these prefixes, specify the keyword "MICSLEVEL." If you do
NOT want ".MICS." appended to any of these prefixes, specify
the keyword "NOMICSLEVEL." Place the keyword "MICSLEVEL" or
"NOMICSLEVEL" after, but on the same line as, the definition
of SHAREDPREFIX, PREFIX, or TAPEPREFIX. When "NOMICSLEVEL"
is specified, the prefix length limit increases from 14 to
19. If no keyword is specified, the default MICSLEVEL is
used so that ".MICS." follows the prefix. Figure 2-22 shows
the resultant data set names that are formed when MICSLEVEL
and NOMICSLEVEL are specified in conjunction with the three
prefixes.
+-----------------------------------+-----------------------+
|JCLDEF Keyword Value | Data Set Names Formed |
+-----------------------------------+-----------------------+
|SHAREDPREFIX EYCS MICSLEVEL | EYCS.MICS.SOURCE |
|PREFIX EYP MICSLEVEL | EYP.MICS.CNTL |
|TAPEPREFIX EYCT MICSLEVEL | EYCT.MICS.BACKUP.DAYS |
+------------- ---------------------+-----------------------+
|SHAREDPREFIX EYCS NOMICSLEVEL | EYCS.SOURCE |
|PREFIX EYP NOMICSLEVEL | EYP.CNTL |
|TAPEPREFIX EYCT NOMICSLEVEL | EYCT.BACKUP.DAYS |
+------------- ---------------------+-----------------------+
|SHAREDPREFIX EYCS | EYCS.MICS.SOURCE |
|PREFIX EYP.TEST.MICS4 NOMICSLEVEL | EYP.TEST.MICS4.CNTL |
|TAPEPREFIX EYCT.DAILY NOMICSLEVEL | EYCT.DAILY.BACKUP.DAYS|
+-----------------------------------+-----------------------+
Figure 2-22. NOMICSLEVEL Data Set Name Formation
A more comprehensive control over CA MICS data set names is
available. For more information about CA MICS data set
names, see section 2.3.3.3.2.3, CA MICS User Names Table
(JCLNAMES).
