Figuring out who’s been accessing, and perhaps modifying, your reports can be tough. This little utility provides you with the means to track all spooled file activity.

Most shops probably practice good security by not allowing unauthorized users to access spooled files they don’t own. This is a good idea as it keeps both the unscrupulous and the merely curious from printing or viewing sensitive information. It is also very easy to accomplish; simply do not grant the Spool Control (*SPLCTL) special authority to unauthorized users on their user profiles. By not granting this special authority, you are ensuring that those users cannot inadvertently view or print documents they did not create. Of course, this does not mean that all of your spooled file security problems are over. If a user profile belongs to a group profile, then any spooled file created by anyone in that group has full access rights to any spooled file created by anyone else in that group.

Sally Sells Seashells

Let me give you an example: Sally, who is a member of the SALES group profile, is a great salesperson. To prove it, she runs a daily sales analysis report, which she leaves on her output queue so her boss can later view it to see all the clients she sold to that day.

What Sally doesn’t know is that Rodney, who couldn’t sell oxygen to an astronaut, is also a member of the SALES group profile on the company AS/400. Now Rodney, being the shifty character that he is, reads Sally’s report every night so he can see to whom she’s selling. That way, he can go out the next day and try to steal her clients. Poor Sally has no idea that Rodney is up to something, and she continues merrily on her way until the day when Rodney finally manages to steal enough of her sales to put her out of commission.

I Didn’t Do It!

Another situation that frequently occurs in shops is that many user IDs have more authority than they really need. Specifically, they have been granted the *SPLCTL special authority. In general, this doesn’t cause a huge problem, except for those times when

reports suddenly come up missing. You might ask the employees in your shop if they accidentally (or otherwise) deleted or printed the missing report, but you may never learn exactly what happened to your lost document. People forget, don’t realize they printed or deleted the wrong report, or just plain don’t want to admit making a mistake. What do you do in this situation? You don’t want to limit the special authority on their user IDs since, for the most part, it works out really well. The best you can do in most cases, then, is to issue a warning to everyone to pay closer attention and use caution when working with spooled files.

Journaling Is Your Answer

Well, there is a way to better monitor what’s going on with your spooled files. You can use auditing to track activity relating to your spooled files. Auditing spooled files involves creating an audit journal if it doesn’t already exist, attaching a journal receiver to it, and indicating in the appropriate system value (QAUDLVL) that spooled files should be audited. Unfortunately, viewing the data in an audit journal is somewhat difficult. The data is stored in a compressed format that is hard to read and fairly unmanageable. This utility will demonstrate and even provide you with a real working example of how you can display that audited information. I’ll also show you how to set up auditing on your AS/400 so you can capture the information that will tell you who’s been messing around with your spooled files.

How to Get Started

To audit the activity affecting spooled files, you will need to tell your AS/400 to track all activity as it relates to spooled files. The first thing you should do is to determine whether or not you already have an audit journal defined to store the entries your system will generate. From any AS/400 command line, type in the command WRKOBJ QSYS/QAUDJRN *JRN and press Enter. If the journal named QAUDJRN already exists, it will appear in the resulting list. If it does not exist, you will need to create it. You will also need to create a journal receiver. It is the journal receiver that will actually store the journal entries.

To create and use the tools in this article, you should be signed on with a user profile that has *SECADM (security administrator), *ALLOBJ (all object) and *AUDIT (audit) authority specified in the user profile Special Value parameter. You need to have only the *ALLOBJ and *AUDIT authorities to change the system values that affect auditing, but I suggest you create the utility itself with a profile that has the *SECADM authority so that only you and anyone else with this authority can view the journaled entries. By creating the utility in this manner, any case of finger pointing amongst your users will be prevented since they won’t be able to run this command and then accuse someone else of deleting their reports.

Creating the Journal and Receiver

If the journal QAUDJRN does not exist, you can create it yourself. Before you do, however, you will need to create a journal receiver. The journal receiver is the system object in which the journaled entries are stored. For a more in-depth look at journaling, check out the article “Logging All CL Commands” in the December 1994 issue of MC. Another great article is “The Case of the Bad Inventory Accounts,” in the August 1997 issue of MC; author Tim Johnston does a great job of explaining journals and how to understand the data stored in the journal receivers.

To create a journal receiver, enter the command like the one shown in Figure 1. This action will create a journal receiver named SPLFJRN1 in library QSYS. Of course, you can create the journal and receiver in any library you wish. To create the system journal QAUDJRN, which is required for auditing spooled files (and many other types of data as well), use the command shown in Figure 2. This command will create the system journal QAUDJRN in library QSYS and attach the journal receiver SPLFJRN1, which you created in the previous step. If the system journal QAUDJRN had already existed, you could have attached the new receiver SPLFJRN1 by using the Change Journal (CHGJRN) command,

shown in Figure 3. CHGJRN is also the command you will use to add new or remove old journal receivers from the QUADJRN journal when you feel it is time to save or delete the old data.

Once you have created the journal and receiver, you will need to start auditing your spooled files on your system. From a command line, type in the command WRKSYSVAL QAUDLVL and press Enter. You will see a typical “work with” panel showing you the system value QAUDLVL. QAUDLVL is the Security Auditing level system value, and, as its name implies, controls what gets audited on your system. Enter a 2 to change this value and press Enter. In the Auditing Options parameter, enter the value *SPLFDTA. This value tells the system to track all changes to spooled files on your system. There are many other values you can enter on this parameter to track a wide variety of system activities. If you’re interested in other possibilities, place your cursor on this parameter and press F1 to display the help for this field. After you have entered the *SPLFDTA value on this parameter, press Enter. That’s it. That’s all that’s required to start auditing spooled file activity. If you had not yet created the system journal QAUDJRN, or if it didn’t already exist, you would not have been allowed to set the value for this system value.

What Is Tracked

So what type of entries are stored in your journal receiver for spooled files?
• Entries for spool file creation
• Entries when spool files are held
• Entries for spool file changes (e.g., number of copies, output queue, etc.)
• Entries when someone other than the owner views the spool file As you can imagine, all these entries can add up to a significant number in your journal receiver on a daily basis. It’s a good idea to periodically, say at month end, detach and delete old journals.

There are a couple of quirks with the information in the journal entry. When a spooled file is created, the job information of its creator is stored in this entry. When the spooled file is changed, say by another user who changes the number of copies, the job information of that other user gets stored in a new entry. When another change is made to that same spooled file, say it gets deleted by yet another user, it is the last user’s information that gets stored with the journal entry. This progression makes sense, but when you are trying to track the life of that spooled file, it also makes it tough to determine the file’s original creator. That’s one of the benefits of the Spooled File Audit (SPLFAUD) command. It correlates all of this information for you and lets you know who the original creator of the spooled file was. It also displays the information in a more user-friendly format.

The SPLFAUD Command

Command SPLFAUD (Figure 4) has five parameters: ACTION, OUSER, CUSER, FILENAME, and REBUILD. All are optional; that is, you can take the default entries for each one. The Action parameter controls what type of journal entries you will see. You can enter *CHG, *DLT, *RLS, *HLD, or *RBN. Except for the *RBN value, most of these values are self-explanatory. *RBN stands for Read by Nonowner. When you select this value, you will get a list of all spooled files that were created by one user but read by another user. Using this parameter is a good way to see who has been reading other people’s reports. If you enter *ALL in this parameter, you will see all entries, including entries for all reports that were created. The functions of the four other SPLFAUD parameters are as follows:

• The OUSER parameter allows you to bring up a list of spooled files that were created by a specific user ID.

• The CUSER parameter allows you to bring up a list of spooled files that were changed by a specific user ID.

• The FILENAME parameter allows you to bring up a list of spooled files in which the spooled file name matches the value you enter here.

• The REBUILD parameter specifies whether or not to rebuild the input file used by this utility. The input file used by this utility is the output created from running the Display Journal (DSPJRN) command. If you enter a Y to rebuild the journal entries, the file SPLAUDJ is cleared, and then all spooled file entries in the journal receiver are extracted from the journal receiver and placed in the file SPLAUDJ. You should periodically rebuild this file, as this is the only way to keep an up-to-date list of all spooled file activity. If you use this utility/technique in your own shops, you may want to consider rebuilding this file on a scheduled basis by using the AS/400 Job Scheduler.

All command parameters as well as the command itself have Help text included. Simply position your cursor over a field and press F1. The Help text is stored in a User Interface Manager (UIM) panel group member named SPLFAUDPNL. The code for this command consists of a command source, a help panel source, a display file, a CL source, and an RPG IV program source, all of which can be downloaded from Midrange Computing’s Web site at www.midrangecomputing.com/mc/99/02.

Running the Command

When you run the command, you’ll be presented with a screen like the one shown in Figure 5. Notice the entries toward the bottom. They show a spooled file named SOF100, which was created by user SHANNON and read by user BRIAND. Since BRIAND wasn’t the owner of the spooled file, an entry was placed in the journal receiver indicating that he read it. Entering a 5 in front of any of these entries will give you a second screen showing you more detailed information, such as the original number of copies on the spooled file as well as the number of copies it was changed to.

Keeping an Eye on Things

The SPLFAUD command, along with system auditing, is a great way to keep an eye on what’s going on with your system’s spooled files. Now, you can easily see who created what, who deleted what, and, perhaps most important of all, who read what. System security just got a little bit tighter!

Figure 1: Create a unique journal receiver to store your spooled file journal entries

Figure 2: Create the system journal QAUDJRN

 

Figure 3: Use the Change Journal (CHGJRN) command to attach a new journal receiver to an existing journal

Figure 4: The Spooled File Audit (SPLFAUD) command

 

Figure 5: Tracking your spooled files is easy using the SPLFAUD command

Shannon O'Donnell has held a variety of positions, most of them as a consultant, in dozens of industries. This breadth of experience gives him insight into multiple aspects of how the AS/400 is used in the real world. Shannon continues to work as a consultant. He is an IBM Certified Professional--AS/400 RPG Programmer and the author of an industry-leading certification test for RPG IV programmers available from ReviewNet.net.

 

Also Read

Partner TechTip: End the Scourge of Ugly Forms!

Partner TechTip: The Pursuit of a Paperless Process

It's Just Another Day, But Do You Know What Your Reports Are Doing?