Hi,
SVRCONNS don't have to be single phase commit. They support XA (i.e. two phase coordinated transactions) too.
Regardless of that, sending messages to a queue manager via a single phase commit (i.e queue manager coordinated SVRCONN) shouldn't cause issues if they are going to be consumed by an application which gets them under a CICS transaction (or any other type). There are two transactions here: one that gets the message on the queue, and the other that gets it off. The two transactions are unrelated and you can mix and match as you require.
It is however correct that once you application sends a message into MQ something bad might happen to it (i.e. the backend processing application might fail to process it for some reason, or the message might get sent to a DLQ somewhere) and the sending application won't know. But that's what happens with asynchronous messaging. And if the sending application is expecting a response, and doesn't get one, it should retry, make use of message expiry etc.
In this specific case where the CICS application fails, the application could be written to send a reply message indicating that something has failed and the caller should retry again, potentially after correcting the data it originally sent.
Regards, Matt.
------------------------------
MATTHEW LEMING
------------------------------
Original Message:
Sent: Tue September 20, 2022 07:06 AM
From: JAMES Nadziejko
Subject: Can we count the number of messages processed by Local Queue in MQ
Hi Prathyusha, good day. Just noticed your post and thought I might offer my two cents.
First and foremost the connection you mentioned that you are using is a SVRCONN connection. If you are connected to a zOS platform, then read on as my background and point of view is zOS based.
You did not mention how you are getting a count on the other side of the channel, Do the messages flow downstream to a QLOCAL on zOS and is the consumer application a CICS based application, or Batch job?
If these are all correct presumptions then consider this:
SVRCONN connections are single phase commit. This means that for each message you transmit over a SVRCONN if the other side is a two phase commit model, you may lose messages during transport to the mainframe application. For the case of a CICS based task if that task transfers control or links to another program in CICS or starts out in a CICS application owning region and does data extracts from a data owning or file owning region, there is an implied checkpoint (the second phase). SVRCONN's are not structured to handle this (phase ii commit), so to continue to use this CICS task as an example, if the second phase of the COBOL application tries to insert data into a file, data table, or data base and gets a non-zero return code from the api of the subsystem it is in, your client side application will never see this and the message will be lost if the source code does not manage the COBOL buffer internally. If the mainframe application just takes your message and processes it and if in that process there is a failure of any sort, (file out of space is just one of many potential faults, I have seen new users who do not have the proper RACF authorization also get their request failed),,,,then your client side (SPLUNK..etc..) is blind to this.
You can dig about on the server side and if you are running the newest and best versions of MQ on zOS or your client side then MQ creates SMF115 116 records and you can capture the date and time via established SMF reports and put them in table form. There are some vendor tools like SAS (Moreno and Associates) that interpret this data as well as the sample code that comes with MQ for zOS that may assist you. When you extract the SMF data you can do it by "Julian" Date and System time as well however take care here as the sheer volume of data can cause you more problems as you try to understand your situation.
Finally if you know when you are losing data you can look at the MQ JES2 logs for the MQ MSTR started task and it's CHIN and you may also find Data format related failures. Check too that the MQ you connect to has a default DLQ defined in the QMGR attribute field and well and the default XMITQ and browse those queues for your missed content. If your client is routing the message thru an intermediate broker and the message is being edited there that is another place to check to see if what you sent was really what was processed ,(or failed to process as well). I have seen mal-formed message headers that cause messages to just vanish although this is rare.
Get you detective gear and begin your adventure. Once a message is deposited in a mainframe environment the subsystems there can pass and route your message to a myriad of subsystems that all have dependent API's that may not be able to process or have logic that communicates the failure it sees due to this two-phase commit model.
Changing the connection from a SVRCONN to a SENDER/RECEIVER channel pair is more robust and will allow you to see on the sending side more two phase commit failures but your client will have to connect to a Queue manager on your distributed system (AIX,Windows,Linux)....and of course if serving application should have logic that "knows" in advance the message it received is from a SVRCONN connection and the buffer handling in any error process should adjust for this two phase limitation.
Hope this gives you some idea and help. If your receiving side is not zOS and the processing application is not a CICS COBOL transaction then your mileage will vary and this response will not be of much help.
Cheers and good luck.
------------------------------
JAMES Nadziejko
Original Message:
Sent: Mon September 19, 2022 12:16 PM
From: Prathyusha Yedupati
Subject: Can we count the number of messages processed by Local Queue in MQ
Hi Everyone,
Is there a way we can count the number of messages processed by local queue at MQ layer, to identify the historical data. I know we can do this using Splunk/Dynatrace. Because we have an application that is connecting using SVRCONN channel to MQ and placing the messages and which in turn MQ forwards those message to downstream application. We wanted to monitor the Queue count that is been processed, sender app count that is sending is not in sync with Destination app, and where MQ is been a middleware part in routing the messages. Can we write any scripts to monitor that at MQ layer? Trying to see if I can find any sample scripts
Thanks,
Prathyusha
------------------------------
Prathyusha Yedupati
Software Lead
------------------------------