Domain Failures- Moving to a Higher Security Level

The entries I typically find at my clients are D (domain failures) and more often, J (job description use). If you have any domain failures, the program name and library in the D audit journal entry identify the program running at the time of the failure. The object name is the object being accessed, and if there’s an instruction number, that’s the statement number in the program where the object is accessed. It’s usually that an operating system program is being called rather than a command or API. One of my clients had domain failures because they were directly calling the program that’s called by the SIGNOFF command rather than calling the command itself. Why the original programmer coded it this way is beyond me, but it was an easy fix, as most domain failures are.

I have not seen an application that doesn’t run at QSECURITY level 40 for many, many years. However, you may see some AF-D entries listed for them. Some vendors still take a different code path at the lower security levels than at level 40 or 50. If you discover entries for vendor products, don’t assume there’s an issue. A quick call to the vendor will verify that their application does run at level 40 and you can ignore those audit journal entries.

I will often find no audit journal entries and wonder whether my SQL is correct or I’m missing something. If I need to test my method, I’ll force an AF-D entry. That’s easily done by attempting to call an operating system program. Since I’m familiar with it, I attempt to directly call the program that’s called by the Create User Profile (CRTUSRPRF) command. Simply running the following from a command line will cause an AF-D entry to be generated:

It’s a quick and easy way to make sure you’ll detect issues if you have any. Most of my clients have no issues, so this is the only entry that shows up in my reports.