Hi Community,
I have a customer that wants to setup a Sandbox in their development environment (In a GRID on Linux (SAS 9.4M6)). This means that each user have their own autoexec and their own sasenv.sh file where they can set their own environment variables. If the user does not have a personal user folder then a common autoexec and sasenv.sh file should be read.
For the autoexec, I usually use %sysget('METAUSER') to find the user logged in and this works for other machines in the environment with a Workspace Server, but it seems that there is no METAUSER environment variable set on the machines in the GRID. I have checked the production environment and it seems to be the same case here. You can see how I have verified this if you go to the appendix in the bottom.
So my workaround for the autoexec is to use the %mduextr macro instead. From here I can find the user logged in as well and then I can %include the correct autoexec for the user. It takes a little bit longer time start up, but I can live with that. However, it would be nice, if there is a way to add the METAUSER environment variable to the GRID machines also. Is it possible?
For the environment variables I am running a custom .sh file that needs to set the correct environment variables and the code looks like this:
if [[ -f "$SANDBOX/$USER/sasenv.sh" ]] ; then . $SANDBOX/$USER/sasenv.sh else . $CURRENT_LEVEL_ROOT/SASApp/sasenv.sh fi
The problem with this code is that $USER resolves to the service account that runs the Workspace Server. It works fine if I create a folder for the service account, but I need to look for the user logged in to metadata. Is there a way to do this?
I have played around with X commands, %SYSEXEC and the data step statement call system. Because once we get to the SAS Session I can use %mduextr to figure the metadata user out. But it seems that I can not affect the parent process with the new environment variable. Only child processes. So I need to set the variables earlier.
I hope you can help.
Appendix:
When I start a Workspace session on a machine that is not part of the GRID. I can see that an environment variable called METAUSER is set. I find my session ID in Management Console (it could be 32071) and then I run the following code as root:
strings /proc/32071/environ | grep METAUSER
I get the following:
If I do the same on one of the GRID machines, I don't get the METAUSER environment variables:
And from SAS I also get an note that suggests that the variable is missing:
This code would do it.
proc optsave out=work.options; run;
proc sql;
select OPTVALUE into:metauser from work.options where OPTNAME="METAUSER";
quit;
options set=metauser='&metauser';
Hi,
I agree. But I haven't been able to find these scripts. Shouldn't be inside the SAS installation or configuration somewhere? I guess that is the only thing that makes sense since METAUSER is coming from SAS Metadata.
If someone can point me to a script that sets the METAUSER environment variable, I will be very grateful
This code would do it.
proc optsave out=work.options; run;
proc sql;
select OPTVALUE into:metauser from work.options where OPTNAME="METAUSER";
quit;
options set=metauser='&metauser';
Hi Greg,
Thank you for this piece of code. Now I can remove the part with %mduetr, so this part will run faster.
Do you have any idea of how I can set the environment variable to be used in my .sh setup file as well? I assume that this code will only create a macro variable that exists within my sas session.
A quick update here.
Thank you for the solution, Greg. I did not see
options set=METAUSER='&metauser';
Which set an environment variable on Linux. And the customer has x command enabled, so I can call the sh script from the autoexec after setting the METAUSER variable.
Just one correction. In the options statement the &metauser needs to be enclosed with " " instead of ' ' in order for the value to translate correctly. And then I remove everything else than the username from the OPTVALUE that came from the proc optsave that you showed me.
options set=METAUSER="&metauser";
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.