Again, I would encourage you to look in the Dead-Letter Header written on the front of the messages placed on the Dead-Letter Queue. Two of the fields in that header are:
- DestQName (Name of original destination queue)
- DestQMgrName (Name of original destination queue manager)
If you believe that the DLQ-ing routine is putting messages that were destined for a different queue manager on it's DLQ, this will be apparent from the contents of those two fields. However, I would suggest that this is more likely because the original putter was doing a put to Queue @ QMgr where the QMgr was not local, rather than the DLQ-ing routine deciding to DLQ across a QSG. Just a thought.
You didn't say where it was that you saw the "CSQMPRUM" name? Did you see an error message with it, or was it in the DLH?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
------------------------------
Original Message:
Sent: Fri September 25, 2020 11:29 AM
From: David Awerbuch
Subject: CSQMPRUM puts message on DLQ
Hi Morag,
I understand the receiving application failed to retrieve all the messages before closing the TEMPDYN queue it was receiving the responses on, but I am curious to know more about how CSQMPRUM works, and why it would be putting messages from one queue manager in the QSG onto the DLQ of another qmgr in the same QSG (I believe that was the scenario).
I will look for and save the next set of these messages when I run across them, and be able to provide more information for you.
Thanks,
David
------------------------------
David Awerbuch
Original Message:
Sent: Wed September 23, 2020 11:25 PM
From: Morag Hughson
Subject: CSQMPRUM puts message on DLQ
I got two hits when searching CSQMPRUM, APAR PI28005 and APAR PI06260 which is a sysroute of the other. APAR text etc is the same.
The APAR text contains the phrase "... and has invoked CSQMPRUM to put the message to the dead-letter queue." This suggests to me that the CSQMPRUM is the routine in Message Manager (CSQM is Message Manager) that handles DLQ-ing a message, that is, building the DLH and filling in appropriate queue names, reason codes and so on, in the header.
If application messages have been placed on the DLQ, there will be a reason in the Dead-Letter Header (DLH) to say why. Can you tell us what that reason code is?
You shouldn't need to be concerned about what CSQMPRUM is, unless it is failing to put the messages onto the DLQ like the APARs above, but instead focus on why these messages ended up on the DLQ. Where did you see CSQMPRUM? Did you get an error message in the MSTR joblog with CSQMPRUM as the csect insert? Or did you see it somewhere else?
The reason why, and where the messages were supposed to go, should all be contained in the DLH. Can you add that information to your question?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Original Message:
Sent: Wed September 23, 2020 05:48 PM
From: David Awerbuch
Subject: CSQMPRUM puts message on DLQ
We are running z/OS MQ V9.0.0. CSQMPRUM has put a number of obviously application messages on the queue manager's dead letter queue.
What is CSQMPRUM? What does it do for the queue manager? For applications?
I did a google search for the name CSQMPRUM -- from the first 2 results I surmise it has something to do with the QSG; the third result I dare not speak of in mixed company.
Thanks,
David
___________________________________________________________________
David Awerbuch – MQS Messaging Technology – Production Services Group
Home office: 1-516-481-2410 (Protected by NoMoRobo and Hiya Call Screener)
The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.
Please refer to
https://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities. We take our data protection and privacy responsibilities seriously and our privacy notice explains how we collect, use and share personal information in the course of our business activities. It can be accessed at the privacy section of
www.bnymellon.com.