In favour of our CICS-applications accessing IDMS and MQ, we want to set up two-phase commit.
Does anyone has done this in the past, and is willing to share some experiences and guidelines ?
The topics I'm curious about are :
Thanks in advance.
Best regards, Frank.
We are not using IDMS in a Two-phase commit environment yet, but we are also asking the same questions. before I posted on the IDMS community, I searched and found this question.
(Did you have any replies frank?)
Has anyone made any progress on 2-phase commit?
Does anyone want to discuss any Gotchas or issues or problems to look for?
Several issues we are worried about are:
How do we cater for DBA processes: Journal recovery, in flight backups, journal auditing?
What happens when transactions are committed, but held "in-doubt".
Does the transaction runtimes become extended?
Unfortunately I never got any replies on my questions, so I opened a case at CA support. Together with Yves Anthoons of CA, we did a lot of tests concerning parameter settings and their results.
I suppose you're also going to setup an IDMS-CICS 2-phase commit ?
In the meantime all is in place to have 2PC at our side, from an infrastructure point of view. CICS-Applciations will "soon" - the comming months - make use of two phase commit to commit the CICS UOW that accesses IDMS, MQ and/or DB2.
I'm finalizing our own documentation about 2PC, containing the theory, but also how we did the setup, and some CICS information too . If I can/may, I'm willing to join this information with you.
Thanks for your reply.
We are currently looking at an external XA transaction manager to support our 2-phase-commit architecture using JDBC to update IDMS as part of a wider distributed transaction. But, when using CICS, I am thinking there will be similar considerations for existing IDMS systems.
Any additional information would be useful.