5
votes

I am having problems testing the MQSC Adapter in BizTalk to communicate with a Queue on Z/OS Host.

The test senario: While sending messages though Biztalk I (Force)stop and start the Host channel, to mimic a HOST IPL.

In this scenario I experienced the following outcomes:

Sometimes there are messages left uncomitted on the Host MQ. Even after the channel are started again. This way I don't know if the messages have been processed by Biztalk.
Question Is there a way to make sure that messages are always committed on the Host MQ or still available on the MQ if not committed

Once I experienced duplicate messages and once that messages was lost Since these things happened only once each. I hope to find problems in my test applications / procedure.
Not really a question, but if others have experienced the same errors I would like to know.

The test Setup

  • Biztalk 2009 on 2 nodes
  • WebSphere MQ client 7.5.0.2 (Transactions supported)
  • MSDTC - XA Transactions are enabled (Edited to reflect comments)
  • MS Biztalk Adapters for Host Systems 2.0 MS Biztalk Adapters for Host Systems 2.0

Port Configuration
Receive Location
Receive Location

Send Port
Send Port

1
FWIW we used non-transactional 7.0.1 without issue on a 2 node BTS2009 group to an AIX MQ Host. Just to check, have you enabled XA support on MSDTC?StuartLC
Thanks for the comment StuartLC: Yes we have enabled XA Transactions on MSTDC.Jorn

1 Answers

1
votes

If you are using MQ transactions, that is just MQPMO_SYNCPOINT and MQCMIT, then the disconnection (either explicitly or implicitly due to STOP CHANNEL(chl-name) MODE(FORCE)) will cause any outstanding transaction to be completed (committed on an explicit disconnection, rolled-back on an implicit one).

If you are using 2-PC transactions with a Transaction Manager (TM), then the transaction will need to be dealt with by the TM, depending on how far through it is, is it prepared already for example.