Current depth reflects "in tran" MQPUT's but not "in tran" MQGET's.
Having a currdepth of 38, while having an open input cout of 170 (the number of clients) suggests one of several possibilities:
- The messages are part of an incomplete batch being sent over an MQ message channel.
- The clients could be polling for messages, rather than sitting in an MQGET with MQGMO_WAIT
- The responding application could be batching responses (note the responding APP rather than the requesting app)
The first case might be caused by a slow network (how big are the response messages), an MQ performance issue at the responding QM, or might indicate the use of BATCHINT on the channel sending the replies.
The second case would be a "simple" programming error in the client receiving the responses. How does the client receive the responses from both SATRANS_REF_RESP and SATRANS_STATS_RESP concurrently ?
The last case is the same as Morag's response, just clarifying that batching at the responding app rather than the requesting app that would cause these symptoms.
You should be able to identify if any of the above are occurring by looking at the status of the various MQ objects in more detail. For example the respnse queue status would show you how many of the 38 messages are currently in a transaction (and therefore currently unavailable to MQGET's). The channel status substate should show you if the sending end of the channel on which the response is flowing is waiting on the network, etc etc.
------------------------------
Andrew Hickson
------------------------------
Original Message:
Sent: Thu October 19, 2023 03:55 PM
From: Ernest itebogeng Matjane
Subject: MQ intermittent
Hi,
Please help or suggest what we can do we getting intermittent messages on our MQ and also our client MQ,
Background
Client user sign on and send a message to our MQ, Client MQ must send receive a verification code back.
It seems for them that we send in batch, so they get all the messages at once. It also seems the response is also in batch. So, nothing is happening and then all of a sudden, a lot of messages hung on the output count XMIT queue which is our outgoing queue.
Please see the screen print
Queues from our client MQ.
SATRANS_REF_RESP - The remote queue sends a response/message to SOCPEN that contains the challenge code.
SATRANS_STATS_RESP - The remote queue sends a response/message to SOCPEN that contains transaction status information after the user approves the transaction on the NRP web application.
Messages will lands in the SATRANS_REF_RESP because of the time waits from application which is 60sec
The network team says there is nothing wrong on the network. see the screen print below
------------------------------
Ernest itebogeng Matjane
z/OS and MQ Junior system programmer
State Information Technology Agency
Pretoria
------------------------------