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
MICS
at your site, or the introduction of some new input source into the
MICS
database.
micsrm140
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
MICS
at your site, or the introduction of some new input source into the
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
MICS
modifications that use the inputs.
Include the following documentation:
  • 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
    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
MICS
database, the output of the daily update cycle must be documented. The examples noted previous could cause data elements to be added to existing
MICS
files, or could cause entire user components to be added to
MICS
.
Include the following documentation:
  • If the files currently exist, the list of files to be modified.
  • The description of files to be added to the
    MICS
    database, and the structure of the user component to which these files 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
MICS
administrative Information Area.
Include the following documentation:
  • 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
    MICS
    output that contains information from the new source, including report/record content descriptions.

Benefit Analysis

If a modification involves improvement in the performance or application of
MICS
, the benefits of such a modification should be examined. For example, some extension of the normal
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
MICS
input? Or would such communication merely slow down the daily update process with a needless operator message with every update?
Include the following documentation:
  • Identification of the
    MICS
    user or
    MICS
    support person who would benefit.
  • A description of the benefit
  • The list of
    MICS
    operational considerations necessary to use the new procedure.

Impact Analysis

Any modification involves actually changing
MICS
code or adding code to
MICS
. A complete list of
MICS
modules that are affected must be made and evaluated.
Some
MICS
modules lend themselves to modification more readily than others, and some
MICS
modules should not be modified at all. For example, if you are considering modifying the
MICS
JCL Generator, there is generally a way to modify the
MICS
prototype library instead to produce the desired result.
Include the following documentation:
  • The identification of the
    MICS
    module or functional area to be modified.
  • The description of the modification.
  • The list of
    MICS
    operational dependencies that are seen at this stage. That is, if an update was made in module A, then module B must be changed to accommodate the modification.