5. CA MICS/SAS Coding Conventions › 5.1 SAS Coding
5.1 SAS Coding
SAS is a program product of SAS Institute Inc. Almost all of
the logic of CA MICS is programmed in this powerful language.
The SAS language is interpretive; that is, each program is
recompiled each time it is executed using a compiler
technique. The interpretive nature of the language has
several advantages:
- Run-time modifications to CA MICS can be made as a
matter of course, with no special operational
considerations. It is in the nature of CA MICS to
respond to certain execution definitions that may
change from run to run. When such a change happens,
CA MICS can construct new SAS code appropriate to the
situation at hand and execute the new code (in addition
to the preprogrammed code).
- User modifications are incorporated into CA MICS
immediately, with no change to the operational flow.
- There is a single source of compile-time and CA MICS
execution-time diagnostic messages. This is desirable
from the aspect of providing timely product support and
problem diagnosis and correction.
As with any computer language, SAS has some constructions
that are more efficient than others. The information that
follows highlights considerations of SAS language coding that
are in good SAS form and constitute particularly efficient
constructions. Following these SAS programming guidelines
will result in more readable, more efficient SAS code for any
SAS application, including CA MICS.
Macros are used in CA MICS as a way to simplify repetitive
coding. Refer to Section 4.3.1 in this guide for information
about SAS Macro Statements and SAS Macro Language.
Maintainability Standards
COMMENTS:
SAS supports the use of three comment facilities. If a
statement begins with an asterisk (*) and ends with a
semicolon (;), SAS ignores the statement. Such comments must
not be within other statements. For example,
...
X=5;
* THIS IS A COMMENT ; This comment construction
Y=3; is valid.
...
...
X=5 * THIS IS A COMMENT ; This comment construction
Y=3; is invalid.
...
The second form of comment is in the form of comments
originally found in the IBM PL/I language and used in many of
today's programming languages. Any string of characters
enclosed by a slash-asterisk, asterisk-slash is treated as a
comment anywhere it occurs, except inside text quotes.
...
X=5 /* THIS IS A COMMENT */ ; This comment construction
Y=3; is valid.
...
...
A='/* THIS IS A STRING */'; This is invalid.
...
Comments of both types may be found in CA MICS code, but most
comments are of the "/* - */" variety. This form is used
because of the great advantage of being able to put the
comment inside a SAS statement, especially long INPUT
statements.
A third form of comment, which is only available from within
the SAS Macro language, is similar to first comment form. If
the Macro language statement begins with a percent-asterisk
(%*) and ends with a semicolon (;), the SAS Macro language
ignores the statement. Such comments must not be within
other statements. For example,
%MACRO name ;
%* THIS IS A COMMENT ; This comment construction
... is valid.
%MEND name ;
Below are some guidelines that help provide enough comments
without overburdening the reader:
- Use comment blocks for logic descriptions, such as the
following:
/* ************************ */
/* THE FOLLOWING STATEMENTS */
/* APPLY TO TYPE 30 SMF */
/* RECORDS ONLY. */
/* ************************ */
- Include a comment in SAS code that changes, showing
the date of the change, the purpose of the change,
and the person who coded the change.
- Where practical, follow the indentation conventions
when coding comments.
- Have the comment contain more than just a word for word
translation of a logic statement. The comment
X=5; /* SET X TO 5 */
tells the reader nothing.
- Refer to supporting material in comments whenever
possible, such as manual numbers, product release IDs,
or other parts of the program's code.
- If you are not sure that a comment is necessary, insert
the comment. Too many comments may be cumbersome, but
too few can be a greater problem.
INDENTATION:
Good indentation as described below increases the readability
of a program effectively and inexpensively.
- Labels begin in column 1.
- Each level of code is indented 2 columns in from the
previous level.
- ELSE statements align with their IF.
- Continued IF or ELSE statements are indented.
- END statements align with their DO.
- DO statements following an IF or ELSE are on the same
line as the IF or ELSE, and their END aligns with the
IF or ELSE.
The following hypothetical example illustrates each of the
guidelines listed above.
+-------------------------------------------------+
| |
|GENSETRC: |
| |
|INTERVLS=0; |
|SAMPLES=SETSAMPS; |
|TRCNOSET=1; |
|TRCTYPE='S'; |
| /* COMPUTE APPROXIMATE SET DURATION */ |
|IF SETS > 0 THEN DURATION=DURATION/SETS; |
|ELSE DURATION=0; |
| |
| /* CHECK FOR SAMPLE FIELD LENGTH */ |
|IF FLDLENG=4 THEN DO; |
| DO X=1 TO SETS; |
| IF TRCMNFLG THEN INPUT TRCMN PIB4. @; |
| IF TRCSMFLG THEN INPUT TRCSUM PIB8. @; |
| TRCSSQ=TRCSSQ+(SSQ1*16**9); |
| IF TRCEVFLG THEN INPUT TRCENDVA PIB4. @; |
| IF SETS=X THEN SAMPLES=LSTSAMPS; |
| IF TRCSMFLG AND SAMPLES > 0 THEN |
| TRCAV=TRCSUM / SAMPLES; |
| ELSE TRCAV=.; |
| TRCSETNO=X; |
| OUTPUT SCPTRC00 ; |
| END; |
|END; |
|ELSE IF FLDLENG=2 THEN DO; |
| DO X=1 TO SETS; |
| IF TRCMNFLG THEN INPUT TRCMN PIB2. @; |
| IF TRCSMFLG THEN INPUT TRCSUM PIB6. @; |
| IF TRCMXFLG THEN INPUT TRCMX PIB2. @; |
| IF SETS=X THEN SAMPLES=LSTSAMPS; |
| IF TRCSMFLG AND SAMPLES > 0 THEN |
| TRCAV=TRCSUM / SAMPLES; |
| ELSE TRCAV=.; |
| TRCSETNO=X; |
| OUTPUT SCPTRC00 ; |
| END; |
|END; |
|RETURN; |
+-------------------------------------------------+
Performance Guidelines
Refer to the manuals "SAS Programming Tips: A Guide to
Efficient SAS Processing," "Efficiency, Improving the
Performance of your SAS Applications," and "Tuning SAS
Applications in the MVS Environment" from SAS Institute.
