View previous topic :: View next topic
|
Author |
Message |
Haresh
New User
Joined: 04 Jan 2009 Posts: 18 Location: Germany
|
|
|
|
Hello,
can anyone please tell me is there a way to start a cobol program whenever a commit occurs in a DB2 table?
Thanks in advance |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
What does "start a cobol program" mean for your question?
Depending on exactly what you are trying to accomplish, there are different answers. |
|
Back to top |
|
|
Haresh
New User
Joined: 04 Jan 2009 Posts: 18 Location: Germany
|
|
|
|
my goal is to execute a cobol program automatically whenever a commit occurs in a DB2 table. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Well, this is just a repeat of the original post. . .
You need to explain (in detail) what you want to accomplish. "Start a cobol program" tells nothing.
Where are you going to start this program? How should it communicate back to the process that "started" it? What if it fails? |
|
Back to top |
|
|
Haresh
New User
Joined: 04 Jan 2009 Posts: 18 Location: Germany
|
|
|
|
Hello,
the cobol program and the db2 table are in the same LPAR. it is not required to communicate back to the process that has started this cobol program.
The error occurs in the cobol program will be handled via logging mechanism (log the error details in a file/table and read it later).
The error handling at the start process can be defined only if i know the process which is going to start the cobol program.
All these steps will not affect the source data since the complete process is after the commit of the source data.
please note that i havent done many posts, so i am still now sure how to use right words to explain my need. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
warum muß Du sofort zugriff auf die Tabelle nach ein COMMIT.
Es macht keinen Sinn.
Hat es zu tun mit 'logging' oder 'duplexing transactions' oder 'mirror image trickle-down'.
You will receive little help
until you reveal the reason for 'starting a process (cobol program) after a commit.
Most triggering mechanisms supported by DB2 are based on the actual INSERT/UPDATE/DELETE of a row for a 'specific' table.
Notification of a successful COMMIT is the sole responsibility for the task causing the COMMIT. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
so i am still now sure how to use right words to explain my need. |
Possibly the biggest challange we have here at the forum is communication/language.
Maybe it will help if you explain why someone believes you need to do this (either "this" way or as mentioned in your other, similar topic).
My guess is that there are alternatives as i don't recall this ever being a requirement . . . We can offer suggestions only when we understand clearly what is intended. |
|
Back to top |
|
|
Haresh
New User
Joined: 04 Jan 2009 Posts: 18 Location: Germany
|
|
|
|
Hi,
sorry for not giving you guys the full picture. Below i have tried to give the full details and this is the reason why i have raised two similar topic.
Existing Funtionality:
- we have a DB2 table which is used by many applications, so the data are inserted/updated/deleted through various programs.
- we are replicating the data from this db2 table to an oracle database that resides in solaris system. This is done via db2 triggers -> stored procedure -> MQ -> Webservices -> Oracle database
- for each insert/update/delete the db2 triggers will call the SP and replicate
- the replication is done in near time
New Requirement:
- the data changes happen within a single unit of work for the same customer should be grouped together and should be replicated in single call.
For example within a unit of work there can be an couple of inserts, updates and deletes for single customer. The previous logic will do the replication for each data changes, but now all these changes should be captured and replicated in single call.
Solutions we have in mind:
- the first post from me is to check whether we can make the db2 triggers to work after commit. its clear that this is not possible
- next solution is the DB2 propagator which replicates to a local table after the commit, but its not cost effective for us.
- next one is that instead of calling stored procedure from triggers, insert all the resultant of triggers in an intermediate DB2 table.
By this all the changes are inserted only after the commit in the current unit of work (i already tested this).
The next problem is to replicate from the intermediate table to the oracle database in near time. For this one solution is to schedule a batch job for every 10 mins which reads the intermediate table and replicate.
I wanted to do some automatic process to start the replication, instead of scheduling the batch job for every 10 mins. Thats the reason i asked whether a db2 commit can trigger the execution of cobol program.
If you have any idea to do automatic process instead of batch scheduling, it would be very much helpful |
|
Back to top |
|
|
|