Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Trigger feedback to Application Programs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Trigger feedback to Application Programs

    Don't trigger programs(by definition) occur/execute after the fact. The fact being add/update/delete? If that is the case, then should you be using referential integrity for editing so it occurs BEFORE the a/u/d? Just a thought. Bentley Pearson

  • #2
    Trigger feedback to Application Programs

    Bentley, trigger programs can be set to be called before or after the event. *BEFORE is normally used to decide whether or not the event should occur, or to change the value of the record that will be written/updated. *AFTER is normally used to do some followup processing. (Although, RI might be a better solution in this case - I don't know.) Robert, you could send a diagnostic message to the program causing the trigger to fire(*). If the trigger failed, the program could receive the message. Or you could have a data area with the same library/name as the file, and update the data area with the error information (both the trigger program and the I/O doing program should be able to figure out the actual library and name of the file, I think). (*) There are a few ways to figure out which program caused the trigger to fire. I think some programs have been posted (or are otherwise available), but I don't remember the details.

    Comment


    • #3
      Trigger feedback to Application Programs

      I tried using *DIAG as the Message Type but *ESCAPE is necessary if the trigger is going to signal the database to disallow the action. My trigger does send a message using QMHSNDPM API and I can see it in the job log. However when I try to receive the message in the program that initiated the write or update this message is never found. The only message I can see is the one the database module put out stating the trigger program encountered an unmonitored error which is useless to me. Is communication from a trigger back to the program really this cumbersome? Surely someone is using something better. If I use a dataarea then I won't know which message belongs to the calling program because many people can be doing updates and writes at the same time which triggers my trigger. Putting the calling program name and user profile in the dataarea record might solve this problem but once again it is very cumbersome to access this info from a trigger.

      Comment


      • #4
        Trigger feedback to Application Programs

        Robert, I was thinking of sending an additional *DIAG message directly to the I/O-doing program, but it also works if you send your *ESCAPE message directly to that program: I just hacked this up (very sloppy programs) and it worked. Here's my "trigger program" (it always fails). It avoids the problem of determining the name of the I/O program by hard-coding it, since it's just a proof-of-concept for the message thing. D sds D thispgm *proc D qmhsndpm pr extpgm('QMHSNDPM') D msgid 7a const D msgfile 20a const D msgdata 100a const D datalen 10i 0 const D msgtype 10a const D stackentry 10a const D stackoffset 10i 0 const D msgkey 4a const D errorCode 10i 0 D errCode S 10i 0 inz(0) * Send an escapemessage to the program doing the I/O C callp qmhsndpm ('CPF9898' C : 'QCPFMSG *LIBL' C : 'trigger fail' C : 12 C : '*ESCAPE' : 'TRIGIO' : 0 C : ' ' : errCode) C return Here's my "I/O" program called "TRIGIO": Ftrigfile uf e disk D rcv ds 500 D qmhrcvpm pr extpgm('QMHRCVPM') D msginfo 1000a options(*varsize) D infolen 10i 0 const D format 10a const D stackentry 26a const D stackoffset 10i 0 const D msgtype 10a const D msgkey 4a const D waitTime 10i 0 const D msgAction 10a const D errorCode 10i 0 D errcode s 10i 0 inz(0) C read rec C eval fld = 'new value' C update(e) rec C if %error C callp qmhrcvpm (rcv : %size(rcv) C : 'RCVM0100' : '*' : 0 C : '*ESCAPE' C : ' ' : 0 : '*SAME' : errcode) C endif C seton lr Here's what was in the qmhrcvm receiver, from the debugger: ....5...10...15...20...25...30...35...40...45...50 ...55...60 ' ñ ñ CPF989815 trigger fail'

        Comment


        • #5
          Trigger feedback to Application Programs

          Robert Fike wrote: > ... > Is communication from a trigger back to the program really this cumbersome? > ... Maybe there are more convenient ways of communicating from the trigger to the program, I don't know. I don't even know if it's a common (or good) practice for trigger programs to want to pass information back to their I/O programs. Maybe it is common, though; maybe that's the source of the frequent request for "what program caused my trigger to fire?".

          Comment


          • #6
            Trigger feedback to Application Programs

            Barbara said: I don't even know if it's a common (or good) practice for trigger programs to want to pass information back to their I/O programs. Maybe it is common, though; maybe that's the source of the frequent request for "what program caused my trigger to fire?". Ideally a trigger program should not need to know which program is updating the file. It should do its job, no matter whether the program writing to the file is batch or interactive, green-screen or client. Practically, however, it is sometimes good to know, especially when you are trying to figure out how bad data is getting into a file. But there are also other ways to find out such information, such as through reading a journal.

            Comment


            • #7
              Trigger feedback to Application Programs

              It is my understanding that it is good practice to put as much business logic int the database as reasonable possible so as to make the programs which use the database as simple as possible. It also does a better job of protecting the database since all programs which try to alter the database will be subject to the business rules in the database. By putting all the edits in one place and then putting them in the database itself via a trigger program we will prevent bad records from getting into the file. Trigger programs, to be of any benefit at all, must return to the calling program an indication of what specifically is wrong with the record. Otherwise the calling program doesn't have the slightest idea what is wrong or what to do about it. Constraints at least return a constraint name and don't have to traverse up a stack to figure out who to send the message to. It is impossible to write a mission critical system using contraints is I have to figure out which previous stack entry to send the escape message to. I cannot always depend on sending it to the 2nd or even 3rd entry because the database modules are between my trigger and my i/o program. Who's to say IBM won't change how these work in the future and add an additional stack entry at some future date. The people who have responded to my question so far are the ones whose opinions I highly respect. Based upond their answers I don't think triggersare going to work for my project because they are just to cumbersome when it comes to returning error info to the calling program. Also, from the lack of response to my question it seems that very few people use triggers at all. Thanks to everyone for their responses.

              Comment


              • #8
                Trigger feedback to Application Programs

                Do you know how to code an SQL trigger to prevent an insert/update. We are trying to stop update to a table based on conditional foreign key existence, which can't currently be performed via a check constraint due to the need to reference another table. Basically, do not allow insert/update to table A if A.1 is not found in table B (A.1 = B.1) with B.2 > 10.

                Comment


                • #9
                  Trigger feedback to Application Programs

                  I know all parameters to a trigger program are input only so communication back to the calling application program is not via any input parms. My trigger program is doing edits to determine if the record can be inserted or updated. I need to communicate back to the program a specific error code or message id. Can anyone tell what techniques they are using?

                  Comment


                  • #10
                    Trigger feedback to Application Programs

                    Robert, A trigger program can easily perform edits, reject the request and generate an escape message. Of course, it is up to the requester to handle the error condition. I have attached some example code. Mark

                    DB008R.rpg

                    Comment

                    Working...
                    X