I also wanted to track what object code is being used to help find out what code is in use and what is not. This only works if you're using Linux as your host os.
For my first attempt was to use the last access time on the object code file. That number looked reasonable to me but when I sent out a list object code files that hadn't been accessed in the last few years some of the other developers swore that those programs were actually in constant use. Anyway, that's not on all file system types and lots of systems disable updating it for performance reasons.
The method I finally took was to use Linux's auditctl service to create log entries whenever one of the object code programs is accessed.
In the /etc/audit/rules.d folder I added a file called objectcode_run.rules. The file looks like this:
root:/etc/audit/rules.d$ cat objectcode_run.rules
-w /objectcode -p r -F exe=/usr/uv/bin/uvsh -k "objectcode_run"
-w /objectcode -p r -F exe=/usr/uv/bin/uvdlssh -k "objectcode_run"
Next you would tell auditctl to reload the rules: "augenrules --load".
This rule creates an entry in the audit log whenever uvsh or uvdlssh accesses a file in the /objectcode folder or any of it's sub-folders. On my system this is all I needed to do because I've put all the object code files as sub-folders of /objectcode. If you have multiple files in different accounts you could add separate rules for each one. You could also add any proc or paragraph files to the audit rules if you wanted to track those.
I don't think I need the uvdlssh rule. That's the dll you run to activate shared licensing but I think it just runs uvsh. I dont' think I saw any log entries with the uvdlssh file.
You end up with a bunch of log entries. You can use the "ausearch -k objectcode_run -i -ts mm/dd/yy hh:mm:ss" to list all the log entries after a specific time and date. You get a bunch of lines that look like this:
----
type=PROCTITLE msg=audit(08/01/2024 16:15:02.221:737983) : proctitle=uvsh EDI.SAP.DRIVER
type=PATH msg=audit(08/01/2024 16:15:02.221:737983) : item=0 name=/objectcode/EDI.SAP.BP.O/EDI.READ.947.SUB inode=272169 dev=fd:04 mode=file,660 uid=jgold ogid=bars rdev=00:00 obj
type=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(08/01/2024 16:15:02.221:737983) : cwd=/accts/SAP.WHS
type=SYSCALL msg=audit(08/01/2024 16:15:02.221:737983) : arch=x86_64 syscall=open success=yes exit=9 a0=0x7ffdc5f96f70 a1=O_RDONLY a2=0x1b6 a3=0x24 items=1 ppid=56894 pid=56909 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=79446 comm=uvsh exe=/usr/uv/bin/uvsh key="objectcode_run"
Next I wrote a python program that executes the ausearch command and parses the results into an sqlite3 database file. I keep track of the last date processed so I can list just the entries that happen after that date. The log can be huge but specifying a starting date speeds it up a lot.
It's been running on our production system since July 23rd. So far it shows 376 programs have been accessed. There are 6,895 compiled programs in that folder so most of that is not being used on a regular basis. I think it might take a year or so before we get a complete picture.
I chose python to parse the ausearch results because it's good at it. I chose sqlite3 to store the results because it's included with python and it makes it easy to view the results. You could put the results in a mvdb database file if you want. I didn't want to use a Universe license and I'm pretty good with sql so I just went with sqlite3.
This adds more entries to the audit logs. They're set up to rotate to new files when they get to a certain size and only keep a certain number of log files. The result of this would be that you're not keeping things as long unless you bump up how large and how many log files it keeps. I haven't had any performance problems but our system doesn't seem to suffer from that at all anyway.
I can send you my notes and the python program if you're interested. I'm not recommending this as the best way to do it. It's just what worked for me.