Tracking critical file access in real time

A method for tracking critical file access in real time.

If you're a regular reader, you'll know that last time around, I presented a method where you can use OS/400 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 week, 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 accesses 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 cool trick, we'll implement 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 OS/400 *PGM object. When it is associated with a *FILE, OS/400 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 parameter 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 better to 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 e-mail 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, just let me know and I'll send you a copy via e-mail. You can reach me at rich@kisco.com, I'll do my best to answer any questions. All e-mail messages will be answered.


Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.


This was first published in November 2004

Dig deeper on iSeries system and application security

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchEnterpriseLinux

SearchDataCenter

Close