I need to manage the SAS Enterprise Guide users, each user can open only 2 sessions, but I do not know how it could be administered.
I have SAS 9.4 on the Windows 2012 server Company Guide 7.1
I presume (wrongly, perhaps ?) that you want to enable a quota of number of sessions per user : 2 ongoing sessions maximum per each user. Presently you have no quota and each user can launch as many sessions as he likes, which is the defaut behaviour of as SAS 9 platform with SAS Enterprise Guide (or Add-In, or SAS Studio).
A former colleague once tipped me about how to implement such a rule, it involves a modification of the kind of Metadata server object you have. I cannot remember if I have ever tested this trick so this remains to be thoroughly tested. It might not work at all.
If you don't have a strong knowledge (or the impulse to aquire one) of SAS Metadata then it's going to be difficult somehow.
Here are the main ingredients to make the cake, this list is not comprehensive :
1. Convert your standard Logical Workspace Server to a Load Balancing one
2. Change the Cost parameters of the Logical LB Workspace Server and the underlying Workspace Server (Options > Advanced > Performance) in order to have quota restricted to 2 sessions maximum per user
3. [ You might have to create in Metadata a duplicate Server object (the last level under 'Workspace Server') ]
4. Enable a higher level of Object Spawner log verbosity , change your parameters set (2.) iteratively and check if this works.
In theory, a pooled workspace would be simpler but Clients like SAS EG as far as I know cannot use these kind of multi-sessions pooled servers to tun a SAS session (?).
On a UNIX system, I have this in Lev1/SASApp/WorkspaceServer/WorkspaceServer_usermods.sh:
LIMIT=4 COUNT=`ps -ef|grep bridge|grep spawned|grep $USER|wc -l` if [[ $COUNT -gt $LIMIT ]] then exit 1 fi
Since the ps line in itself will appear in the result of the grep's, the COUNT value has to be incremented by 1, so this script code tests for a maximum of three workspace server sessions.
I have no idea if you can find similar useful tools on a toybox (Windows).
@Kurt_Bremser's suggestion is a very good one. I've had to implement something like this before and his script will do the trick. Although not for Windows, the concept is identical.
Maybe just two additional points to note.....
1.) Ensure that proper housekeeping is maintained to ensure that no orphan processes are counted towards a user's quota
2.) There are usually underlying reasons why this get implemented. I would suggest you closely look at these and determine if this solution is the best. This method can be fairly disruptive to the users, so use with caution. A very common disagreement is a user saying he/she has x sessions and the script is counting y
In my case, it was the result of a user who used to open a separate EG instances for every program that he ran. His Windows task bar was so incredibly cluttered that you could see no more than the left half of each icon. And when one day I found 32(!) concurrent workspace server sessions for that particular user, I pulled the emergency brake and implemented the above logic.
Needless to say, next day I had a phone call from him, complaining about it. Told him that I worked under the same restrictions, and that he could open lots of code windows in one EG without problem. Never heard about it again.
Aside from the overhead caused by multiple processes, also consider to implement a user-based quota system for your shared resources (WORK!). With that, no single user can wreck the day for everybody else by consuming all the work space.
this is great one ....
is there a way in unix to limit batch jobs ? I mean user who kicks off jobs just with nohup sas ?
see red highlighted below - users write ksh script and schedule them in scheduler - and the script have "nohup sas sascode.sas" statements..!
/local/home/sasadm>ps -ef | grep marprod
marprod 7799002 22611710 0 11:01:10 - 0:00 sasels 7 4 8 2 f7346
marprod 28508336 2950762 0 09:00:00 - 0:00 ksh /local/home/marprod/scripts/ref_id_perm_data.ksh
marprod 35651712 4915948 0 09:00:46 - 0:00 sasels 7 4 8 2 649ec
marprod 23069066 33358530 0 10:00:05 - 0:00 sasels 7 4 8 2 11799c
sasadm 35783084 7603956 0 15:02:50 pts/1 0:00 grep marprod
marprod 4915948 28508336 1 09:00:19 - 20:46 /sasgrid/SASBASEP/SAS_94/SASFoundation/9.4/sasexe/sas -batch -noterminal -nogwindow /local/home/marprod/code/Ref_id_perm_data.sas
marprod 28181236 2950762 0 08:30:00 - 0:00 ksh /local/home/marprod/scripts/DlyNewAcct_frcst.ksh
marprod 33358530 2950762 0 10:00:01 - 13:18 /sasgrid/SASBASEP/SAS_94/SASFoundation/9.4/sasexe/sas -batch -noterminal -nogwindow /local/home/marprod/code/MARK/Retention_Call_Trck_Daily.sas -log /local/home/marprod/code/MARK/Retention_Call_Trck_Daily.log
marprod 33358992 28181236 19 08:30:57 - 27:25 /sasgrid/SASBASEP/SAS_94/SASFoundation/9.4/sasexe/sas -batch -noterminal -nogwindow /local/home/marprod/code/DlyNewAcct_new_dailymm.sas
marprod 13108924 13895246 0 15:02:27 - 0:00 ksh /local/home/marprod/scripts/jetblue_daily.ksh
marprod 13174480 13108924 0 15:02:27 - 0:00 /usr/bin/ksh /local/home/marprod/scripts/at_submit.ksh /local/home/marprod/scripts/jetblue_daily.ksh 10
marprod 13895246 2950762 0 15:02:26 - 0:00 ksh
marprod 22611710 2950762 18 11:00:00 - 12:44 /sasgrid/SASBASEP/SAS_94/SASFoundation/9.4/sasexe/sas -batch -noterminal -nogwindow /local/home/marprod/code/MARK/elite_calls.sas -log /local/home/marprod/code/MARK/elite_calls.log
marprod 22742762 33358992 0 08:31:03 - 0:00 sasels 7 4 8 2 fc00a
marprod 24512238 13174480 0 15:02:27 - 0:00 sleep 28
marprod 34146016 2950762 0 13:01:00 - 12:40 /sasgrid/SASBASEP/SAS_94/SASFoundation/9.4/sasexe/sas -batch -noterminal -nogwindow /local/home/marprod/code/MARK/intercept_seed.sas -log /local/home/marprod/code/MARK/intercept_seed.log
marprod 37488276 34146016 0 13:01:00 - 0:00 sasels 7 4 8 2 fe076
You can only implement that in the shell scripts SAS has in the configuration tree, but you can't guard against direct calls of the SAS executable.
So you need to do that from the operating system, by using a workload manager or simply by limiting the number of concurrent processes for a single user.
Some batch schedulers have settings to be able to limit the number of batch jobs that can run simultaneously. I know LSF has this. The nice thing is if you reach the limit, then the remaining batch jobs are just queued until active jobs finish, then the queued jobs will start automatically.
In many SAS Grid installations LSF is the underlying scheduler. You don't have to run this from GSUB. It is available via Schedule Manager in SAS Management Console. Personally I don't get it why so many SAS users resort to command line stuff when there is a perfectly good point and click interface available.
Also there is no reason why your batch and online SAS environments should be different. Ours aren't and that means absolutely no code changes are required whatever environment we run our SAS code in.
I don't understand why you don't want to use your metadata server in Production. The whole point of leveraging metadata use is to keep your SAS environments consistent, and minimizing the use of coded LIBNAMES - it is much more productive and less prone to error this way.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.