On Tue, 2014-09-23 at 12:23 -0400, rob@xxxxxxxxx wrote:
<snip>
When it comes to feedback from a business logic trigger to say, JDBC,
how will the ILE public data structure export help?
--buck
</snip>
Good point.
When you use a constraint, and you give it a decent name (unlike the
default I used below) and you get a constraint error you will get a
message like this in iNav's Run SQL scripts
INSERT INTO rob.nathan (mydata) VALUES('A')
SQL State: 23513
Vendor Code: -545
Message: [SQL0545] INSERT, UPDATE, or MERGE not allowed by CHECK
constraint. Cause . . . . . : The value being inserted or updated does
not meet the criteria of CHECK constraint Q_ROB_NATHAN_MYDATA_00001. The
operation is not allowed. Recovery . . . : Change the values being
inserted or updated so that the CHECK constraint is met. Otherwise, drop
the CHECK constraint Q_ROB_NATHAN_MYDATA_00001.
If "CHECK" is part of the message data (not the "sender") then a
mediator would just need to grab the message and forward it on up the
stack.
In fact having just checked now, QMHMOVPM will allow a message(s) to be
moved up the stack as if the sender was the original sender, not
replacing the sender with the current stack entry.
QMHRSNEM can also be used just to forward a message but replaces the
program name info with its own, I think?
I'm not strictly sure, but I think it leaves the original message
intact. (I know I've seen some messages denoted as "Sender
copy" (CPF5029 data mapping error) from QDBSIGEX to QDBSIGEX. So even if
the above doesn't do it, some API or IBM program is doing something,
forwarding it, and marking a message as "sender copy."
Obviously every program in the stack (bar IBM/SQL/i ones, right down in
the bowels sending typically cryptic messages) needs to be written to
"deal/ignore" and "forward/replace" if its all going to hang together.
While it seems a lot of work, I guess with ILE most of the grunt could
be put into a set of procedures...
Get escape > I'll deal and forward or > sod this shove it all up the
stack.
As to whats done, or even if some messages can be handled (ie, *diags
through ODBC/JDBC as well as exceptions, or only the "can't be done"
*ESCAPE/*NOTIFY) thats down to the application.
I can see green screen can be adapted, eg. Grab the CPD(F)5029's *DIAGs
and condition the screen indicator based on the message data which
contains the field name. (although much better to test the dates are
valid in the first place *BLUSH)
Older programs may just bottle it... either a function check as no error
indicator on the write/update, or make some assumption such as the "oh
it must be a dupkey," although that doesn't always hold up as the UNIQUE
might be in multiple logical files not just the one being updated, or
just issue an "I'm stumped not happening" message along with the cryptic
IBM ones already in the PGMQ.
Jon
midrange.com
