First, I want thank everyone for all the input.
Second, we have no controls over these object create processes, they are 3rd party product install/upgrade processes, and the same vendor will not do it consistently.
Sometimes they will restore directly from a savf, all original object detail is persevered.
Other times they will restore from a savf, but then use crtdupobj later in the process.
Third, of the 20+ software vendors we use, only one, besides IBM, uses Object level, Licpgm name, Licpgm level, PTF number, APAR.
Fourth, then we have our own add-on custom programs, which have our own totally different in-house rules.
Summarizing, because there is no consistently, there is no simple easy solution.
I still feel strongly that CRTDUPOBJ should keep original create date and user, this would solve many of the issues.
Do you think IBM would consider a DCR, maybe using a data area, or a new parameter on the command, to keep original create date and user?
For Duplicate file identifiers, I see the default is NO but IBM gave a YES option
It makes you wonder if IBM is rethinking how CRTDUPOBJ should perform.
*NO
The file level and member level identifiers of the existing database
file will not be used for the newly-created file. The file level
and member level identifiers for the newly-created file will be
generated by the system; for example, 1070224092922.
*YES
The file level and member level identifiers of the existing database
file will be used for the newly-created file. Having two database
files with the same file level and member level identifiers can
impact database operations. This value should only be used when an
exact duplicate database file is expected.
Paul
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, February 14, 2014 7:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: Checking object create dates
<snip>
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:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qlicobjd.htm>
</snip>
Hmm, I thought those attributes were not allowed by set by users. From the help:
The Program Temporary Fix that resulted in the creation of the displayed object. This field is blank for user-created objects.
Oh, but here's good news. On the APAR id.
The Change Object Description API, QLICOBJD, can change this field to any value. But also note: If this is a command and you run CHGCMDDFT it replaces this apar id with CHGDFT.
Ok, so that api does allows us to change some of these.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 02/14/2014 04:54 AM
Subject: Re: Checking object create dates
Sent by: midrange-l-bounces@xxxxxxxxxxxx
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
library.
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
any.
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:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qlicobjd.htm>
midrange.com
