Snooping On Critical Files

By Rich Loeber

If you're a regular reader, you'll know that last time around, I presented a method where you can use IBM i/OS object auditing to keep track of who is doing what with selected files and objects. That's a good way to keep a record of what's happening with these critical resources on your system, but no matter how often you check results, it is always after the fact. This time, I'll give you a way to track and report on file access for read, change and/or delete with immediate, real time notification. Using this method, you'll know right away when someone is in the critical file you want to keep an eye on. And, nobody will know about it except you, if you can keep quiet about something this cool.

To accomplish this trick, we'll create a very simple trigger program and then associate it with the file you want to track. Keeping the trigger program simple is a key to success for this method of object tracking control. Keep in mind that every time the file is accessed for the method you choose (which you will see as you read on), the trigger program will be run by the system and it will run in line with the application that is accessing your file. I'll put in some cautions along the way to point out where this might be an issue.

A trigger program is nothing more than a standard IBM i/OS *PGM object. When it is associated with a *FILE, the OS will call the program according to the instructions you provide with the trigger file registration. Your trigger program must have two parameters, one for information about the event and the other a simple binary two byte number that will provide you with the length of the first parameter information. The first parm can be variable, but for a simple application like this one, you can code it at a fixed length. The variable length is there to support multiple record length files and the actual record contents are passed to the trigger program, but for our purposes, we won't be using that part of the information. I code the first parameter with a length of 136 and the second parameter with a length of 2. The first 30 positions of parameter 1 contain the file name, library name and member name in that order. Position 31 will have an indicator as to the trigger event and position 32 has the trigger time indicator.

You associate the trigger program with the file by using the Add Physical File Trigger (ADDPFTRG) command. The parameters on this are fairly self explanatory. Since you don't want to hold up production, use the *AFTER option for your trigger time setting. The trigger event will indicate when you want the trigger to be called and the values are:

• *INSERT - whenever a record is added to the file
• *DELETE - whenever a record is deleted from the file
• *UPDATE - whenever an existing record is changed in the file
• *READ - whenever an existing record in the file is read

A word of warning about using the *READ option, this can generate a huge number of calls to your trigger program and it is probably for the best if you avoid using it. If you want to track multiple events, you will have to register each one with a separate use of the ADDPFTRG command.

When you're all done with your tracking project, remember to clear your trigger file registrations. This is done using the Remove Physical File Trigger (RMVPFTRG) command. Just use the defaults once the file is specified and all of the trigger registrations can be removed at once.

How you code your trigger program itself depends on what you want to find out. If you're looking for a specific user profile, then check for it. If you're looking for a specific time of day or day of the week, check for that. When you've found something that qualifies, or if you just want to report on everything, use the SNDMSG to send a message to your user profile (or a list of user profiles that you store in a data area) and you're done. If you use the SNDDST to send an email notification, it would be best to do this via a SBMJOB so that the application processing is not held up while you get this sent.

To better explain this technique, I've written a simple CLLE program that can be used with any file and contains comments along the way to show different options that you might want to implement. If you'd like a copy of this trigger file shell program for free, just let me know and I'll send you a copy via Email.

If you don't want to bother with coding your own solution, Kisco's iFileAudit software has this capability built in along with a lot of other neat ways to keep track of what's going on with your files. It is available for a free trial on your system.

You can reach me at rich at kisco.com, I'll do my best to answer. All email messages will be answered.