| Author |
Message
|
| HenriqueS |
 Posted: Tue Dec 19, 2006 9:00 am Post subject: SYSTEM.COMMAND.INPUT and MessageId / CorrelId |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks,
I wanted to know more about the behaviour of MQSC scripts executed through the SYSTEM.COMMAND.INPUT queue.
I am not sure if the following behaviour is assured:
a) SYSTEM.COMMAND.INPUT receives the message containing the script.
b) MQ processes the script, the output goes to the specified ReplyTo Queue specified within the message.
c) The message containing the output contains has the CorrelId set to the same value as the MessageId from the message Id that contained the MQSC script.
Is this correct? Where can I find more information of such behaviour?
Thanks!  |
|
| Back to top |
|
 |
| wschutz |
| Posted: Tue Dec 19, 2006 9:09 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Dec 19, 2006 9:20 am Post subject: Re: SYSTEM.COMMAND.INPUT and MessageId / CorrelId |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| HenriqueS wrote: |
| Is this correct? Where can I find more information of such behaviour? |
Yes. The WMQ for z/OS System Administration Guide will have more information.
One more thing: Your application should be using a temporary dymanic reply queue then you don't need to worry about any MsgId / CorrelId issues.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Dec 19, 2006 9:36 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
I talked to my boss, he said to stick with MQSC for now. 
Guess I found some guidance...
From the infocenter:
Understanding how it all works
In outline, the procedure for issuing commands from an application program is quite simple:
-You build a WebSphere MQ command into a type of WebSphere MQ message called a request message. The command can be in MQSC or PCF format.
-You put (MQPUT) this message onto a special queue called the system-command input queue. The WebSphere MQ command processor runs the command.
-You retrieve (MQGET) the results of the command as reply messages on the reply-to queue. These messages contain the user messages that you need to determine whether your command was successful and, if it was, what the results were.
Then it is up to your application program to process the results.
------------------
Waiting for a reply
Use the MQGET call to retrieve a reply from your request message. One request message can produce several reply messages. For details, see Interpreting the replies.
You can specify a time interval that an MQGET call waits for a reply message to be generated. If you do not get a reply, use the checklist beginning in topic If you do not receive a reply.
To use the MQGET call:
Set these parameters:
Hconn
The connection handle returned by the MQCONN or MQCONNX call.
Hobj
The object handle returned by the MQOPEN call for the reply-to queue.
Buffer
The name of the area to receive the reply.
BufferLength
The length of the buffer to receive the reply. This must be a minimum of 80 bytes.
To ensure that you only get the responses from the command that you issued, you must specify the appropriate MsgId and CorrelId fields. These depend on the report options, MQMD_REPORT, you specified in the MQPUT call:
MQRO_NONE
Binary zero, '00...00' (24 nulls).
MQRO_NEW_MSG_ID
Binary zero, '00...00' (24 nulls).
This is the default if none of these options has been specified.
MQRO_PASS_MSG_ID
The MsgId from the MQPUT.
MQRO_NONE
The MsgId from the MQPUT call.
MQRO_COPY_MSG_ID_TO_CORREL_ID
The MsgId from the MQPUT call.
This is the default if none of these options has been specified.
MQRO_PASS_CORREL_ID
The CorrelId from the MQPUT call.
For more details on report options, see the WebSphere MQ Application Programming Reference manual.
Set the following GetMsgOpts fields:
Options
MQGMO_WAIT
If you are not using the same code page as the queue manager, set MQGMO_CONVERT, and set CodedCharSetId as appropriate in the MQMD.
WaitInterval
For replies from the local queue manager, try 5 seconds. Coded in milliseconds, this becomes 5 000. For replies from a remote queue manager, and channel control and status commands, try 30 seconds. Coded in milliseconds, this becomes 30 000.
Discarded messages
If the command server finds that a request message is not valid, it discards this message and writes the message CSQN205I to the named reply-to queue. If there is no reply-to queue, the CSQN205I message is put onto the dead-letter queue. The return code in this message shows why the original request message was not valid:
00D5020F It is not of type MQMT_REQUEST.
00D50210 It has zero length.
00D50212 It is longer than 32 762 bytes.
00D50211 It contains all blanks.
00D5483E It needed converting, but Format was not MQFMT_STRING.
Other See the WebSphere MQ for z/OS Messages and Codes manual. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Dec 19, 2006 9:47 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Looks like the msgId from the incoming input message is copied to the correlId from the reply msg.
------------------
MQRO_COPY_MSG_ID_TO_CORREL_ID
The MsgId from the MQPUT call.
This is the default if none of these options has been specified.
------------------- |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Dec 19, 2006 1:04 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| HenriqueS wrote: |
Looks like the msgId from the incoming input message is copied to the correlId from the reply msg.
|
This is working as designed.
I have a pretty basic question here....why are you doing this?
Couldn't you just use the ISPF interfaces?
To be hoenest with you we have several z/OS queue managers handling thousands of messages and we haven't had to write a stick of code to issue commands down to the queue managers. (Well not since IBM introduced Channel triggering). |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 19, 2006 1:15 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And you know, I found a support pack that will let you do MQSC commands from your PC to your z/OS QMGR so long as you have privilege to do the command in the first place.
It is my recollection that I needed to tell it a prefix to the temporary dynamic queue it uses, that I had authorization to. I will see if I recognize the support pack.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Dec 19, 2006 1:17 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Pehraps: mo72-MQSC_Client_for_WebSphere_MQ
and there's the ever popular "-x" flag on runmqsc.....
_________________
-wayne |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Dec 19, 2006 5:01 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Ok, I work at a financial instituition, pretty much the equivalent of the US Federal Reserve, but in my own country.
Several other financial instituitions connect to us in a hub and spoke topology. We do consolidate transactions between those banks and monitor their assets level (there is probablu a better word for that), so we can switch them off if they don´t have more money or start playing with someone else´s money.
We had a console app (Natural + Adabas) allowing the remote users (operators from those banks) to gather some info as channel status, execute actions as channel stop/start and change their queue mgr name, hostname, tcp/ip port and so on. The users have obviously only control over their respective MQ objects.
Suddenly they came with the idea of supplying a web based interface. It´s a preliminary study to maybe someday switch the "broker" from z/OS to a cluster of low end machines.
I am a newbie here and my boss is a old school guy who really understands about CICS, Natural, z/OS, etc but has no clue about web programming or java. That´s how I got the assignment. I am the opposite, I almost have no clue about mainframe technologies - they pretty much stopped teaching this sort of stuff on college 20 years ago in my country.
So I guess the next years I´ll be a common name roaming the mqseries.net forum  .
| kevinf2349 wrote: |
| HenriqueS wrote: |
Looks like the msgId from the incoming input message is copied to the correlId from the reply msg.
|
This is working as designed.
I have a pretty basic question here....why are you doing this?
Couldn't you just use the ISPF interfaces?
To be hoenest with you we have several z/OS queue managers handling thousands of messages and we haven't had to write a stick of code to issue commands down to the queue managers. (Well not since IBM introduced Channel triggering). |
|
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Dec 19, 2006 5:20 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| So I guess the next years I´ll be a common name roaming the mqseries.net forum |
Welcome aboard then! 
_________________
-wayne |
|
| Back to top |
|
|
|
|
