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 aMICSupdate 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 theMICSdatabase, 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 otherMICSoutput 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 theMICSuser orMICSsupport person who would benefit.
- A description of the benefit
- The list ofMICSoperational 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 theMICSmodule or functional area to be modified.
- The description of the modification.
- The list ofMICSoperational 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.