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)?
Thanks,
Andrew.
try this
proc product_status;
run;
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:
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,
Michelle
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.
I've been looking around and neither opensnoop in BCC-tools nor opensnoop.bt 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.
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 /pub/sas/SASFoundation/9.4/dbcs/sasexe/sasoda /pub/sas/SASFoundation/9.4/sasexe/sasjson /pub/sas/SASFoundation/9.4/sasexe/sasodr /pub/sas/SASFoundation/9.4/sasexe/sasods /pub/sas/SASFoundation/9.4/sasexe/sasodsm /pub/sas/SASFoundation/9.4/sasexe/sasodst /pub/sas/SASFoundation/9.4/sasexe/sasodtpo /pub/sas/SASFoundation/9.4/sasexe/sasoevt /pub/sas/SASFoundation/9.4/sasexe/sasofen /pub/sas/SASFoundation/9.4/sasexe/sasomip /pub/sas/SASFoundation/9.4/sasexe/sasoptio /pub/sas/SASFoundation/9.4/sasexe/sassort /pub/sas/SASFoundation/9.4/sasexe/saszsort /pub/sas/SASFoundation/9.4/sasexe/skndns.so /pub/sas/SASFoundation/9.4/sasexe/t0a0en.so /pub/sas/SASFoundation/9.4/sasexe/t0a4en.so /pub/sas/SASFoundation/9.4/sasexe/t0a6de.so /pub/sas/SASFoundation/9.4/sasexe/t0a6en.so /pub/sas/SASFoundation/9.4/sasexe/t0a8en.so /pub/sas/SASFoundation/9.4/sasexe/t0c8en.so /pub/sas/SASFoundation/9.4/sasexe/t0d2en.so /pub/sas/SASFoundation/9.4/sasexe/t0l1en.so /pub/sas/SASFoundation/9.4/sasexe/tk4aboot.so /pub/sas/SASFoundation/9.4/sasexe/tk4afref.so /pub/sas/SASFoundation/9.4/sasexe/tk4aiomc.so /pub/sas/SASFoundation/9.4/sasexe/tk4aiome.so /pub/sas/SASFoundation/9.4/sasexe/tk4aioms.so /pub/sas/SASFoundation/9.4/sasexe/tk4aroll.so /pub/sas/SASFoundation/9.4/sasexe/tk4aunxf.so /pub/sas/SASFoundation/9.4/sasexe/tkarm.so /pub/sas/SASFoundation/9.4/sasexe/tkautop.so /pub/sas/SASFoundation/9.4/sasexe/tkcacr.so /pub/sas/SASFoundation/9.4/sasexe/tkcacs.so /pub/sas/SASFoundation/9.4/sasexe/tkcacw.so
...
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.
Nik
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;
length
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.;
run;
proc sort data=maps;
by pathname;
run;
/* 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)?
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/orlax11
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sas
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sasauto
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sasautop
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sasbins
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sasdosm
/sas94/SASHome/lev2/SASFoundation/9.4/sasexe/sase7io
etc..
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?
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.