Using the New Security Features in the Latest IBM i Technology Refreshes

IBM i (OS/400, i5/OS)
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

The TRs for IBM i V7R3 and V7R4 have some very cool stuff. Carol gives you a tour.

Yes, once again the IBM i development team has provided us with new features that will help make security administration easier. You can find information on all of the new features of V7R3 TR10 here and V7R4 TR4 here, but I thought it might be helpful to provide examples of how and why I’ll use four of these new features.


This service is similar to running the Display Security Attributes (DSPSECA) and Display Security Auditing (DSPSECAUD) CL commands along with the Retrieve Security Attributes API (QSYRTVSA). But instead of calling two CL commands, which only go to display or write to an API, you can retrieve all of the information in one easy Select statement!

If you’ve ever run DSPSECA, you’ll know that it displays somewhat random security configuration information, but if you need that information, it’s the only place you can discover it. For example, I find it useful to run DSPSECA to determine whether a change to either QSECURITY or QPWDLVL has taken effect. DSPSECA shows both the current and pending values. (Remember, it takes an IPL for changes to these system values to take effect.) Note: If the current and pending values are the same, only the current value is displayed.

I find running DSPSECAUD helpful to determine which audit journal receiver is currently attached. While not all of what I consider to be security-relevant system values are available via SECURITY_INFO, most of them are, so this will allow you to easily check their values on a regular basis. And if you’re pulling information from multiple partitions, you’ll want to add this to your list of information you retrieve so that you can ensure your security system values are set the same on each of your partitions. Details on this service can be found here.


This IBM Service provides the same information as QSYS2.USER_INFO except it doesn’t provide the USER_OWNER , USER_CREATOR, SIZE, CREATION_TIMESTAMP, LAST_USED_TIMESTAMP, DAYS_USED_COUNT, or LAST_RESET_TIMESTAMP fields. Not much to say about this one except that if you are one of those IBM i shops with thousands of user profiles, you may want to switch to this view if you’re not using the fields listed here to get better performance with your SQL. Check out the documentation here.


This table function provides a subset of the attributes that can be changed using the Change User Profile (CHGUSRPRF) command. But in this case, you can select the user profiles you want to modify and then make changes to them—all in SQL. Think about wanting to automate the disabling profiles when your organization deems them to be inactive. I provided this example in my last article, so building on that, you can now use this function to set the profiles to status of *DISABLED rather than running CHGUSRPRF against each profile yourself. Much more efficient and handy, don’t you think?



                             P_USER_NAME => AUTHORIZATION_NAME,

                           P_STATUS     => '*DISABLED',

                             PREVIEW     => 'NO'))

WHERE (last_used_timestamp is NULL or

     last_used_timestamp < current timestamp - 3 months ) and

     (creation_timestamp < current timestamp - 3 months );

If you’d prefer to review the list of profiles about to be changed prior to making the change, change the Preview field to YES in the table function. Not all user profile attributes are included in this function (some notable ones that are missing include the supplemental group and special authorities attributes), but enough are included to make this useful and, hopefully, over time, IBM will provide a fully functional equivalent of CHGUSRPRF. More information on this table function can be found here.

Audit Journal Entry Services

Last but certainly not least, IBM has provided us with four services that parse out the details of the AF – Authority Failure (AUDIT_JOURNAL_AF), CA – Changes to Authority (AUDIT_JOURNAL_CA), OW – Ownership Changes (AUDIT_JOURNAL_OW) and PW – Password (AUDIT_JOURNAL_PW) audit journal entries! All are found in SYSTOOLS library and details are documented here.

Yes, we’ve been able to use the QSYS2.DSIPLAY_JOURNAL view to retrieve audit journal entries for a while now. But for the reasons I look in the audit journal, I’ve found this function to be almost worthless. That’s because the only portion of the audit journal entry that’s parsed is the header, which is common to all audit journal entry types. Using this view, it’s left up to you to parse the details of each type. No, thank you. So while this feature is great when you’re sending audit entries in SYSLOG format to a SIEM, it’s not helpful for the analysis that I perform for my clients because I’m typically looking at the information in the detailed portion of the audit journal entries.

Without using these services, I must first run the Copy Audit Journal Entry (CPYAUDJRNE) command; then I can run my SQL to get to the entries I’m really interested in. For example, if I’m trying to determine who changed the authority on a specific file (HR_NFO/SALARY), I’ll run CPYAUDJRNE CA *CURCHAIN to first get all of the CA entries out of the audit journal. Then I do an SQL SELECT to find the entries I’m looking for. Do you have any idea how many CA entries occur throughout the running of a normal day? Potentially millions. But I’m just looking for a handful of entries! The file created by running CPYAUDJRNE may be huge, and if I decided to keep that file in a library (rather than letting the command default to putting the file in QTEMP and getting deleted when I signed off), I’m keeping around a huge volume of information compared to what I actually need. Instead, I can simply run the following and get right to the information I’m looking for.

The following SQL lists all CA entries generated during the last seven days. It’s handy but not all that different from running CPYAUDJRNE.





However, this statement gets me to the exact entries I’m looking for in one statement. I can tell who made the change (USER_NAME field), the day and time (ENTRY_TIMESTAMP FIELD), and the profile to whom the authority was added or removed (USER_PROFILE_NAME field). You can also scroll through the various authority and previous authority fields in the entry to determine the exact permissions granted or revoked.








I can’t tell you how excited I am to be able to access the audit journal in this way. If for no other reason than to take advantage of the easy way you can perform timestamp arithmetic, I’m going to switch how I access these audit journal entries. I’m guessing this is the tip of the iceberg; we might be seeing more of these for other audit journal entry types. To have a say in which ones are next, you can either open a Request for Enhancement (RFE) or send an email to or tweet Mr. SQL (aka Scott Forstie) at This email address is being protected from spambots. You need JavaScript enabled to view it. or @Forstie_IBMi and let him know which audit journal entries you use most and want to see in this format. (You might also include a big thank you to him and his team for all of the cool function they’ve been providing the last few years.)


Hopefully, I’ve given you reasons to install the latest TRs and start experimenting with these new features. Knowing the inventive ways people use the system, I know you can come up with even more clever ways to utilize these powerful features provided by the crack IBM i development team. I challenge you to use these features and make it worth the time and effort these people have put in to make these new features possible. And if you haven’t upgraded to V7R3 or preferably V7R4, while you’re technically on a supported release, none of these enhancements are provided on V7R2 and you’re missing out. Time to upgrade!