I need to make aware a group of interactive users (SAS Enterprise Guide / SAS Studio running workspace sessions) of the number
of ongoing (active) SAS sessions launched by their workspace server.Technically, the number of child processes "spawned" as distinct workspace sessions
by the assigned Object Spawner.
The number should be calculated at each distinct workspace level, not at hostname level (this might be too broad, I think).
The option might be selected through :
This kind of feature would be useful when too many sessions are launched in order to give some feedback thus some control back
to the end users, sometimes unaware of the overall server workload. Then they could better anticipate the server response time,
being able to know how many sessions are currently ongoing.
I have tried a workaround using a shell script which creates a flag file at the bottom of the folder path displayed by SAS EG file explorer (see below)
The script is replayed based on two events :
1. each time a new workspace session is launched (called by the WorkspaceServer_usermods.sh script)
2. by the server scheduler every minute
I would have preferred for the 2nd event to be able to run the script each time a workspace session is closed by the user (TERMSTMT) but in 9.2,
this feature is not allowed (or, is it ?).
Of course, the process owner of the workspace session on the server cannot modify the flag file, preventing any erase by mistake.
I have done something similar with perl scripts to display via the webserver's cgi-bin interface. Can provide examples.
I have also implemented a "maximum allowed sessions" device in the workspace server startup scripts that keeps users from using more than 3 workspace server sessions concurrently.
This is definitely useful. My need is slightly different : when a pooling limit cannot/might not be set to allow a maximum number of sessions, which means when we use a standard workspace server (unlimited number of sessions/resources ) then I suggest to responsibilize the user themselves (instead of the IT ... or the Admin ! ). With great power comes great responsibility as they say on Linux when it comes to impersonate root privileges. The underlying assumption is that, with this extra awareness, the users can knowinglinly re-distribute their work load by setting up their priorities in a cooperative mindset, instead of using unrestricted resources blindly (and suboptimally, perhaps).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.