3. Maintenance Policies and Procedures › 3.2 User Maintenance Procedures › 3.2.2 User Change Control Procedure › 3.2.2.1 Identification

3.2.2.1 Identification

The goal of change control procedures is to ensure a tested
modification that produces the desired results.  The desired
results are usually improvements in the performance or
application of CA MICS at your site, or the introduction of
some new input source into the CA MICS database.
Source of Data

If the modification involves treating a new data source,
document the source.  Some examples of new data sources are
user-generated appendages to SMF records, entire special
purpose SMF records, or manually-generated operations data.
Regardless of the source, documentation is essential to the
success of CA MICS modifications that use the inputs.

    The documentation should include:

    - The source of the input, such as the SMF log, or a
      data entry function.

    - The format of each type of record, including the
      location and SAS INFORMAT specifications for each data
      element in each record type.

    - The availability of the input source, including the
      time of day the data can be input to a CA MICS update
      cycle, and what corporate entity is responsible for the
      integrity of the input.
Database Output

If the modification involves adding new data elements or
whole files to the CA MICS database, the output of the daily
update cycle must be documented.  The examples noted above
could cause data elements to be added to existing CA MICS
files, or could cause entire user components to be added to
CA MICS.

    The documentation should include:

    - The list of files to be modified, if the files
      currently exist.

    - The description of files to be added to the CA MICS
      database, and the structure of the user component to
      which these files will belong.

    - The list of data elements added by the process,
      including the SAS data element length and output format
      of each.
Tangible Output

Usually a modification involves the production of some
form of tangible output, such as a report or an extracted
output file to be used as input to some further process.  The
examples noted above might enable resource utilization or
billing reports to be created using extended accounting
information, or may enable site-unique exceptions to be added
to the CA MICS administrative Information Area.

    The documentation should include:

    - The list of existing reports into which the new
      material must be integrated, and considerations for
      doing the integration.

    - The description of new reports or other CA MICS output
      that will contain information from the new source,
      including report/record content descriptions.
Benefit Analysis

If a modification involves improvement in the performance or
application of CA MICS, the benefits of such a modification
should be examined.  For example, some extension of the
normal CA MICS input checkpointing mechanism might inform the
computer operator of a possible data loss condition.  Such a
modification should be evaluated for benefits:  Does the
operator communication serve the useful purpose of helping
the operator locate missing CA MICS input? Or would such
communication merely slow down the daily update process with
a needless operator message with every update?

    The documentation should include:

    - Identification of the CA MICS user or CA MICS support
      person who would benefit.

    - A description of the benefit.

    - The list of CA MICS operational considerations
      necessary to use the new procedure.
Impact Analysis

Any modification involves actually changing CA MICS code or
adding code to CA MICS. A complete list of CA MICS modules
affected must be made and evaluated.

Some CA MICS modules lend themselves to modification more
readily than others, and some CA MICS modules should not be
modified at all.  For example, if you are considering
modifying the CA MICS JCL Generator, there is generally a way
to modify the CA MICS prototype library instead to produce
the desired result.

    The documentation should include:

    - The identification of the CA MICS module or functional
      area to be modified.

    - The description of the modification.

    - The list of CA MICS operational dependencies seen at
      this stage.  That is, if an update were made in module
      A, then module B must be changed to accommodate the
      modification.