× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Commit in Trigger process
  • From: "Weatherly, Howard" <hweatherly@xxxxxxxxxxxx>
  • Date: Thu, 14 Sep 2000 09:06:00 -0400

Title: RE: Commit in Trigger process

Maybe I misstated, the commit is in the a program that the trigger calls, the only function of the trigger is to initiate an update processes. Basically here is what is happening, we run DpropR between the mainframe and the AS400. The tables are updated on the mainframe and propagated to the AS400. Since we can not propagate the other way because it would be like a dog chasing its tail and never quite catching it we decided  to update on the 400 side and use DRDA to update the mainframe. The 400 has 2 collections, one for the propagated tables and one for native tables, the native tables are the drivers to update the mainframe which will be reflected in the propagated tables on the 400. One table contains simple rows that have a code and some dates in it, this row is add when a 400 process updates the native tables. We have an insert trigger on this table. The trigger receives the code in the trigger buffer and decides which process needs to be done on the mainframe and calls the necessary program.

Now in that context the program that inserts the row into the table that causes the trigger has done some other updates on the 400, should that program commit before inserting to the table that will cause the trigger or should it issue a commit/rollback after that insert? or should/would  the called program from the trigger be responsible for the upstream commit.

My opinion is that as soon as the program that initiated the trigger ends,. the commit is going to be done by the system and if it did do a rollback, it should be done only upon discovering that the insert to the table that will cause the trigger fails, that way the trigger will not occur, or will it?

In any case yes the called DRDA program will be using two phase commit as it also must update 400 tables but its primary mission is to update the tables on the mainframe that will be/are propagated.

-----Original Message-----
From: Pete Hall [mailto:pbhall@execpc.com]
Sent: Tuesday, September 12, 2000 08:09 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Commit in Trigger process


At 10:37 09/12/2000 , Howard Weatherly wrote:

>We have a process that updates files on the AS/400 and when completed
>inserts a row into a table that initiates a trigger. The trigger program
>calls a DRDA program that synchronizes the mainframe data with the AS/400.
>
>My question are:
>When should the program on the AS/400 issue a commit? before inserting to
>the trigger table or after?
>Should the trigger program issue a commit to ensure that all upstream
>processing is cleaned up?
Trigger programs are not intended to execute commit or rollback. I think it
might even be invalid to issue a commit in a trigger, but I'm not certain.
The intent is that a trigger should adopt the same commit level as the
initiating process. That process is responsible for committing changes. I
don't know how that fits in with DRDA though. Does it handle two phase commits?


Pete Hall
pbhall@execpc.com
http://www.execpc.com/~pbhall/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.