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.5 Notes on Coding CA MICS Parameters

2.3.1.5 Notes on Coding CA MICS Parameters

The prefix.MICS.PARMS library contains a number of members
which specify the options to control various parts of the
total CA MICS system.  Members either contain control
statements or are exit routines coded in SAS.

The format of control statements is free form, but
positional, meaning that any number of blanks may come before
and after any parameter, but all parameters must be
specified, and specified in the order shown.  There is no
explicit provision for the continuation of control
statements.  Our approach has been to allow the repetition of
control statements when more parameters must be specified
than can fit on a single line.  Comments are supported in all
of the PARMS members.  If the first parameter is '*', the
parameter line is ignored.  For those parameter statements
which begin with a keyword, the keyword MAY NOT BE
ABBREVIATED--it must be coded exactly as shown in the
documentation.

Some PARMS members require you to specify your
installation-specific requirements by coding an exit in SAS.
This method of tailoring affords you great flexibility
because the SAS language is powerful.  You should, however,
always follow these guidelines:

    Validate the fields your exits use to make their
    processing decisions.  While CA MICS does some basic
    validation, it cannot catch the kinds of installation-
    specific errors you can (e.g., an invalid account number
    on a JOB statement). When one of your exits detects
    invalid input data, it should never pass it on into the
    database (e.g., pass through an invalid account number so
    it becomes part of the key of a record).  Doing so
    increases the size of the database and decreases its
    usefulness for analysis and reporting.  Rather, your
    exits should take some sort of standard default action
    when they detect invalid input data (e.g., assign a job
    with an invalid account code to an overhead category).

    Exit code is inserted directly into CA MICS processing
    logic, so you should ensure the code inserted will not
    do anything to cause subsequent CA MICS logic to operate
    abnormally.  To help you ensure the validity of your exit
    code, the following guidelines are presented:
              ****  D O  the following:   ****


     DO:  Use the member supplied in the distributed version
          of the MICS.PARMS library as the starting point for
          your exit.

     DO:  Liberally comment all code.

     DO:  Examine input record length to be sure INPUT
          requests can be satisfied from the current record.

     DO:  Reference input field locations with pointer logic
          where possible.

     DO:  Preserve data element integrity by type (numeric,
          time stamp, character variable) and range (having
          the value agree with the FORMAT and LENGTH
          specifications).

     DO:  Define new retained data elements by specifying
          the RETAIN statement after LENGTH and FORMAT
          statements.

     DO:  Test all exit logic under the CA MICS-required SAS
          release.

     DO:  Contact CA Technical Support if you have
          ANY questions.
             ****  D O N ' T  do the following:    ****


     DON'T:  Use columns 73-80 for SAS statements. CA MICS
             only uses 1-72.

     DON'T:  Code these SAS statements in your exit:  RETURN,
             DELETE, or INPUT without a trailing '@'.

     DON'T:  Code INPUT statements that could cause SAS
             to perform an automatic input statement skip.
             Use the RECLEN variable to be sure the record is
             big enough to contain data at any intended input
             offset.

     DON'T:  Forget the CA MICS naming standards, especially
             for DDnames, file names, and data element file
             prefixes.

     DON'T:  Assume that any data element is RETAINed or
             not RETAINed.

     DON'T:  Redefine any currently-existing CA MICS data
             element unless the documentation of the specific
             exit in question says it is allowed.

     DON'T:  Assume that the SAS automatic variable _N_
             contains the actual input observation number.

     DON'T:  Assume that setting the SAS automatic variable
             _ERROR_ will cause an input observation to be
             ignored or CA MICS processing to terminate.

     DON'T:  Use SAS language features not supported by the
             SAS release specified for use by the CA MICS
             update process.

When specifying a PARMS member, you should always do so by
modifying the example member from the MICS.PARMS shipped with
the system rather than coding one from scratch.  Doing this
will spare you annoying syntax errors.