| Author |
Message
|
| mca |
 Posted: Wed Jul 01, 2015 5:59 am Post subject: MQGet not doing destructive Read |
 |
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
We are having an issue with an MQ Get that is not destroying messages in the mainframe output queue. It appears that in some cases the messages are being returned to the application but not in all cases.
The channel appears to open and close almost immediately after being invoked by the server application.
We are not certain what MQ 7.0 configuration parameter to look at to confirm that the Get is actually configured as a destructive read to clear the messages versus a browse type of read.
Background:
We are running this same application from a 2003 Windows server using MQ 6.0 to connect and exchange messages. An IMS transaction is triggered when the application drops a message in bound to the mainframe. The IMS transaction runs and delivers one to many messages back to the output queue for the application to then come and pick up. Everything is running just fine on this set up.
We’ve deployed the application to a Windows 2008 R2 server running MQ 7.0 and we are experiencing this MQ GET issue. Messages are not being deleted in the mainframe outbound queue and some but not all messages are being returned to the application.
In monitoring the starting and stopping of the channel the server application is using we can see that it starts and closes almost immediately.
Any help greatly appreciated. Thanks again for your assistance. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jul 01, 2015 6:25 am Post subject: Re: MQGet not doing destructive Read |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mca wrote: |
| We are having an issue with an MQ Get that is not destroying messages in the mainframe output queue. It appears that in some cases the messages are being returned to the application but not in all cases. |
What do you mean 'returned to the application?' Do you mean returned to the queue? If so, look at the BackoutCount of the first message in the queue. Is it greater than zero?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mca |
| Posted: Wed Jul 01, 2015 8:02 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
The Client-Conn is defined on Windows server. It connects to Server-Conn defined on the Mainframe. Windows initiates a message to Mainframe using the client-conn, mainframe processes it, puts the message to Mainframe MQ Output Queue that comes back to the windows server.
The application on Windows is getting response for the first 10-15 messages but they are doing a non-destructive Get on Mainframe output Queue. After that the Windows server is getting a MQRC2058 (A CLNTCONN channel connection to a WebSphere MQ queue manager fails with: 2058 0x0000080a MQRC_Q_MGR_NAME_ERROR). We have to restart the Windows server before it starts processing again for first 10-15 messages and get this error.
So, first issue is why are the messages not going away from Mainframe output Queue after the MQGet, Second issue is MQRC2058. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 01, 2015 8:09 am Post subject: Re: MQGet not doing destructive Read |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mca wrote: |
| We are not certain what MQ 7.0 configuration parameter to look at to confirm that the Get is actually configured as a destructive read to clear the messages versus a browse type of read. |
That's because there isn't one. It's set by the application as an option on the MQGet call (see here - MQGMO_BROWSE_<something>. What programming framework is the application using, and how did that change between v6.0 / v7.0 and Win2003 / Win2008? Did you just copy the exe file or did you recompile it for the new Windows?
| mca wrote: |
| We’ve deployed the application to a Windows 2008 R2 server running MQ 7.0 and we are experiencing this MQ GET issue. Messages are not being deleted in the mainframe outbound queue and some but not all messages are being returned to the application. |
Congratulations on moving to a supported version of WMQ. What will you do in 3 months when v7.0 goes as out of support as v6.0?
What version is the mainframe running? How is the CAF configured?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 01, 2015 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
MQRC 2058 is a strange error to receive for a client application. By any chance does the application try to connect with bindings then client?
How many client connections are being used to the mainframe? If you do not have the new deal in place (unlimited) you may well be limited to 7 connections on a svrconn channel and hitting this limit when you get the 2058 ??
Have you reviewed your app and are correctly releasing any resources in case of exception?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mca |
| Posted: Wed Jul 01, 2015 12:56 pm Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
We are running NBP1 IBM WebSphere MQ for z/OS V7.0.1 on the UC mainframe. Plannning to upgrade to v7.1 later this month.
We do not have any limit of SVRCONN connections. We are set to maximum number of channels as 1000. The application used up 300 channel limit in the past. So, we modified it to close the channels. This is the only Production system using SVRCONN. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 01, 2015 1:17 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mca wrote: |
We are running NBP1 IBM WebSphere MQ for z/OS V7.0.1 on the UC mainframe. Plannning to upgrade to v7.1 later this month.
We do not have any limit of SVRCONN connections. We are set to maximum number of channels as 1000. The application used up 300 channel limit in the past. So, we modified it to close the channels. This is the only Production system using SVRCONN. |
Where is it that you don't have any limit of SVRCONN connections? How about MAXCHANNELS on your z/OS qmgr? What attributes set the no-limit?
Have the z/OS sysprogs look at qmgr and CHINIT address spaces SYSLOG for errors.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
