Scanning QSYSOPR for Selected System Messages
May 11, 2005 Joe Hertvik
In your article “Bullet-Proofing User Profiles,” you talk about scanning the QSYSOPR message queue. Is there a way to scan for selected system messages, such as failed sign-on attempts, or do you have to review your logs line by line? I suspect that I have a user who is deliberately disabling user profiles by typing in a garbage password three times in a row, but I can’t prove this is happening. Do you have any ideas?
The simplest way to do this is to scan the system history log for message CPF2234, which tells you when a user tries to sign on with an invalid password. You can do this by entering the following Display Log command (DSPLOG) from a green-screen command line or from the command line utility in iSeries Navigator:
DSPLOG displays the System History log for your partition. The system log is an OS/400 message queue (object type *MSGQ) that contains a summary of different system activities, including system and job information, failed sign-on attempts, and other system messages. Running DSPLOG this way tells your system to filter the system log information so that you only see incorrect password attempts that are designated by message ID CPF2234, which is issued to the log every time a user tries to log on with an incorrect password. Message ID CPF2234 has the following format:
Password from device & 1 not correct for user & 2
In this message, the second listed parameter (&2) displays the name of the user who is trying to sign on to the system and the first parameter (&1) displays the workstation device that they are signing on from. This information should provide enough evidence to pinpoint when and where your invalid sign-ons are happening.
By default, DSPLOG returns the requested information back to your display. You can also run the command to produce a printout of this information by entering it this way:
DSPLOG LOG(QHST) OUTPUT(*PRINT) MSGID(CPF2234)
The Output option (OUTPUT) can be set to provide more detailed printouts. By setting OUTPUT to *PRTWRP, each output line will be wrapped if its text does not fit on one line. Setting OUTPUT to *PRTSECLVL prints out both the first and second level text for the message, if that additional text is present. Unfortunately, IBM does not provide the option to send the output to a database file, which would come in handy for setting up a program to automate system log monitoring (although I believe there are vendors who offer this capability).
DSPLOG also has options to display system log messages for a certain time period or for specific jobs. The option to display job messages is not as handy as you might like because you have to enter the specific job name, user name, and job number of each job you want to display messages for. IBM does not allow you to generically specify that you want to see all the messages for a particular user, which is unfortunate.
Finally, if you just want to turn off the filtering and display all of today’s current messages, you can just run DSPLOG with its default parameters, like this: