How can I trace what or who changed the QAUDCTL value from *OBJAUD *AUDLVL *NOQTEMP to *NONE? This has happened several times in the past few months. In this case I suspect something happened during an IPL. A previous time I think it was an issued command. The journal stops recording when the command is issued.
QAUDCTL is the on/off "switch" for auditing. The system itself will turn it off if it can't send an audit journal entry. If the system can't send a journal entry it will set QAUDCTL to *NONE and send the message CPI2283 to QSYSOPR. This happens when the journal receiver attached to QAUDJRN is full and hasn't been configured to auto-generate a new receiver. If a person is actually changing the system value, an SV (system value) entry should be sent to the audit journal before the system value is changed. My guess though, is that this is a journal receiver issue.
MORE INFORMATION ON THIS TOPIC
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Check out this Search400.com Featured Topic: Top ten security tips
Dig Deeper on iSeries ILE programming
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
Look in the audit journal (QAUDJRN) on the AS/400 for an authority failure message with the name of the library as the object name. Use the ... Continue Reading
The UPPWEI field corresponds to the password expiration interval field, and its values "0" and "-1" represent the *SYSVAL and *NOXMAX commands. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.