Joined: 20 Oct 2006 Posts: 6968 Location: porcelain throne
you still have a problem because you complete unit-of-work
includes every db2 row effected by the msg on mq-1.
any commit you make will destroy the msg on mq1. and since you can only partially work the mq1 msg before committing the mq2 msg,
you need to save the mq1 msg (in a db2 table) as a restart parm when you commit.
that way you process the saved db2 row (with the msg) before you ever read mq1.
the last commit for a completely worked mq1 msg would be to update the db2 restart row as empty, forcing your processing logic to read mq1.
I have seen numerous posts in this forum with improper explanation and get the answers of the same quality.
And this is what makes me try to explain my question at the fullest I can.
Coming back to the query,
I had suggested the same answer to the senior folks about saving the MQ1 msg on a db2 table.
But as it happens at most times, seniors often like to choose the difficult/complex way and solution implemented was:
the message read from MQ1 is written back to the MQ1 on reaching the syncpoint limit which then re-triggers the same transaction/program and this goes on.
For eg: For 5000 records,
after 1000 MQPUTs, the message read from MQ1 is written back to MQ1. and transaction ends.
Now there are 4000 records waiting to be processed, The message is read again and the process continues until it finishes all records.