|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Message exit and MQSC Commands |
« View previous topic :: View next topic » |
Author |
Message
|
Mr Butcher |
Posted: Thu Jan 24, 2013 5:24 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
Hello,
yes, still here.
Just let me figure out that i do not use this feature for mqseries administration. I used it for special testing situations and to extract technical informations i need at a specific point in time, either from the message arriving/leaving or e.g. at channel start / stop time.
I dont recommend to use that for administration (and i would never do that). And i recommend to be very careful with the usage, because - even if there are multiple tcb's in the chin to handle the channels, there are always multiple channels handled by a single tcb. And - when one channel spends a lot of time in the exit, the tcb is blocked for the other channels. So be careful, especially if you use get-wait when waiting for replies? You may block other channels. This is also written in the documentation somewhere .....
now for your problem not receiving a reply ..... IMHO you should either receive a returncode from the put, or at least a reply to your reply queue, no matter what the command is. At least you should receive that the command was invalid or that could not be executed or whatever. Double check you filled out the proper md fields for the reply.
so check your returncode handling.
check the security. check that you (the CHIN) is authorized to put to the command queue. if you use command and admin security make sure, the CHIN user is authorized to issue the command on the specified objects.
Did you also check the DLQ? If the reply can not be put to the reply queue for whatever reason, mq should put it to the DLQ.
Check MSTR and CHIN logs for messages...
In the MQOD i set objectname and objecttype
In the MQMD i set replytoq, msgtype to request, non persistence,
in the pmo i set no_syncpoint
and i used mqput1 _________________ Regards, Butcher |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jan 24, 2013 6:10 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Does the cics app that creates the message do in syncpoint? _________________ 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 |
|
 |
RogerLacroix |
Posted: Thu Jan 24, 2013 1:34 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
MaxP wrote: |
The exit is running and I am doing a MQPUT to SYSTEM.COMMAND.INPUT - just nothing is coming back to my replyq, unlike when I test under CICS. |
That should be a MQPUT1 with certain MQMD fields filled out (see Mr Butcher's comments).
MaxP wrote: |
Just a linked to CICS application program:
Open request queue
Open reply queue
Put a message to request queue
Get messages from reply queue
Format a record with required fields extracted from the reply queue messages, and output this somewhere
Close request queue
Close reply queue |
Silly rabbit, tricks are for kids..... Under CICS, you are automatically (or automagically) connected to the queue manager but in an exit, you are NOT. Issue an MQCONN and life will be fine!!!
Speaking of fine, how come you are not checking your CC and RC from the MQOPEN?
MaxP wrote: |
Open request queue |
And why are you opening the request queue? How many messages are you sending to the command queue? You are in a channel message exit - you should not be doing elaborate MQ message conversations.
MaxP wrote: |
Open reply queue |
That should be a temporary dynamic queue, so that you don't have different threads (TCBs) reading the wrong response message.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
MaxP |
Posted: Thu Jan 24, 2013 4:09 pm Post subject: |
|
|
Newbie
Joined: 22 Jan 2013 Posts: 9
|
Ahh Roger, wondered if I'd be seeing you. How are the pugs? I'm doing a MQOPEN/MQPUT/MQCLOSE so as to create a temporary dynamic queue for the reply (I have changed this to a permanent dynamic queue for debugging purposes). I am doing a MQCONN in the channel exit (as suggested in the Intercommunication manual). I check CC and RC after every call, as is standard programming practice.
Yes, I am in a channel exit and I realise that I am holding up every channel, etc. I've implemented a version of SupportPac MR01 as a channel exit for another client a few years back and, horror of horrors, it is issuing WTOs and updates to sequential datasets - all sorts of despicable wait type operations. Their world did not end either. I can drop the MQCLOSE of the reply queue if need be, but that's not the burning issue. To allay the concerns of the purists, the channel exit will be used intermittently to capture parameter values from a DISPLAY, not for 'administration' purposes.
Thanks for replying Mr Butcher
For the MQPUT I am setting the following:
In the MQPMO:
MQPMO_OPTIONS to MQPMO_NO_SYNCPOINT
In the MQMD:
MQMD_PERSISTENCE to MQPER_NOT_PERSISTENT
MQMD_MSGTYPE to MQMT_REQUEST
MQMD_REPLYTOQ to the dynamic queue that was created by the MQOPEN
MQMD_FEEDBACK to MQFB_NONE
and setting MQMD_REPORT, MQMD_CORRELID and MQMD_MSGID to nulls |
|
Back to top |
|
 |
MaxP |
Posted: Thu Jan 24, 2013 4:13 pm Post subject: |
|
|
Newbie
Joined: 22 Jan 2013 Posts: 9
|
Oh, and MQMD_FORMAT to MQFMT_ADMIN in MQMD |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Jan 24, 2013 4:31 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
MaxP wrote: |
How are the pugs? |
Always under foot.
MaxP wrote: |
MQMD_PERSISTENCE to MQPER_NOT_PERSISTENT
MQMD_MSGTYPE to MQMT_REQUEST
MQMD_REPLYTOQ to the dynamic queue that was created by the MQOPEN
MQMD_FEEDBACK to MQFB_NONE
and setting MQMD_REPORT, MQMD_CORRELID and MQMD_MSGID to nulls
and MQMD_FORMAT to MQFMT_ADMIN in MQMD |
I agree with everything except for the last item. I just do:
Code: |
memcpy(md.Format, MQFMT_STRING, MQ_FORMAT_LENGTH); |
Have you checked the DLQ? In a channel message exit, the exit is running under the CHIN's UserID and it may not have permission to make the request. Hence, the Command Server will send a reply message to the DLQ.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
MaxP |
Posted: Thu Jan 24, 2013 8:42 pm Post subject: |
|
|
Newbie
Joined: 22 Jan 2013 Posts: 9
|
Yes, found some reply messages on the DLQ (thanks for the suggestion Mr Butcher and Roger). My DLQH was deleting them, as I was using the same prefix as used by our MQ monitoring tool (and these are just deleted). Changed prefix and there they are. |
|
Back to top |
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|