On 13-Feb-2014 12:30 -0800, Steinmetz, Paul wrote:
I'm working on a utility to find objects that exist in a
custom/emergency fix library that would have a create date *LT the
create date of the object in the standard library, thus sign of an
issue. Utility done, working.
However, I found a scenario where we received a new object (*prtf)
for an upgrade. Because we change some print attributes on a few of
these, we place a copy of these prtf file objects in the fix
The upgrade is done, replacing the objects in the standard library.
Here's the issue.
The prtf object in the fix library was created with crtdupobj, prior
to the upgrade being done.
Creation date/time . . . . . . . . . : 08/15/11 10:41:44
The prtf object in the standard library has a create date for the
day of the upgrade.
Creation date/time . . . . . . . . . : 08/28/11 10:49:35
The objects are valid, but being flagged because of the create date
issue. I'm looking for some other field on the object, not finding
Many of our upgrade processes do this. The upgrade process does a
CRTDUPOBJ, thus the object loses its original info, (create date,
created by user)
I had not previously responded to this message, the OP, because I did
not understand the scenario. I still do not understand, so perhaps the
following is not germane, but I offer anyhow as a SWAG with regard to
handling upgraded objects:
If the objects could be assigned an Object Control Level, an APAR or
PTF identifier, or some other value that defines what is the specific
object [beyond its name], would that assist to know that the duplicated
object was a copy of the original? Even without actually delivering
objects via a product and PTFs, the PTF\APAR details and product
information can be set for an object. The object control level also can
be assigned, having no relation to product and\or PTF/APAR activity.
These attributes are available to be set using the Change Object
Description (QLICOBJD) API: