How to record speed of UniVerse verbs such as SELECT and SORT?

Question

I remember seeing an article somewhere that outlined a clever way to wrap a UniVerse verb, like SELECT, in a custom basic program in order to record some metrics such as elapsed time. The easy answer is to share that link, if you are familiar with that article.

Otherwise, I appreciate any sample code you might be able to share that exemplifies the proper way to create such a wrapper.

I would like to write some data to a file, and capture things like the user, the file involved, the amount of time used to perform the selection, and whatever phrase was included with the SELECT statement. I plan to send this data to another system for analysis and reporting, so that we can better visualize how well various selections are performing.

Thanks for your time and I am looking forward to discussing a solution with you!

UPDATE!

After seeing Van's answer, I must clarify that I am most interested in recording the processing time of the statement, and gleaning some other information purely for logging purposes. My goal is to make it transparent so that I don't end up breaking everything or anything.

My logic is something more like this:

• Statement is fired, and wrapper program makes note of the current time.
• The plain vanilla sentence is executed by the wrapper.
• When the selection is complete, wrapper notes the current time again and records the difference from start time.
• While we're in here, use various SYSTEM(x) and/or @ values to capture user name and maybe the number of records.
• Use some logic to parse the statement and record other interesting tidbits.
• Write the interesting values to one log file, with incrementing ID.
• User or proc is oblivious and ends up with the select list as usual (somehow... insert magic here)
• Some other decoupled process feeds each record to a reporting system in regular batches.

Does that make more sense?

Answer 1

I will caveat this by saying that I would be terrified to try anything liek this on a production system for 3 reasons.

1. SELECT is used in lots of places and this could quickly become an I/O issue if you have lots of Phantoms and users running stuff at the same time which leads into...
2. Depending on the number of files your system has finding a way to meaningfully organizing the data in a way that does not invite locking or overwriting issues would be a large challenge.
3. SELECT has a pick style usage and a SQL style usage and they do not behave the same.
4. This is hacky as all get out.
5. Counting is for wimps.

That said, you can pretty much replace any word in the VOC. You could copy the VOC entry for SELECT into SELECT.BASE and then replace it with your own cataloged SELECT where you catch the command line parameters as such.

SENTENCE       = @COMMAND
FILE.NAME      = FIELD(SENTENCE,' ',2)
CONDITIONS     = FIELD(SENTENCE,' ',3,999)
NEW.STMT       = "SELECT.BASE ":FILE.NAME:" ":CONDITIONS

You would then do whatever ever sort of processing before or after you EXECUTE NEW.STMT.

I have no idea what this will break so try it at your own risk.

Answer 2

The sample program that I ran into a while ago was in one of Rocket Software's GitHub repos, multivalue-lab. The program there is called VERBTIMER.

However, that program also exhibits the bug I found in my own experimenting, where any previous active select list is ignored.

I opened an issue on GitHub and will update this post if a solution is found.