On Fri, 2014-09-19 at 15:24 -0600, Nathan Andelin wrote:
I question doing stuff in triggers that are best left in constraints.
@Rob - The new Modernization Redbook has a section on Constraints, too. I
haven't delved into it, yet. But that's on the agenda ;-)
Actually I wonder, is it possible to create a "trigger/middle man" type
program that could monitor for generic "unable to update, RI error" that
was in the SQL subsystem (it would live one level up from the DB,
between that and the application) that could then find the real
reason(s) if *DIAG messages such as "LVEMSTDB/ODHDR record 1774 does not
exist" preceded it and then translate them (if possible) to meaningful
*DIAG messages, then push them (the original or new translated messages)
up one level along with the *ESCAPE (which could also be
translated/replaced) to either the application program, or into the ODBC
driver if a PC application... either way the more helpful messages could
then simply be "grabbed and displayed" by the program and/or if given
new message ID's be used to update the relevant on screen fields.
If only a single generic message exists, the above obviously isn't
possible except in so far as providing a more user friendly message, ID,
than the SQL/OS level, so the application has less work to perform which
has the added advantage of not needing to translate a single non user
friendly message in various places such as "green screen" and "pc"
programs.
Then again, that all falls down if such messages/SQLCI's/ODBC's are the
same no matter the vendor so if "OS/i" uses 2115 for referential error
and MSSQL also uses 2115 as an industry standard then changing things as
"a man in the middle" would tie you into SQL/i only.
@Matt - That discussion on Stack Overflow was a good read. It seems that
most of the "evils" of Triggers might be overcome by a bit of additional
generic plumbing such as the Trigger Mediator idea reference by John Voris.
@Buck - I will look into using QMHRCVPM to pull the "real" error message
from the Job Log.
Ever since I learned about that API and QMHSNDPM (we had just updated to
V2R3M0 from god knows what earlier version) some of my programs
subroutines were written in a similar style as API's in general with an
error code DS, and returning a "length of message data" greater than
zero to denote an error along with a message ID which could be tested,
immediately, and/or sent to the programs message queue.
White it made my programs bigger, it simplified the design where say a
test of a field could be done in a SR, and an error message ID returned,
and then if a display needed to turn on an indicator and show a message
subfile it could be done in the display handling section, not in the SR
which meant indicators could be re-used and were no longer "global" in
terms of their meaning; no longer did I have to remember *IN25 was
"invalid cust no" on screen 1,4 and 7 which also had the added advantage
of not needing to perform tricks such as making/overlaying/renaming
*IN25=field "CstInvld."
I guess I was also back then (1994) thinking about ILE, or if not ILE at
least way more modular, and writing my programs to be more
"Escape/Diagnostic message" driven as, I assumed, IBM did it. (my
biggest clue to that was program dumps and seeing CPF messages saying
"record X does not exist in file Y" or some such messages.)
@Booth - I tend to prefer having "applications" display error messages;
have the Trigger generate them.
When I have eventually ILE'd my program in to submission...
(its still OPM, wow the number of _subtle_ logic errors I've found is
high, but it worked because silly things like userB deleting a record
from under the "update screen" of userA didn't/couldn't happen due to
business processes... even though it was green screen, it was still
written to never lock any records until the update happened, and then to
lock in a cascading order with "headers" before "details" and so on.)
...I guess the next logical step would then be to SQL it, and at the
same time move the data validation totally out of the program/sub
procedure and into the DB, issuing *DIAG for all the errors, followed by
a generic "not updating record/s" *ESCAPE, and then to change the
application to grab the *diags one by one and condition the RI/PC of
fields depending on the message data contained within them.
Thanks,
Nathan.
Jon.
midrange.com
