2. Planning for Installation and Use of CA MICS › 2.3 Installation Planning and Parameter Specification › 2.3.1 Database Complex Planning and Parameters › 2.3.1.1 Database Complex Overview

2.3.1.1 Database Complex Overview

The purpose of this discussion is to provide an understanding
of the relationship of a CA MICS database complex to the
specification of the parameters that are the subject of this
chapter.  We will define database related terms and give
some simple examples.  A more comprehensive discussion can be
found in the System Modification Guide.

A complete and independent CA MICS system contains one and
only one database complex.  A database complex consists of
one or more databases.

There are four types of databases:

        UNIT DATABASE
        PRIMARY DATABASE
        TEST DATABASE
        SPECIAL DATABASE

A unit database consists of one or more CA MICS products.
For example, a unit database could contain the Batch and
Operations, Hardware and SCP, and CICS analyzers.

The simplest database complex would contain a single unit
database containing CA MICS platform.  You must provide the
parameters (defined in this guide and in the parameters
chapter of each guide) to create each unit database.  A unit
database requires a complete set of programs to update the
files it contains.  The input data sources (for example SMF,
RMF, CICS) must be processed to update this unit database.

One of the unit databases defined in a database complex is
called the primary database.  This should normally be the
first production database installed in the complex.  The
primary database takes responsibility for backing up the
complex level data libraries, such as tables.

Certain CA MICS libraries (those preceded by the
sharedprefix) are made available to all other databases in
the database complex and exist in only one place in the
complex.  All other libraries (those preceded by prefix or
tapeprefix) are applicable to a single database.

Consider the case where you want to separate an IMS database
from one containing SMF, RMF, and CA TSO/MON PM.  The
database complex would have a unit database containing the
Batch and Operations, Hardware and SCP, and TSO analyzers.
This would be the primary database.  A second unit database
would be defined to contain the IMS Analyzer.  Each unit
database would have a separate set of parameter definitions
and a separate generation process performed on those
parameters.  The daily update of each unit database would be
performed independently.  Therefore, any problem with IMS log
data would not affect the update of SMF, RMF, and TSO files.

Now suppose you added a second IMS system and wanted to keep
it in a different database than the first one (so each could
be updated independently) rather than have them in the same
database (which is also permissible).  You could define
another unit database for the second IMS system.

CA MICS allows considerable flexibility in defining a unit
database.  A component can have only certain timespans
active and can also deactivate files and/or selected data
elements in files.  This is called file tailoring and is
explained in the System Modification Guide.  The only point
to make here is that file tailoring is a global function that
takes place at the database complex level.

Consider our example with two unit databases for IMS.  They
must contain the same timespans, information areas, files
and data elements.  However, each IMS unit database could
have a different number of cycles for each file.  Cycles are
defined at a level local to a unit database.  Of course,
the IMS Analyzer contains one information area, but two unit
databases could contain the Hardware and SCP Analyzer (which
contains two information areas) and the principle would still
apply.

You can create a test database in order to test changes to
your CA MICS system.  While there can be certain technical
differences from a unit database (described in the System
Modification Guide), for our purposes here we consider it as
a specially marked unit database used for testing purposes.

A special database is used to create files for special study
purposes.  Unlike the unit and test databases, the special
database does not use the database complex definitions of
timespans, information areas, or files.  Therefore, a
special database can contain selected files only.

In summary, a database complex can have one primary database
and several other units, test and special databases.  The
primary and unit databases can be viewed as production
databases.  Each database is generated separately from its
own set of parameters, but shares certain libraries and
definitions at the database complex level.