I certainly do not disagree with using the correct tool for the job. UDFs could be used for this function, though introducing UDFs does increase the amount of development work when legacy applications and databases are involved.
I do not agree however with restricting read triggers to only an audit capability.
Database may have viewed read triggers as initially providing an audit trail, but that should not preclude enhancements to allow improved functionality (updating the buffer in this case). And I certainly don't agree with precluding enhancements due to previous serviceability considerations.
If there was a high amount of CPS activity (with modified buffers related to update/insert triggers) that were identified as user defects then, to me at least, that indicates that the provided documentation was insufficient. One does not accidently fall into using and modifying the buffer provided to a trigger program. The user had to have done quite a bit of research into how a trigger should work. I don't know how many user problems were related to incorrect coding of update/insert trigger buffers, but the fact that the original example programs provided by IBM were coded incorrectly (not using the provided buffer offsets) undoubtedly had an influence on past CPS activity.
I also have a concern with restricting new function due to the expense required to identify an underlying problem (using ConsultLine in your example). This suggests to me that insufficient serviceability tools were provided to Level 2 in order to quickly determine root cause. As with insufficient (or incorrect) documentation, insufficent service tools should not be a reason for precluding further enhancements in any area of the system.
Providing sufficient documentation and serviceability should be built into the sizing for allowing read triggers to modify the data buffer. They should not be used to preclude allowing read triggers to modify the data buffer.
Bruce
http://www.brucevining.com/
Providing integrated solutions for the System i user community
CRPence <crp@xxxxxxxxxxxxxxxxxxxx> wrote:
A UDF [User Defined Function] is what is used to redefine output [to
a program] reading data from a database file. Use the correct tool for
the requirement.
The Read Trigger is used for auditing what was passed to the program
that issued the read request. If the Read Trigger could change the
data, then what was passed as data to the trigger for audit does not
match what was sent to the program; function defeated. Also IMO IBM
would almost have to refuse to ever investigate any problem where any
Read Trigger was involved [if ever changing the buffer were allowed],
except under a paid consultancy. Non-SQL trigger programs already were
costly, to the point where many inquiries as suspected defect were
effectively forced through ConsultLine before being /proven/ not to be a
usage error; in my experience over 95% were usage problems.
At least UDF enforces well-defined structure\typing whereas a read
trigger could rewrite the output from the following request to return "A
BUNCH OF GARBAGE" instead of "SIMPLE", either on purpose or by an error
in coding:
SELECT VARCHAR('SIMPLE') FROM SYSIBM.SYSDUMMY1
Regards, Chuck
midrange.com
