I see no reason for the CIUPDATE to behave any different than DBDELETE/DBPUT.
Regardless of how CSY implements the necessary logic/code, the fact is the sort
and extended fields must always be consistent with the original concepts and
beliefs of what it is trying simplify.
Maybe I am wrong, but CIUPDATE was developed to allow the universal modification
of items and/or fields. If the said modification involved critical items and/or
fields, then they would be modified using the rules in place for the
DBDELETE/DBPUT sequence. It seems when this ability was added, CSY forgot to
check their own rule book concerning sort items and/or extended fields and what
procedures must be followed when creating them.
I have come across many programs written by vendors and consultants which have
exploited a defect in HP or vendor software, only to have it bite back when the
defect gets corrected. I will never exploit a deficiency in any application or
software, although I do believe in working around a defect whenever possible. It
seems that some people are worried that if CSY were to enhance (fix) the CIUPDATE
logic, their applications may no longer function (now might be a good time to
hire a qualified consultant). If CSY were to correct the behavior of CIUPDATE
then we should rejoice in the fact that it may just be the last thing that CSY
does.
The way it stands now, we are all talking about it; and it seems we could keep
talking about it until CSY tells us the lab is CLOSED or plainly no longer
cares. A missed opportunity, is an opportunity which never re-occurs.
The need for this option is for backward compatibility, and therefore the default
for the CIUPDATE flag should be off. The developer must be in control of the
program, and if s/he needs the features of this option, then the option can be
switched on. Otherwise, if the option is on by default, the developer could
inadvertently destroy the original intent of the database structure. A database
tool like ADAGER, DBGENERAL or others (sorry if I don't list them all) will be
able to over-ride any option set at the DBUTIL level by its use of PRIV mode. If
a vendor application requires that the option to be on, it will be the
responsibility of the vendor to explain to their customer why and to get them to
agree...........Would anyone like a vendor application to be using PRIV mode
without you knowing about it.
~~~~~~~~~~
So lets agree to settle this by proposing to CSY the following (without
exceptions):
The default setting for CIUPDATE is off or unassigned.
CIUPDATE flag off:
No updates allowed if any sort item or extended field is changed.
CIUPDATE flag on:
The behavior of the CIUPDATE should be exactly like a DBDELETE/DBPUT of the
record. Let the process
go through all the motions and let us now when it is done. Behind the scenes,
all the sort items and extended fields must be checked and validated; and if a
critical item and/or extended field is altered, it must be placed in the
appropriate location in the chains (sort or otherwise).
Olav Kappert
IOMIT International (HP Application Development Specialist - Consultant)
http://www.IOMIT.UnitedStates.com
Wirt Atmar wrote:
> There's nothing tricky about it. The sole complaint has been so far that
> CIUPDATE doesn't honor "extended sorts" in the same manner as does the
> DBGET/DBDELETE/DBPUT sequence. That is an easy complaint to correct.
>
> Nor is there any reason to have any sort of flag with CIUPDATE turned
> permanently on (or at least on by default). Unless the user is somehow
> philosophically depending on the current CIUPDATE or DBUPDATE procedures to
> intentionally screw up his extended sorts, installing newly corrected
> procedures that honor those extended sorts cannot possibly do him any harm.
>
> Wirt Atmar
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
