Relationship of object Change Date/Time to audit records

Reports written to detect changes to programs, or other objects, are sometimes based on the Change Date/Time field of the object instead of information in the security audit journal. The following list describes reasons why there might be a difference between the date on the object and the date on the source for the object.

  • The CHGPGM command is used to force program re-creation to update the Change Date/Time field of the program. This operation writes a ZC (Change to Object) audit record.
  • The Sign Object (QYDOSGNO) API is used to digitally sign a program or command to update the Change Date/Time field for the program or command. This operation writes a ZC audit record.
  • When a device file is opened for update, a ZC audit record is written for the device file. For example, tape device files are opened for update during a save, display device files are opened for update when an application sends and receives data to/from a display device, printer files are opened for update when printed output is produced. In each of these cases, and similar instances involving other types of device files, a ZC audit record is written if auditing is on and the device file (*FILE object) is being audited. However, since no actual modification to the device file object is being done by the operating system during the I/O operation, the object change date is not updated on the *FILE object even though a ZC audit record is written.
The operating system will update the object change date for many reasons such as:
  • When a user profile has private authority to an object, and that object is then deleted, the system updates the Change Date/Time field of that user profile as it removes that private authority.
  • If security auditing is on when the object is deleted, a DO (Delete Operation) audit record is written for the deleted object.
  • Because the system automatically updates every user profile that has private authority to the deleted object, no audit records are written for those user profiles, even though their Change Date/Time fields are updated.
  • When internal updates are made to the object at runtime. These could include runtime statistics, object conversion, extending the size of an object during use in order to hold additional information, etc. These types of object updates will normally not result in a security audit record being sent to the QAUDJRN audit journal.

To track when your users have used normal system interfaces to change objects, use the security auditing journal. Reports to detect changes to objects that are based solely on the Change Date/Time field of an object can only produce partial results.

Why you should not use the Date/Time field for general security auditing

The main guideline used to decide what to audit for IBM i is to audit the security-relevant actions of users. The second guideline is to not write audit records for operations that the operating system automatically performs. In some cases, those automatic operations might be audited if the operating system performs the operation by using a function that is also designed to be used by users.

The objectives for maintaining the Change Date/Time field of an object are different from the audit objectives. The main purpose of the Change Date/Time field is to indicate when an object is changed. An updated Change Date/Time field does not indicate what was changed for the object or who made the change. One of the main uses of this field is to indicate that the object should be saved by the Save Changed Objects (SAVCHGOBJ) command. The SAVCHGOBJ command does not need to know when the last change was made, only that the object was changed since it was last saved. This feature allows performance to be optimized for database files. The Change Date/Time field is updated only the first time the file is changed after it was last saved. Performance can be affected if the Change Date/Time field was updated each time a record in the file was updated, added, or deleted.