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.4 Database Complex Definition › 2.3.1.4.2 Multi-System/Site Database Planning

2.3.1.4.2 Multi-System/Site Database Planning

The CA MICS Database may contain data from one or more
computing systems.  If you have multiple OS/390 systems or
multiple distributed systems, then some thought should be
given to the best CA MICS database configuration for your
installation's requirements.  If your installation only has
one OS/390 System for which data will be maintained by
CA MICS, then the issues discussed in this section may not be
pertinent.

To CA MICS, a "computing system" is identified by a unique
SYSID -- One SYSID, one system; two SYSIDs, two systems.  For
example, OS/390 multiprocessors (MPs) operating as a single
LPAR are single systems to CA MICS because they are
associated to a single SMF SYSID.  On the other hand,
"loosely" coupled systems, as one finds in an OS/390, JES3
complexes, or SYSPLEX JES2 Multi-Access Spool environments,
are multiple systems to CA MICS (note, however, that the data
from all member systems of a loosely-coupled complex must go
into the same CA MICS database).

You should do the following when planning your database(s)
and its(their) configuration:

    1.  Ensure that unique computing system identifications
        (SMF "SYSID"s) are being used on all the systems to
        be included.  You must NEVER be running the same
        SYSID on two systems at once.

    2.  If you intend to put data from more than one system
        in a database, ensure that you have in place an
        operational process to bring the measurement data
        together from the different processors.  If this has
        not yet been worked out, it may be most unwise to
        demand that it be implemented at the same time as,
        and for the purpose of supporting, CA MICS.  As an
        alternative, use separate database units to store
        the data from each of the systems.  It is also
        possible to create multiple database complexes if
        the systems do not share proclibs.  However, this
        increases overhead needed for CA MICS system library
        space, and to perform CA MICS installation and
        maintenance tasks and so is not recommended.

    3.  Recognize that all machines in a loosely-coupled (as
        defined above) complex must have their data stored in
        a single database.  This is because in such
        environments, a job may be read in on one CPU,
        executed on another, and printed on a third.  SMF
        records for such a job will be cut on all three
        systems, and the proper operation of CA MICS
        requires that all the data for the job be brought
        together for processing.

The concept of a commonly defined and maintained database
available at a single site for a data processing department
having multiple data centers is appealing for the purposes
of corporate capacity planning, organizational control,
auditing, etc.  CA MICS enables a multi-site organization to
take a giant stride closer to achieving the "headquarters
database".

There is more than one way of implementing such a centralized
database.  We believe that it would be a mistake for most
organizations to attempt to transport raw measurement data to
the central point in order to feed CA MICS.  Rather, CA MICS
should be installed at each installation using the guidelines
presented above.  Periodically, say monthly, the headquarters
or central office could easily extract the desired data files
(if it is done monthly, the CA MICS MONTHS files would be the
ones of interest) from each CA MICS database, and construct a
single headquarters database containing the selected data for
all computing systems.

Our suggestions for achieving this objective are as follows:

    1.  Ensure that unique and identifiable computing system
        identifications (SMF "SYSID"s) are being used on all
        systems to be included.

    2.  Agree upon standards governing the data files that
        will be maintained and agree on retention periods,
        so that each system can be defined to incorporate
        these decisions.

    3.  Define the data collection interval, which should
        be no less than weekly, but no greater than
        quarterly.

    4.  Define how the data will be transmitted at the
        defined collection intervals.  Teleprocessing is, of
        course, attractive, but the most practical way may
        be simply writing the required CA MICS files on a
        tape in SAS format, mailing it to headquarters, and
        having headquarters personnel load the data into
        the headquarters database.

    5.  Use separate CA MICS database units to store the
        data collected from other sites.

We expect that there will be many organization-specific
considerations involved in establishing a headquarters
database and reporting structure.  In designing your approach
to a headquarters database, please feel free to contact the
CA MICS Product Support Group for assistance.