Who Deleted That IFS Object? A Guide for IBM i Sleuths

Picture this: you’re sipping your morning cup of PG Tips Tea, contemplating a third hobnob biscuit dunker, ready to tackle another day of IBM i wizardry, when someone screams, “Who deleted that critical file in the IFS?!” The office goes silent. All eyes are on you, the resident IBM i guru.

You gulp Loudly.

You try to hide behind that box of biscuits while thinking about journal entries, system logs and message queues that just might let you find out how deleted what!

Sweat starts to plop into your cuppa!

Fear not, brave programmer! With a few trusty commands and a sprinkle of SQL magic, you’ll unmask the culprit faster than you can say “WRKSYSSTS.”

CAVEAT EMPTOR – This will work if you are recording DELETIONS as part of your system auditing level. Check the value of your QAUDLVL system value and ensure it includes the DELETE settings.

The default value may look like this:

Simply by adding CREATE and DELETE you will now audit all object creations and deletions. My settings look like this:

If you are auditing deletions, then we can proceed. If not, climb behind your cup of tea and pretend you don’t know what is going on.

Having said that, with deletion auditing active, here is your step-by-step guide to solving the mystery of the missing IFS object.

Step 1: Create Your Evidence Locker

First, you need a place to store the clues. Think of it as setting up a CSI lab for your IBM i system. We’ll create an output file to hold the audit records by duplicating IBM’s trusty QASYDOJ5 file.

What is the IBM i QASYDOJ5 file?

The QASYDOJ5 file on IBM i systems is part of the main IBM i System Library and is associated with the IBM i Audit Journal functionality. Specifically, it is a database file used to store audit journal entries for the DO (Delete Operation) audit type, which tracks object deletion events on the system. The QASYDOJ5 file contains audit journal entries related to delete operations performed on objects within the IBM i system. These entries are generated when the system is configured to audit delete actions as part of its security and auditing policies.

QASYDOJ5 is a physical file that stores structured data in a format defined by IBM i for audit journal entries. Each entry includes details such as:

• The timestamp of the delete operation.
• The user profile that performed the deletion.
• The object name, library, and type that was deleted.
• The job name, number, and other relevant job information.
• Additional metadata, such as the system name and audit entry type.

The file is typically linked to the QAUDJRN journal in the QSYS library, which is the primary journal for security auditing on IBM i.

Run this command, and try not to feel like you’re forging a detective badge:

CRTDUPOBJ OBJ(QASYDOJ5) 
  FROMLIB(QSYS)
  OBJTYPE(*FILE)
  TOLIB(YourLibrary) 
  NEWOBJ(SherlockFile)

Replace YourLibrary with your favorite library (no, not the one with books) and SherlockFile with a name that screams “I’m solving crimes here!”

This creates a shiny new file ready to capture the audit trail.

Step 2: Dust for Prints with DSPJRN

Now it’s time to interrogate the system’s journal, QAUDJRN, which is like the IBM i’s security camera footage.

The DSPJRN command will extract the juicy details into your SherlockFile.

But beware—pick the right journal receiver, or you’ll be chasing ghosts from last year’s backups.

Here’s the command to get those audit records:

DSPJRN JRN(QAUDJRN)                     
       RCVRNG(*CURCHAIN)                
       JRNCDE((T))                      
       ENTTYP(DO)                       
       OUTPUT(*OUTFILE)                 
       OUTFILFMT(*TYPE5)                
       OUTFILE(YOURLIBRARY/SHERLOCKFILE)

A few pro tips:

• AuditLibrary/Receiver should point to the journal receiver active when the object vanished. Check WRKJRNA if you’re unsure—it’s like checking the timestamp on the security footage.
• JRNCDE((T)) and ENTTYP(DO) filter for object deletion events. We’re only interested in the “DO” (delete object) entries, because nobody cares about who printed 500 pages of test data (yet).
• OUTFILFMT(*TYPE5) ensures the output is detailed enough to crack the case.

Step 3: Play Detective with SQL

Now that you’ve got a file stuffed with audit records, it’s time to sift through the evidence like a true IBM i sleuth. Fire up SQL (STRSQL, ACS, or your favorite tool) and run a query to zero in on deletions in the /QFPNWSSTG directory.

This is where you separate the wheat from the chaff—or the deleted files from the irrelevant noise:

select DOTSTP,
       DOJOB,
       DOUSER,
       DONBR,
       DORADR,
       DORPORT,
       DOOTYP,
       DOASP,
       DOPNM
  from YOURLIBRARY.SHERLOCKFILE
  where DOPNM like '/home/%'

Here’s what you’re looking at:

• Dotstp: The timestamp of the crime—when the object was deleted.
• Dojob: The job that did the deed.
• Douser: The user profile of the culprit (call them out at the next team meeting).
• Donbr: Job number, because why not be thorough?
• Doradr and Dorport: Remote address and port, in case it was a sneaky network job.
• Dootyp: Object type, so you know what got zapped.
• Doasp: ASP number, for those extra nerdy details.
• Dopnm: The path name, confirming it’s in /QFPNWSSTG.

Run this query, and you’ll have a list of suspects showing exactly who deleted what and when.

This is an example where I just asked for the job info like this:

select DOTSTP,
       DOJOB,
       DOUSER,
       DONBR,
       DOOTYP,
       DOPNM
  from SHERLOCK.SHERLOCKDB
  where DOPNM like '/home/sherlock%'

If the list is empty, double-check your journal receiver range. Maybe the crime happened before or after your selected receiver. Or maybe the file’s just hiding in another directory, mocking you.

Watch this in real time!

Congratulations, you’ve just solved an IBM i mystery! With your output file, cunning DSPJRN prowess, and SQL finesse, you’ve tracked down the dastardly IFS object deleter.

Now go confront the culprit (politely, of course) or at least restore that file from backup before anyone notices. And maybe treat yourself to another cup of brew… you’ve earned it, detective!