There are different methods to config SAS in unix environment. First of all, for every installatoin, there is a config file stored in the installation directory alongside with the SAS executable file (i.e. the sasroot directory). This file is named config.sas in version-6, sasv8.cfg in version-8 and sasv9.cfg in version-9. This config file is effective for all users in this machine using this SAS. For example, this line in the config file can let all users to share the SAS working directory:
-work '/production/global/sas_working_directory' ;
|
However, if there is a config file in the $HOME directory e.g.
, SAS will use this $HOME config file instead.
Using this method, each programmer can has his/her own SAS configuration setting, e.g. using his own very large working directory instead of the global one :
-work '/my_large_filesystem/sas_working_directory' ; |
But, when there are some other parameters changes e.g.
and the program is rolled out to production, how can you ensure that the config file is also adjusted to be similar to the programmer's own config file (i.e. to -sortsize 32M) ? The change is ONLY in the programmer's config file in the programmer's $HOME directory. This is a serious drawback. (Actually, the change is not reflected in system test and user acceptance test either.)
Also, when upgrading from SAS version-6 to version-8, the name of the config file is changed from config.sas to sasv8.cfg. All user's config file under $HOME directory will be affected. Similarly when upgrading from version-8 to version-9.
Starting from version-8, we can also use environment variables SASV8_OPTIONS and SASV8_CONFIG to specify the config files. Using this method, it is more easy for all team members of a department to SHARE a common config file. For example:
export SASV8_OPTIONS='-config /company/department/common/sasv8.cfg'
sas my_program.sas |
or
export SASV8_CONFIG=/company/department/common/sasv8.cfg
sas my_program.sas |
These environmental variables can be specified in a common profile file. All team members has to call this departmental common profile file to make it effective for the login sessoin.
Another method is to specify the config file as command line option when calling the SAS executable. The advantage of using this method is the capability of specifing different configuration under different development phases. For example, in development phase, we can use a development configuration file like this :
export MYSASCONFIGFILE=/project/dvt/sasv8.cfg
sas -config $MYSASCONFIGFILE my_program.sas |
Then, during system test, we can do this :
export MYSASCONFIGFILE=/project/syt/sasv8.cfg
sas -config $MYSASCONFIGFILE my_program.sas |
During user acceptance test, we can do this :
export MYSASCONFIGFILE=/project/uat/sasv8.cfg
sas -config $MYSASCONFIGFILE my_program.sas |
Using this method, we can adjust the parameters (e.g. the working directory) in different development phases. In case some parameters needed to be adjusted, the UAT version of sasv8.cfg file can also be check-in / check-out to rollout to production.
By the way, since SAS version-8 and versoin-9 has some more complicated ways to specify the config file please refer here for the details for version-8 and this for version-9.
In short, before using SAS for any project, the first thing is to define the way of using the config file. It is better to use a systematic approach, rather than an ad-hoc way (e.g. the $HOME config file method).
