| Author |
Message
|
| eurotait |
 Posted: Mon Aug 16, 2010 6:51 am Post subject: Finding MQCONN entries in TRACE |
 |
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
Hello gurus. We are running MQ v6 and v 7.0.1 in a z/OS 1.11 environment.
We are running GTF trace on a z/OS MQ batch program - the IBM sample program CSQ4BCK1.
After formatting USR(5EA), we can see the control blocks and MQRC values on exit from the MQ API for OPEN, GET, PUT and CLOSE.
We can't see entries for MQCONN or MQDISC.
I have also used USR entries of 5E9 and 5EE, but cannot find MQCONN or MQDISC information there either.
I would like to see the return and reason codes from the MQCONN calls.
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 16, 2010 7:17 am Post subject: Re: Finding MQCONN entries in TRACE |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eurotait wrote: |
We can't see entries for MQCONN or MQDISC.
|
Does the batch adapter issue MQCONN or MQDISC? I thought it ignored them like the CICS adapter does & uses the values in CSQBDEFV.
Been a while though. You don't see much batch WMQ z/OS (or I don't) and would welcome correction on that.
(Paging Mr Butcher. Paging Mr Butcher....  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| eurotait |
| Posted: Mon Aug 16, 2010 7:25 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
The batch adapter does. The CICS adapter doesn't. And I have no idea about evil IMS  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 16, 2010 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eurotait wrote: |
| The batch adapter does. |
Then I'm stumped. Someone brighter will be along in a minute. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 16, 2010 7:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Does the batch adapter issue MQCONN or MQDISC?
I thought it ignored them like the CICS adapter does & uses the values in CSQBDEFV.
The batch adapter does. The CICS adapter doesn't |
.
Wow... confusion.
Could this be less clear?
_________________
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 |
|
|
| eurotait |
| Posted: Mon Aug 16, 2010 10:59 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
Clarification.
Batch, TSO, and IMS applications must issue the MQCONN call to use the other MQ calls.
CICS applications do not have to issue the MQCONN, but the call can be left in the code without problem.
CSQBDEF can be used on z/OS to nominate a default QM.
Sorry about my poor english. I'm Australian |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 16, 2010 11:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eurotait wrote: |
| CICS applications do not have to issue the MQCONN, but the call can be left in the code without problem. |
Strictly CICS applications must still issue the MQCONN call; they just get a dummy connection handle through to the queue manager the CICS system is connected to and the call never actually goes out anywhere. This can be proved by using a MQCONNX call to a different queue manager; the call apparently succeeds but you end up on the CICS system's queue manager.
I thought the same was true of batch. But clearly it isn't
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Aug 16, 2010 11:35 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
who paged me? yes, i am a z/Os guy.... how did you know?
however, it is all said by now...nothing more to throw in here. i recently took a gtf trace but this was related to IMS region, and i did not care about the connect so i do not know for sure.
But for CICS i assume that you will see the connect from the CICS region to MQ on CICS startup (connection time) if the trace settings are properly, but no connect from the application as this is just a dummy between cics and the application (as already been said here).
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 17, 2010 4:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mr Butcher wrote: |
| who paged me? yes, i am a z/Os guy.... how did you know? |
Oh I don't know, subtle clues in your postings, that sort of thing.... 
| Mr Butcher wrote: |
| But for CICS i assume that you will see the connect from the CICS region to MQ on CICS startup (connection time) if the trace settings are properly, but no connect from the application as this is just a dummy between cics and the application (as already been said here). |
So I was mostly right. And this does seem the mostly likely explaination of why you don't see connections out of the batch adapter either.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| eurotait |
| Posted: Wed Aug 18, 2010 2:40 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
This was IBM's response.
[....we don't cut MQCONN or MQDISC trace records (as much of the
processing happens outside of the qmgr). However, if this is the first
MQCONN then CSQ3ID30 and CSQ3CT30 records may get written. You won't
see these records on the second MQCONN though, unless of the course
an MQDISC call was issued in between. On an MQDISC we write CSQ3ID80
and CSQ3CT80 records.....]
Clear - not really, but since I am interested in the response from a second consecutive MQCONN call, I have my answer ie I won't see it in the trace.
Thanks all. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 18, 2010 4:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eurotait wrote: |
| Thanks all. |
Thank you for posting the resolution. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Aug 20, 2010 10:24 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| eurotait wrote: |
Clear - not really, but since I am interested in the response from a second consecutive MQCONN call, I have my answer ie I won't see it in the trace.
Thanks all. |
I almost hate to ask but....why are you doing two consecutive connects in the first place? Or is that the issue that you are trying to track down?
Connect always was (and I assume still is) one of the most expensive API calls. It is (IMHO) bad application design to connect more than once to any one queue manager. |
|
| Back to top |
|
|
| eurotait |
| Posted: Wed Aug 25, 2010 1:58 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
Ah, good application design.......
Sadly, we just have to make work what gets written. 
The existing application reuses the same module for both long-running
tasks (relying on an existing connection) and short lived tasks, which can't be sure one exists.
To be fair to the developers, it worked under v6 and does not under v7.
If something has changed between versions, it should be published in the migration guide. We currently have a pmr open with ibm on this issue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 25, 2010 4:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eurotait wrote: |
| We currently have a pmr open with ibm on this issue. |
We look forward to your further postings on this matter.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| eurotait |
| Posted: Thu Sep 30, 2010 5:39 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2006
Posts: 6
Location: uk
|
Follow up:
IBM has opened APAR AM23207. The problem description is similar to
"on a second consecutive MQCONN call, the return code is 0, whereas we expected to get 2002."
The problem affects MQ z/OS v7.0.1 and IMS running L/E (COBOL in our case.)
The fix IBM cut has tested well for us so far.
 |
|
| Back to top |
|
|
|
|
