Stored Workflow Documentation (from Fraktal SAS Programming)

Scenario

There's many occasions where direct output to the LOG window is convenient and a matter of time-saving. In a validated and highly automated environment, this advantage does not count, since every un-controlled performed user action immediately harms validation and leaves behind un-documented, hence, un-trackable results.

With respect to this the professional SAS user is offered means to store LOG information in general as well as Generated Code as intermediate results in cases when macro programming is applied. As already seen from other examples, SAS provides a wide variety of options to write any type of results to an external location.

At this point we will examine two of them.

LOG information

Since program flow is documented in the LOG window of an interactive SAS session, it should be as simple as redirecting this data stream to a text file. And indeed, PROC PRINTTO does exactly this:

/*
Switch on
*/
proc printto LOG = "C:\TEMP\MyLOG.txt"; 
run;

/*
Switch off
*/
proc printto LOG = LOG; 
run;

Pretty easy, isn't it?

Of course, any OS path is valid here, moreover, if a structured repository is intended for documentation, automatic variables like &SYSTIME., &SYSDATE., &SYSUID. or others might occur in the filename(s) used.

Generated Code

For various reasons some individuals do not like macro code, and hence, do not even feel comfortable, when reviewing or validating code written by others that contains macro [[1]]. This notion is quite justified for those, not being trained and experienced in macro prgramming, since use of the SAS macro facility breaks the sequential and linear processing of "multi-syntax SAS code", which is what SAS macros really are.

Life would become very easy for such individuals, if SAS macros kept the code given to the SAS compiler and stored it to a *.sas text file that does not contain TRIGGERS and, moreover, might even run cleanly when loaded to the program editor and submitted.

So, let's try this:

/*
Switch on
*/
options mprint mfile;
filename mprint "C:\TEMP\MyCODE.sas";

/*
Switch off
*/
options mprint nomfile;
filename mprint clear;

Details

• The FILENAME statement constitutes a file reference ("FILEREF") MPRINT for a physical location on the OS file system.
• The MPRINT option triggers SAS to write generated code at all.
• The MFILE option triggers SAS to use the fileref MPRINT to copy the code, that was given to the SAS compiler.

This looks somewhat different from the method just used for the LOG information, but that is what makes SAS such a colorful adventure.

When writing to the same fileref target again and again, the user will get the whole history of SAS programming, including repeats, errors and variations. Under the assumption, that this very rarely intended to happen, it appears useful to issue a command to the OS that deletes the fileref target before running the macro:

systask command "del C:\TEMP\MyCODE.sas" wait;

Details

• SYSTASK statements offer a means to establish a controlled workflow integrating OS based processes.
• Inside quotes ("") native OS commands may be issued.
• The WAIT option stops processing consecutive code before the OS command is executed (this prevents the file from being deleted immediately after creation).