| Author |
Message
|
| deanfore |
 Posted: Thu Jan 14, 2010 11:38 am Post subject: Handle Status and Message flow WMQ v 5.2 |
 |
|
Novice
Joined: 08 Aug 2006
Posts: 18
|
Hi all,
I have a batch file process of some sort utilizing a WMQ v5.2 middle tier server possibly communicating with a back-end mainframe through another MWQ server. The batch file process is an in house home grown app and the developer is long gone and I am tasked with tracing the message flow, front-end and backend connections. One issue that I face is it's v5.2 and I can not view the handle status on the only queue I believe is being used for the batch (I can see that there is an open input count via the WMQ GUI but can not view the status of the queue to see what has a handle on that queue – connection name etc…) - the next issue is that I only see the receiver channel on that v5.2 middle tier server go into a running status at different times of the day and night – no sender channel ever fires up. Does anyone have any suggestions on tracing this message flow so I can migrate the WMQ to a new server and to WMQ v6.0. Any information you need I can provide to help figure the best plan. Thanks in advance. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 14, 2010 11:49 am Post subject: Re: Handle Status and Message flow WMQ v 5.2 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deanfore wrote: |
| One issue that I face is it's v5.2 and I can not view the handle status on the only queue I believe is being used for the batch (I can see that there is an open input count via the WMQ GUI but can not view the status of the queue to see what has a handle on that queue – connection name etc…) |
No, you can't. Not on WMQv52
| deanfore wrote: |
| - the next issue is that I only see the receiver channel on that v5.2 middle tier server go into a running status at different times of the day and night – no sender channel ever fires up. |
If you intercept some messages, the reply to queue manager will probably be where they're coming from. It's unlikely the putting application will have bothered to set the value in this sort of scenario.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 14, 2010 11:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'd start by creating a flowchart of what happens where.
Begin with the application program that starts this process. Look at the source code to see what queue manager and queue it opens.
Next look at the definitions in that qmgr to see what the queue definition looks like. Look for a QRemote definition. This queue definition will identify the transmission queue that the message goes to. This def will also identify the RNAME - the name of the destination queue down the network AND the qmgr name where the destination queue exists.
Then look at the sender channel definition to identify which sender channel looks into the transmission queue identified in the queue definition. The channel definition will identify the ip(port) of the next qmgr down the network.
Look at the receiving end qmgr definitions. If, as you explain, this qmgr is a hop on the way to the destination qmgr, look for a transmission queue with the same name as the destination qmgr. Then look for a sender channel to the next hop.
Let us know what you find.
_________________
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 |
|
|
| deanfore |
| Posted: Thu Jan 14, 2010 12:19 pm Post subject: |
|
|
Novice
Joined: 08 Aug 2006
Posts: 18
|
| Good intel – FYI so I found a queue alias… that point to a queue remote …that point to the one and only XMIT queue defined for the QMGR - the XMIT queue points to a sender channel (again, no evidence that it has started in over two weeks, I only see where the receiver channel starts periodically throughout the day). I have used the program qstats.exe to pull back the message counts for all queues and there has been no messages put on the XMIT. That tells me that the Qalias, QRemote, and XMIT are not being utilized for this batch process. One more thing I discovered is that there is a temporary queue being created also periodical throughout the day. Is it possible that the front batch file process puts a batch file on the middle tier queue and the backend process reaches out to that middle tier server to get the messages on the queue thus firing up the receiver channel only. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 14, 2010 12:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deanfore wrote: |
| Is it possible that the front batch file process puts a batch file on the middle tier queue and the backend process reaches out to that middle tier server to get the messages on the queue thus firing up the receiver channel only. |
Only if the back end's using a server/requestor rather than a sender/receiver but that could behave as you describe. Of course the backend could client onto the middle tier and retrieve the messages directly (a more common scenario)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 14, 2010 1:18 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| the XMIT queue points to a sender channel (again, no evidence that it has started in over two weeks |
What other channel definitions did you find?
_________________
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 |
|
|
| deanfore |
| Posted: Thu Jan 14, 2010 1:57 pm Post subject: |
|
|
Novice
Joined: 08 Aug 2006
Posts: 18
|
1 sender and 1 receiver related to another middle tier QMGR on a different box
1 sender and 1 receiver to a mainframe
1 svrconn channel to that same middle tier QMGR I listed above
1 client channel defined
I never see any activity on any of the channels except that 1 receiver channel fire up for 10 minutes at different intervals throughout the day. That receiver channel is defined for the QMGR sitting on the other Windows box and not the mainframe - just to clarify
No clustering architecture involved with this the 5.2 install. |
|
| Back to top |
|
|
|
|
