On 14-Feb-2014 07:30 -0800, Steinmetz, Paul wrote:
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 preserved. Other times
they will restore from a SAVF, but then use CRTDUPOBJ later in the

I am still at a loss what this topic is really all about... other than lamenting the inability of CRTDUPOBJ to do what is desired, specifically according to the requirements laid-out in the conversation. I really can not fathom what is being done with these 3rd-party objects.... I mean... aren't *they* responsible for ensuring that their upgrades and patches are delivered in a manner that is proper and consistent.?

After this post, I will return to just responding only to specifics and ignore what might be the overall topic\goal; lacking interest to ascertain what is necessary to fully understand.

Third, of the 20+ software vendors we use, only one, besides IBM,
uses Object level, Licpgm name, Licpgm level, PTF number, APAR.

Bummer. A decent packaging and delivery mechanism for a software provider to use, while providing consistency to their customers; i.e. rather than requiring customers to learn to deal with an additional means to upgrade\patch for each different sfw provider or even different for different packages from any one sfw provider :-(

Fourth, then we have our own add-on custom programs, which have our
own totally different in-house rules.

I would think these are the objects that need tracking.?

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.

Even if the command changed, its defaults would mimic the past implementation; anybody, any 3rd party could explicitly utilize the old-way, defeating any changed default. OS utilization of the internal interface to the CRTDUPOBJ feature would continue to operate unaffected, but IBM might [feel the need, to be safe] change existing CL code to explicitly add the new parameter with the old default; done blindly and notify anyone they can opt-in to the new setting, by backing out the change... which of course likely nobody would, because everything is already known\assumed to be functioning correctly.

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?

A data area would probably be too risky, per the change could impact unknown dependencies within the OS and LPP code [perhaps even or only] for their install processing. When installs [or run-time] are impacted by command default changes, although defects, the response for install is usually... "don't do that if it hurts" which basically means "reset changed defaults before the install to avoid potential problems." Installs are kind of sensitive that way... because a corrective requires repackaging the sfw.

Always a chance that a DCR would be accepted. But my guess is that the DCR would be answered as "function already available" stating that the Change Object Description (QLICOBJD) API exists to update the object and the Replace Command Exit Program (QCARPLCM) API [enhanced to have a *AFTER invocation] exists to effect the change for the usage of the CRTDUPOBJ command.

For Duplicate file identifiers, I see the default is NO but IBM gave
a YES option.

That implementation is required for compatibility; to avoid impacting existing code that depends on the effects remaining as they were. If the changed command default impacts user code that depends on the old effect, then no concern for IBM; i.e. that is a usage issue. IBM need only deal with their own code, and due diligence to inform the same should be done by other partner software providers; others notified by the MTU.

It makes you wonder if IBM is rethinking how CRTDUPOBJ should

As I understand, some CM software provider(s) [though possibly others] made a case for the value [to them] of the CRTDUPOBJ maintaining the database file level identifiers [without having to resort to save\restore to get the desired effect].

*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.

As I alluded in another reply, the File Level Identifier may continue to be updated\set-anew for non-database *FILE objects, irrespective the specification of FILEID(*YES). That is, I suggested the Duplicate File Identifiers (FILEID) was very possibly not extended to *device files*, and thus the same concern may still exist for those; e.g. a PRTF is one of the device file *FILE objects, and one mentioned initially in the thread. The above documentation snippet seems to imply that lack of support may very well reflect their [actual implementation, and if so, for a poorly executed] design change.

Return to Archive home page | Return to MIDRANGE.COM home page