Troubleshooting
Problem
This document specifies the actions that cause the "Change Date/Time" field on the DSPOBJD display to be updated.
Resolving The Problem
The following options cause the Change Date/Time field on the DSPOBJD display to be updated:
The following options are specific to *LIB objects and cause the Change Date/Time field on the DSPOBJD display to be updated:
The following options are specific to *PGM objects and cause the Change Date/Time field on the DSPOBJD display to be updated:
| o | CHGOBJAUD |
| o | CHGOBJD |
| o | CHGOBJOWN |
| o | CHGOBJPGP |
| o |
EDTOBJAUT (when authority to *PUBLIC, owner, or primary group is changed)
|
|
o
|
GRTOBJAUT (when authority to *PUBLIC, owner, or primary group is changed)
|
|
o
|
RVKOBJAUT (when authority to *PUBLIC, owner, or primary group is changed) |
| o | MOVOBJ |
| o | RNMOBJ |
| o | Restore operations |
The following options are specific to *LIB objects and cause the Change Date/Time field on the DSPOBJD display to be updated:
| o | Re-creating an object into the library |
| o | Renaming an object in the library |
| o | Moving an object from/to the library |
| o |
Deleting an object in the library
|
| o | Changing the library with the CHGOBJD, CHGLIB, CHGOBJAUD, CHGOBJOWN, CHGOBJPGP cmds |
| o | Saving a database file in the library, this includes SAVLIB, SAVOBJ, SAVCHGOBJ, or anything that saves a DB file. |
The following options are specific to *PGM objects and cause the Change Date/Time field on the DSPOBJD display to be updated:
| o | Compressing or decompressing a *PGM object with the CPROBJ or DCPOBJ commands. |
| o | Using CHGPGM, except when message CPC0541- No change required is received. |
| o | Using UPDPGM. This is applicable only to ILE programs. |
For releases R540 and up, the system no longer causes the Change Date/Time field on the DSPOBJD display to be updated when the system is extending/changing the primary associated space of program objects.
For releases R530 and older, refer to APAR SE18894 for additional information for SQL program objects. The APAR states the following:
ERROR DESCRIPTION:
Change Date/Time of SQLRPG and RPGLE programs will change on the first run of the program. RPG and RPGLE program Change Date/Time entries are only modified if there is embedded SQL. RPG and RPGLE programs without SQL will only modify the Change Date/Time when the program is recompiled. The change occurs regardless of the users authority to the program object.
COMMENTS:
Everything is working as designed.
The space being changed is the associated space used by the database to store access plans. When this space is extended to create more room for the new access plans, it causes the CHANGE time stamp to be updated.
From talking to the security team and skimming the information in the Security Reference guide Appendix E, there is not a requirement to audit this activity.
For the question on allowing the program to be changed by an unauthorized user, it will be argued that the user is not changing the program. It is the system that is changing the program for the system's own use.
For releases R530 and older, refer to APAR SE18894 for additional information for SQL program objects. The APAR states the following:
ERROR DESCRIPTION:
Change Date/Time of SQLRPG and RPGLE programs will change on the first run of the program. RPG and RPGLE program Change Date/Time entries are only modified if there is embedded SQL. RPG and RPGLE programs without SQL will only modify the Change Date/Time when the program is recompiled. The change occurs regardless of the users authority to the program object.
COMMENTS:
Everything is working as designed.
The space being changed is the associated space used by the database to store access plans. When this space is extended to create more room for the new access plans, it causes the CHANGE time stamp to be updated.
From talking to the security team and skimming the information in the Security Reference guide Appendix E, there is not a requirement to audit this activity.
For the question on allowing the program to be changed by an unauthorized user, it will be argued that the user is not changing the program. It is the system that is changing the program for the system's own use.
Why would the SAVCHGOBJ command work differently for programs vs. files?
Are the files being journaled? Journaled objects are generally not saved with SAVCHGOBJ unless OBJJRN(*YES) is specified.
Are the files being journaled? Journaled objects are generally not saved with SAVCHGOBJ unless OBJJRN(*YES) is specified.
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHjAAM","label":"Job and Work Management"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
428211414
Was this topic helpful?
Document Information
More support for:
IBM i
Component:
Job and Work Management
Software version:
All Versions
Operating system(s):
IBM i
Document number:
637237
Modified date:
03 October 2024
UID
nas8N1014753
Manage My Notification Subscriptions