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
process.
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
perform.
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.
midrange.com
