BookmarkSubscribeRSS Feed

Question: how to tell if particular SAS components (e.g, SAS/ETS, SAS/Access to ODBC, etc) are being used, and by who?


Reason: We have a challenge in how to split out our current SAS 9.4 M4 platform - we're aiming to de-centralise away from shared "on-premise" infrastructure to segregated "cloud" platforms.


So we'd like to know which users/groups (if any) have been using certain SAS modules - various SAS/Access engines in particular, to know which ones to split to which cloud platform.


But a broader question applies which I thought worth asking: there are utilities to check (a) what is installed, and (b) what is licensed, but what about (c) is it being used? Is there a way beyond trawling through logs (which may not even have the right logging level set)?




Ammonite | Level 13 VDD
Ammonite | Level 13

try this

proc product_status;



Thanks - I wasn't aware of PROC PRODUCT_STATUS, but already have this information from the ViewRegistry utility.


I know what's installed & when the license expires.


What I'm trying to ascertain is if a module has been used/required, and by who?


For example, does someone use:

  • SAS/Access to ODBC
  • etc.


Meteorite | Level 14

Hi Andrew,


If you’re using SAS Environment Manager the Report Centre May have what you need - there is a Proc Usage report, or perhaps use the stored process code to create a custom report.


Kind Regards,


//Contact me to learn how Metacoda software can help keep your SAS platform secure -
Super User

We get asked each year when we renew by our IT area and that's how they handle it. 

I think some area's just click everything because they're afraid of losing tools and others actually pay attention. 


SAS Employee
Good question. If this was my system and it was using Linux I'd probably use a BCC tools based eBPF program to instrument what shared object files are loaded from the $SASROOT/sasexe directory by what users.

Most procedures, access engines etc. have their functionality loaded into the SAS session by loading up a library. e.g sasora is the shared object associated with SAS/ACCESS Interface to Oracle.

Leave the trace running a few days and you'll have a pretty complete list of what features of SAS are being used by what user accounts.
SAS Employee

I've been looking around and neither opensnoop in BCC-tools nor in bpftrace can do filtering based on the directory the file was opened from. If I get some time I'll see if I can work this out and send either group a patch if there isn't a tool that does this already.

Lapis Lazuli | Level 10

You can get this information from /proc/pid/maps for individual pids. It's something we've considered building into ESM


Check it out:


nik at apps in /proc/4597
$ sudo cat maps | awk '{print $6;}' | grep SASFoundation | grep .so | sort | uniq

I think there's information around from a few years ago regarding what library maps onto which product set. I remember someone wrote a paper on using strace and then processing the logs using SAS. This approach should be much more performant / cleaner.



SAS Employee
The maps are a good idea. Good thinking @boemskats. The only thing with it is you have to poll to catch the maps of tasks as far as can tell. For short running jobs it will be unlikely you'd catch it unless your poll interval is pretty high. For long running tasks and workspaces that stay up a while the user is connected with their client this would work perfectly.

An idea actually would be to somehow add a hook on SAS session termination that captures the /proc/self/maps. Not actually sure if there is any facility to write some code that is hooked to the exit event but that would be a pretty elegant solution.

strace(1) is pretty violent with loads of CPU context switches happening. For every traced event you have to context switch to strace for both the syscall entry and exit. The impact to the performance would be too much to be something you could really use safely across a lot of processes on a heavily loaded production system.
SAS Employee

There is an option to hook some SAS code on the exit event. The termstmt option is what you use. Combine this with a bit of macro and I'd say you have a fairly awesome little solution to the problem. @AndrewHowell please keep us in the loop with what you decide to try and do share your experience with how it worked out I'm pretty interested to know.



%macro read_maps;
	data maps;
			address $34
			perms $4
			offset $8
			dev $5
			inode 8
			pathname $256;
		infile "/proc/self/maps" dlm=' ' truncover;
		input address perms offset dev $ inode @74 pathname $256.;
	proc sort data=maps;
		by pathname;
/* Just print it in the log for now but you can do more interesting stuff like write it out somewhere */ data _null_; set maps; by pathname; if first.pathname then put pathname=; run; %mend; %read_maps; /* Add this SAS config option to make the macro run on SAS stopping, you'll need make sure the macro is availble to the sessions -termstmt="%read_maps;" */




Hi @boemskats & @SimonDawson,


Thanks for the responses.


I've used TERMSTMT plenty of times, but never thought to leverage /prod/self/maps - this look like an excellent way to audit usage.


Last step - is there a "mapping document" to link the various SAS modules to their corresponding license items (STAT, ETS, etc)?



SAS Employee

Its going to be procedure based for SAS/STAT and SAS/ETS. Each procedure will load a unique library. That will require some experimenting on your part by looking at the SAS/STAT and SAS/ETS manuals, check the list of procs, issue proc foo; run; for each one in the manuals and map out what you see in the maps.

If my guess as to what products the customer you are working with has this is what you'll be interested in for SAS/ACCESS stuff.

SAS/ACCESS Interface to Hadoop

  -> SASFoundation/9.4/sasexe/sasiohdp

SAS/ACCESS Interface to Microsoft SQL Server

   -> SASFoundation/9.4/sasexe/sasiosrv

SAS/ACCESS Interface to Oracle

   -> SASFoundation/9.4/sasexe/sasioora

SAS/ACCESS Interface to Teradata

    -> SASFoundation/9.4/sasexe/sasiotra


Thanks, @SimonDawson (good guess on the customer), but it there a complete, definitive list available?

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

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.

Discussion stats
  • 12 replies
  • 6 in conversation