Hi,
My out-of-the-box WorkspaceServer.sh script has this line for the SASCFGPATH:
SASCFGPATH="$APPSERVER_ROOT/sasv9.cfg, $APPSERVER_ROOT/sasv9_usermods.cfg, $CONFIGDIR/sasv9.cfg, $CONFIGDIR/sasv9_usermods.cfg"
To determine the order of execution of these config files, I added different settings to each of them and found out that this is the actual order of execution, where the last one wins:
1. $CONFIGDIR/sasv9.cfg 2. $CONFIGDIR/sasv9_usermods.cfg 3. $APPSERVER_ROOT/sasv9.cfg 4. $APPSERVER_ROOT/sasv9_usermods.cfg
I cannot relate that to the order in the SASCFGPATH string:
SASCFGPATH="$APPSERVER_ROOT/sasv9.cfg, $APPSERVER_ROOT/sasv9_usermods.cfg, $CONFIGDIR/sasv9.cfg, $CONFIGDIR/sasv9_usermods.cfg"
I can't find official documentation on this setting, does anyone understand how this works?
The reason for asking is that my customer wants to add a custom sasv9.cfg file to his configuration and the question is where it should go.
-Bart
The order of operations for config files goes from most to least specific. That is:
1. An option given when executing the command (i.e. WorkspaceServer.sh -option)
2. The sasv9_usermods.cfg in WorkspaceServer directory ($CONFDIR/sasv9_usermods.cfg)
3. The sasv9.cfg file in the WorkspaceServer directory ($CONFDIR/sasv9.cfg)
4. The sasv9_usermods.cfg file in the application server context directory ($APPSERVER_ROOT/sasv9_usermods.cfg)
5. The sasv9.cfg file in the application server context directory ($APPSERVER_ROOT/sasv9.cfg)
6. The sasv9_local.cfg file in the SASHome/SASFoundation/9.4 directory
7. The sasv9.cfg file in the SASHome/SASFoundation/9.4 directory
The _usermods and _local files are preserved through updates, so this is where any customizations would go. If you want to apply one to all SAS sessions it would be sasv9_local.cfg, if for all within a context (i.e. SASApp) it would be in SASApp/sasv9_usermods.cfg, and for just the Workspace Server it would be WorkspaceServer/sasv9_usermods.cfg.
Configuration Files for Components of SAS Application Servers
https://go.documentation.sas.com/?cdcId=bicdc&cdcVersion=9.4&docsetId=bisag&docsetTarget=p1n3ivrea2b...
This order matches the order of SASCFGPATH, with the last one being the last one applied. The sas executable in SASFoundation/9.4/ adds to the path values defined in WorkspaceServer.sh the sasv9 and sasv9_local files I mentioned in SASHome:
[sas@sgmmstr 9.4]$ pwd /sas94/SASHome/SASFoundation/9.4 [sas@sgmmstr 9.4]$ grep sasv9 sas -C1 if [ "$SASCFGPATH" ] ; then SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/en/sasv9.cfg, !SASROOT/sasv9_local.cfg, $SASCFGPATH" else SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/en/sasv9.cfg, !SASROOT/sasv9_local.cfg" fi [sas@sgmmstr 9.4]$
Hi @gwootton
Thanks for you explanation.
You write:
This order matches the order of SASCFGPATH, with the last one being the last one applied.
That does not appear to be the case, as:
SASCFGPATH="$APPSERVER_ROOT/sasv9.cfg, $APPSERVER_ROOT/sasv9_usermods.cfg, $CONFIGDIR/sasv9.cfg, $CONFIGDIR/sasv9_usermods.cfg"
implies the order of execution would be:
where the last one wins, where the order that I find - and would expect and that is documented - is this:
What I miss and have missed over time - and what the actual background of my question is - is a sasv9.cfg for the Lev, so $LEVEL_ROOT/sasv9.cfg and $LEVEL_ROOT/sasv9.cfg. The customer has now built that into every (Workspace|StoredProcess|PooledWorkspace)server.sh as:
SASCFGPATH="$LEVEL_ROOT/sasv9.cfg, $APPSERVER_ROOT/sasv9.cfg, $APPSERVER_ROOT/sasv9_usermods.cfg, $CONFIGDIR/sasv9.cfg, $CONFIGDIR/sasv9_usermods.cfg"
How would you implement this using usermods files only?
Sorry for now mixing up 2 questions in 1 post.
Would adding the options in Lev1/sasv9.cfg instead to <SASHome>/SASFoundation/9.4/sasv9_local.cfg work for your purposes?
I tried it out and it works. As it is unclear what the order or execution - and thus the order of precedence - of the files is, I cannot be sure this will always work but for now there are no options in <SASHome>/SASFoundation/9.4/sasv9_local.cfg that also exist in other configuration files so it works.
Thanks.
For the configuration files I have any control over - which is only the usable-writable ones - I have taken the approach of adding a -NOTE option showing the location, so I can just look at the log and see which configs were used and in what order. I might try to get the SAS administrator to do the same thing in the system config files, as "where did that setting some from" questions come up fairly often.
That is a good idea except that a -NOTE in my sasv9_usermods.cfg gives me errors when starting SAS.
Can you show me an example?
Sorry, I shouldn't work from memory, I meant -ECHO
-echo "NOTE: Reading configuration options from ~/sasv9.cfg"
A problem is that this is unreliable. Sometimes I see it, and sometimes I don't. It must depend on something else in the environment.
It appears that the notes from -ECHO appear in the log in SAS for Windows, and in "traditional" sashome/.../bin/sas_en on Unix, but they do not show up when SAS is started through the load manager, e.g. sasgsub , even though the options are set.
Another option, not very clean, is to set SET options in your config files.
in ~/.sasv9.sas
-set MY_DOT_SASV9_CFG_USED_1 1
-set MY_DOT_SASV9_CFG_USED_3 1
in ~/sasv9.cfg
-set MY_SASV9_CFG_USED_2 1
-set MY_SASV9_CFG_USED_4 1
In my SAS program:
proc options option=(set); run;
The log shows
69 proc options option=(set); run;
SAS (r) Proprietary Software Release 9.4 TS1M5
SET=[SASROOT = /opt/sas94_install/sashome/compute/SASFoundation/9.4] [SASAUTOS = ( '!SASROOT/sasautos' )]
[SAMPsrc=( '!SASROOT/samples/accesssample' '!SASROOT/samples/base' '!SASROOT/samples/connect'
'!SASROOT/samples/dbi' '!SASROOT/samples/dmine' '!SASROOT/samples/dquality' '!SASROOT/samples/ets'
'!SASROOT/samples/graph' '!SASROOT/samples/hadoop' '!SASROOT/samples/hpf' '!SASROOT/samples/hps'
'!SASROOT/samples/hpstat' '!SASROOT/samples/iml' '!SASROOT/samples/intrnet' '!SASROOT/samples/inttech'
'!SASROOT/samples/or' '!SASROOT/samples/qc' '!SASROOT/samples/share' '!SASROOT/samples/stat'
'!SASROOT/samples/tmine' )] [SAMPSIO = ( '!SASROOT/samples/accesssample' '!SASROOT/samples/base'
'!SASROOT/samples/connect' '!SASROOT/samples/dbi' '!SASROOT/samples/dmine'
'!SASROOT/samples/dquality' '!SASROOT/samples/ets' '!SASROOT/samples/graph' '!SASROOT/samples/hadoop'
'!SASROOT/samples/hpf' '!SASROOT/samples/hps' '!SASROOT/samples/hpstat' '!SASROOT/samples/iml'
'!SASROOT/samples/intrnet' '!SASROOT/samples/inttech' '!SASROOT/samples/or' '!SASROOT/samples/qc'
'!SASROOT/samples/share' '!SASROOT/samples/stat' '!SASROOT/samples/tmine' )] [SASHOME =
/opt/sas94_install/sashome/compute] [DTJ_CLASSPATH =
/opt/sas94_install/sashome/compute/SASFoundation/9.4/misc/dmine/dtj.jar:/opt/sas94_install/sashome/compute/SASPrivateJavaRuntimeEnvi
ronment/9.4/jre/lib/rt.jar] [APFMTLIB = SASEnvironment/SASFormats] [MY_DOT_SASV9_CFG_USED_1 = 1] [MY_DOT_SASV9_CFG_USED_3 = 1]
[MY_SASV9_CFG_USED_2 = 1] [MY_SASV9_CFG_USED_4 = 1]
Defines an environment variable.
In this case, the values show up in the output in the order in which they were executed, not in alphabetical order.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.