Author |
Message
|
TCV |
Posted: Wed Dec 15, 2004 8:41 am Post subject: MQ Problem |
|
|
Apprentice
Joined: 21 Aug 2003 Posts: 48
|
Hi,
We have QM1 on Unix-HP and one QM on OS/390. And the MQ transfers messages all the time. Some times the mainframe QM gets frozen,they cant access the QM. Now when we check on HP we dont see anything wrong with MQ. When we RESOLVE the SDR channel on HP and restart the channel the other side QM is accessable.(I am not sure really the resolving and re-starting the channel did the trick)
The mainframe team complains the the MQ on HP is the one causing. We contacted IBM and they say nothing wrong with MQ and say the network is the one causing the problem They say the TCP/IP session is getting lost on the channel, though we see the channel in RUNNING state on HP.
Do any one faced similar situation?? Please shed some light on this.
Thanks
TC Venkatesan |
|
Back to top |
|
 |
WannaBeInAParker |
Posted: Wed Dec 15, 2004 1:17 pm Post subject: |
|
|
Voyager
Joined: 09 Dec 2003 Posts: 81
|
No I haven't, but always useful to know MQSeries versions and Maintenance levels. _________________ -WannaBe- |
|
Back to top |
|
 |
kman |
Posted: Wed Dec 15, 2004 10:47 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003 Posts: 309 Location: Kuala Lumpur, Malaysia
|
Quote: |
Some times the mainframe QM gets frozen,they cant access the QM. |
does this happens when there is no activity.. meaning no messages sent, so the channel goes down?
And subsequently the channel did not got up when next message is sent?
I've seen this before a few years ago, but that is using SNA between the two, and only one side is giving the problem. Can't remember what we found out, though. I would check to see if there is network probing being done that is causing TCP fluctuation.
And what is actually the problem. Your description is a little vague.. was it the channel, was it the queue manager.. etc? |
|
Back to top |
|
 |
kevinf2349 |
Posted: Thu Dec 16, 2004 5:40 am Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
Is the Qmgr address space being given sufficient WLM priority. We have ours set to the same as TCP/IP
Just something worth checking....especially if the 'freeze' occurs at a time when the rest of the system is very busy. |
|
Back to top |
|
 |
TCV |
Posted: Thu Dec 16, 2004 8:02 am Post subject: hi |
|
|
Apprentice
Joined: 21 Aug 2003 Posts: 48
|
Let me explain again.
Normally no problem in message transfers.Once in a while say 2,3 months the Mainframe QM gets frozen.they cant run any transactions.At that time they try to check MQ and they cant access the QM.Then we check on UNIX end.And everyting is running and no problem.
Now we just STOP CHANNEL(XX) MODE(FORCE)
RESOLVE CHANNEL(XX) ACTION(COMMIT)
START CHANNEL(XX)
Now the QM on the other end icomes to normal and they can access the QM and everything is normal. We dont know if bouncing the channel really did the trick or some thing else. Only we get the blame from the mainframe developers that the MQ on UNIX side is doing this.
Is there a chance any transactions run on mainframe freeze MQ??They dont even like that idea.
And the channels frequently goes down and come back by themselves.
Thanks
TC |
|
Back to top |
|
 |
JT |
Posted: Thu Dec 16, 2004 9:22 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
Quote: |
Is there a chance any transactions run on mainframe freeze MQ?? |
Wouldn't your mainframe folks have some means (monitor/trace) to determine why a queue manager is inaccessible/"frozen"? It may very well be, that your messages are the root cause, but certainly they need to provide you with some information as to what the host queue manager is doing (or not doing). |
|
Back to top |
|
 |
kevinf2349 |
Posted: Thu Dec 16, 2004 9:36 am Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
OK...let me see if I get this right
You have a z/OS transaction that drops a message onto a queue that gets transmitted across to UNIX for processing.
Every couple of months or so the z/OS queue manager 'freezes'...totally. No transactions can start and nobody can get the queue manager to respond.
Stopping a resolving the SNDR channel appears to free up the queue manager.
Is that correct?
if so....what type of transaction is it? IMS, CICS, DB2, batch?
Is a reply expected before processing in the transaction proceeds? If so do you resolve the RCVR channel too? What syslog messages, if any are you seeing on the mainframe? Check both the job logs for the CHIN and MSTR address spaces. What error messages (if any) are you getting on the UNIX Qmgr?
I am afraid that much more information is required from the z/OS end so if your z/OS system people are not going to help by providing this you may be caught in a catch 22....unless you can access this information.
We have z/OS queue managers and we haven't experienced anything like this.
What are the MQ versions involved? Both ends 5.3? Any Encryption involved? Any SSL? Any Channel exits? |
|
Back to top |
|
 |
JT |
Posted: Thu Dec 16, 2004 9:51 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
Quote: |
You have a z/OS transaction that drops a message onto a queue that gets transmitted across to UNIX for processing |
Kevin, I believe it's the other way around, the offending message, suspected of causing the host queue manager to "freeze", is sent from HP/Unix environment to the z/OS queue manager.
TCV wrote: |
When we RESOLVE the SDR channel on HP |
|
|
Back to top |
|
 |
kevinf2349 |
Posted: Thu Dec 16, 2004 10:02 am Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
Aha....I see.
In that case and given that IBM have determined that is isn't MQ on HP, then I would make sure that you don't have anything that is attempting to share the TCP/IP port on z/OS. We had a Qmgr on z/OS that setup incorrectly and the listner was starting against the same port as another Qmgr and that caused all kinds of strange happenings. |
|
Back to top |
|
 |
kman |
Posted: Thu Dec 16, 2004 8:09 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003 Posts: 309 Location: Kuala Lumpur, Malaysia
|
Is it possible that your log is full, and no write activity can occur. Check to see if similar messages is written on the mainframe side.
I did not it is the problem, but worth checking (since this happens after a long duration, and it freezes the qm). The only problem with this assumption is ..how it relate to resolving the channel.  |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Dec 17, 2004 6:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
kman wrote: |
Is it possible that your log is full, and no write activity can occur. Check to see if similar messages is written on the mainframe side.
I did not it is the problem, but worth checking (since this happens after a long duration, and it freezes the qm). The only problem with this assumption is ..how it relate to resolving the channel.  |
If you look, they are force closing the channel, and force committing it.
This should allow log space to be reused...
This is a good theory... TCV - try reducing the batch size on your channel. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
TCV |
Posted: Fri Dec 17, 2004 8:53 am Post subject: Check point |
|
|
Apprentice
Joined: 21 Aug 2003 Posts: 48
|
Does the QM is not accessible during the QM runs checkpointing after sertain transactions? |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 17, 2004 2:49 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Or could it possibly be a non persistent message that is bigger than the acceptable size for chl, q, dlq etc ... on the MF and that gets lost in the stop force ?
Enjoy  |
|
Back to top |
|
 |
|