Hi,
I have made a small changes in the environment variable defined in sasenv_local file. After saving the file, in order to check whether the changes has made reflected in our SAS session , I have ran the below query in a new SAS EG session
X ' env > /home/test/test.txt';
But the output ofthat variable is not the latest and its still pointing to old value. ( May be the output from cache)?? Do i need to restart the object spawner to make that effect???
Please let me know. Thanks in advance.
The environment of your workspace server is inherited from the objectspawner. Have you restarted the spawner after making the change?
Hope this helps,
- Jan.
If you have spawned a new SAS session and changes were saved successfully, it should work without restarting object spawner. I tested this and it works without any issue on SAS 9.4 LAX platform.
Thanks both.
Yes, I have made a mistake initially that below that environment variable I had another entry that is pointing to old value and that overwrite the new value.
So , After I have removed the old value from sasenv_local I can able to get my desired results.
But there is another problem related to same environmental variable. Initially I had a environmental variable in sasenv_local and that is common across two levels. But I don't want to share that across 2 level, so I have removed from the sasenv_local and in other level (level_env_usermods.sh ) I have added those env variable.
Then I started my new SAS EG session and check whether the variable is removed in one level. But still its referring the same value.
Even I restarted my object spawner to check again. But no luck.
Is there any way to find where the environment variable has been defined??? Thanks in advance.
Maybe it can help if you test your environment scripting by running them outside of SAS. You can source (execute in the current shell, not in a spawned one) and theen check the result. If you use the -x optionn you can follow what's happening.
[sas@centos-sas94 Lev1]$ set -x [sas@centos-sas94 Lev1]$ source /usr/local/SASConfig/Lev1/level_env.sh + source /usr/local/SASConfig/Lev1/level_env.sh ++ LEVEL_ROOT=/usr/local/SASConfig/Lev1 ++ UTILITIES=/usr/local/SASHome/SASDeploymentManager/9.4/products/cfgwizard__94520__prt__xx__sp0__1/Utilities ++ DEPLOYWIZ=/usr/local/SASHome/SASDeploymentManager/9.4/products/deploywiz__94520__prt__xx__sp0__1/deploywiz ++ SAS_HOME=/usr/local/SASHome ++ JAVA_JRE_COMMAND=/usr/local/SASHome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/java ++ SASVJR_HOME=/usr/local/SASHome/SASVersionedJarRepository ++ SASVJR_REPOSITORYPATH=/usr/local/SASHome/SASVersionedJarRepository/eclipse ++ SASWebInfrastructurePlatform_HOME=/usr/local/SASHome/SASWebInfrastructurePlatform/9.4 ++ SASROOT=/usr/local/SASHome/SASFoundation/9.4 ++ SAS_COMMAND=/usr/local/SASHome/SASFoundation/9.4/sas ++ . /usr/local/SASConfig/Lev1/level_env_usermods.sh +++ CONTEXT_USERMODS_OPTIONS= ++ '[' -f /usr/local/SASConfig/Lev1/hadoop_env.sh ']' +++ hostname +++ awk -F. '{ printf $1 }' ++ SHOSTNAME=centos-sas94 ++ SERVER_PID_FILE_NAME=server.centos-sas94.pid ++ export SERVER_PID_FILE_NAME
This is an example from my own test and experimentation machine.
By running the script with "source" you can then test the variables with echo. Thsi approach has helped me many times resolving persky little mistakes in the past. I hope it willl help you as well.
- Jan.
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
SAS' Charu Shankar shares her PROC SQL expertise by showing you how to master the WHERE clause using real winter weather data.
Find more tutorials on the SAS Users YouTube channel.