I have seen cases where somebody has to run a number of sas programs but
they opt to run all the programs in one sas call. This is a bad idea as
there is the possibility that what is left over in one program can affect
a following program. When they realize this then you might see some code
added at the end of every program to clear out the work libraries and formats
and reset the options to an agreed standard. It starts getting messy. If
each program ran in a separate sas session then there would not be this
problem but what sas programmers sometimes need to do is to communicate
some piece of information to all the sas programs and that this information
is different for a full run of all programs rather than runs of individual
programs as is typical during development. So they think that there is
no alternative but to run all the programs in one sas session and set up
these values at the start before the first program runs in macro variables.
There will be a block of code at the top of each program that is active
for individual runs when the program is being developed but must be commented
out for the collective run. Again, this is a bad idea, as there is no guarantee
that the programmer will remember to do this. It is also very messy and
to make it worse, after a program has been "validated", then the code must
be changed slightly by commenting out this block before it can be run in
"production". This introduces the chance of an error so by making this
sort of edit you might have "invalidated" a "validated" program. This less
than optimum situation all comes from the mistaken belief that you can
not "communicate" with sas programs independently of changing sas code
or setting parameters. You can.
System environment variables
One way to do this is to change sas code in the autoexec.sas member so
that each program can pick it up and so each program can run independently
in its own sas session. Although this is a much better way and avoids sas
programs all running together, it is still changing sas code, if only in
autoexec.sas. Sometimes this would be inconvenient due to the system setup.
Luckily there is another and much better way to do this and this is by
using "system environment variables". Most sas programmers have
never heard of "system environment variables" because they have limited
knowledge of the platform they are working on, such as Windows and Unix,
and what it can do. It is not the programmer's fault as SAS software claims
to be platform independent and so programmers never think they need to
bother to learn much about the platform it runs on. If you have a script
or a batch (.bat) file to run your sas programs then you can set up an
environment variable, give it a value and "export" it. This makes it available
to all the sas programs run by the script if they know to look for it.
In your sas code you can check to see what this environment variable is
set to using sysget() in a data step or %sysget() as a sas
macro function. You might want to look at the SAS documentation for these.
But there is a small problem. Using %sysget() will cause a warning message
to be written to your log if the environment variable does not exist, which
will most likely be the case when you are developing your program and trying
to read a system environment variable that will only be there for the final
production run. It is best to avoid this warning message. To get round
this I use a macro I wrote called %readpipe() which reads the results
of system commands, so that you can issue an "echo" command for the system
environment variable. Doing it this way avoids the warning message. You
can link to the %readpipe() macro here.
The clinical reporting system I wrote has an example of using this technique.
It has a macro named %closerep() that closes a report. It looks
at the system environment variable OUTDIR to determine which directory
it should put the final output files in and one called DONELIST so it knows
which "donelist" file to write an entry to (if OUTDIR is set) to say what
output has been created. Take a look at the code and see how it is done.
Note that for Windows (&sysscp EQ WIN) it is done differently than
for Unix. Note the %readpipe() call. You can link to the %closerep macro
here.