| Author |
Message
|
| mikiu |
 Posted: Thu Jan 24, 2013 10:19 am Post subject: Five second delay on MQDISC after 5.3 --> 7.0 Client upgr |
 |
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Hello gentle and learned folks,
We upgraded our AIX client (apps is C-lang / MQ) from 5.3 to 7.0. The user log shows consistently:
------------------------------------------------------------
Jan 22 15:31:00 sdmq_doMQdisconnect(): attempting MQDISC()
Jan 22 15:31:05 sdmq_doMQdisconnect(): MQDISC worked
And further ...
Jan 23 11:04:25 sdmq_doMQdisconnect(): attempting MQDISC()
Jan 23 11:04:30 sdmq_doMQdisconnect(): MQDISC worked
Source that produces log has only a MQDISC call:
/* Attempt disconnect from MQ Manager */
tlogprintf(tL, "%s(): attempting MQDISC()", __func__);
MQDISC(conn_h, &mq_rc, &reason_rc);
if ( mq_rc == MQCC_OK ) {
/* Disconnect from MQ Manager worked */
tlogprintf(tL, "%s(): MQDISC worked", __func__)
----------------------------------------------------------------------
We are aware of APAR IZ78516, but our AIX MQ is at 7.0.1.4 level and IBM website says that U835793 is included in this already.
But I don't believe any, so I checked:
---------------------------------------------------------
[/AIXpatches/MQRetail/MQ7.0.1.4]>ls -lrt | grep U835793
-rw-r--r-- 1 root users 18922496 Jan 13 08:55 mqm.base.
runtime.7.0.1.4.U835793
--------------------------------------------------------
Also that APAR says that the delay on MQDISC is multiples of twleve seconds which is not our case.
Can I just assume MQDISC suddenly grew? Five secs is an awfull ong time (IMO)
Is there anything yous can say in this? I'd be immensly grateful.
Thank you,
MikiUh |
|
| Back to top |
|
 |
| mvic |
| Posted: Thu Jan 24, 2013 3:28 pm Post subject: Re: Five second delay on MQDISC after 5.3 --> 7.0 Client |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| mikiu |
| Posted: Fri Jan 25, 2013 6:14 am Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Thank you ... this helps ... follow up: do we need both client and manager higher than 7.0.1.4? We currently have a combination of 7.0.1.4 and 7.0.1.8 and working towards more currency.
most grateful for your time and effort! |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jan 25, 2013 6:23 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mikiu wrote: |
| do we need both client and manager higher than 7.0.1.4? |
I don't know. Try it out, or ask IBM. |
|
| Back to top |
|
|
| mikiu |
| Posted: Fri Jan 25, 2013 5:00 pm Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Hullo mvic,
Did what you suggested "Try it out" my first choice always ... turns out a 7.0.1.8 client works flawlessly only with a 7.0.1.8 queue manager (if I stay on the 7.0.1.4 queue manager, the five sec delay is still there).
It was very nice of you to take the time to deal with this for me. Will ask them to close the PMR, as they came back with their ususal: "gimme the dumps, gimme more dumps, gimme the trace, gimme more trace"
regards,
MikiUh |
|
| Back to top |
|
|
| SAFraser |
| Posted: Sat Jan 26, 2013 2:37 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
mikiu-- Very grateful for your research and for sharing your result.
Everyone-- I find this disturbing. Upgrading server and client simultaneously in our shop is not even remotely practical, especially since most of our clients are WAS JVMs that use the embedded client files. Our attempts to influence WAS upgrades/fixpacks have failed miserably, and our attempt to force WAS clients to use a separately installed MQ client was also a complete bust.
But I've been able to sleep at night knowing that MQ is famously backward compatible. Till now. <sigh> |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jan 26, 2013 3:02 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| SAFraser wrote: |
| But I've been able to sleep at night knowing that MQ is famously backward compatible. Till now. <sigh> |
I think that's not necessarily the right interpretation.
There's a bug which is fixed in an APAR (IZ94330) which went out in a fix pack already (7.0.1.5). So I took a look, and the description of the bug is not anything like "client/server incompatible". It's "5 second delay when a client closes a multiplex conversation". |
|
| Back to top |
|
|
| SAFraser |
| Posted: Sat Jan 26, 2013 8:51 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| Sleep shall be mine tonight! |
|
| Back to top |
|
|
| mikiu |
| Posted: Mon Jan 28, 2013 6:24 am Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
We can argue on compatibility theory ... fact is that THIS particular bug is limited in scope and should not affect WAS applications because WAS (like her big brother CICS) handle the CONNECTs and DICONNECTs, justifiably, IMO, not trusting the application programmers to do the right thing. So this delay hits only the ancient C with MQ MQI applications that built daemon like code in an attempt to emulate an MDB or CICS triggering and only after I got them off their V5R3 Client (which, BTW, worked great with the 7.0.1.4 Queue Manager). Nevertheless and notwithstanding sleep is (sometimes) ours.
Cheers,
M.U. |
|
| Back to top |
|
|
|
|
