Author |
Message
|
Monk |
Posted: Sun May 20, 2007 4:09 am Post subject: MQGet Node - Where do you set MQMD params? |
|
|
 Master
Joined: 21 Apr 2007 Posts: 282
|
Hi All
Can anyone tell me how MQGet node works.
I need to set CCSID and Encoding in MQMD before I do a MQGET using MQGET Node.
I tried setting the input MQMD parameter location to Environment.MQGET.Inputparms.MQMD
and it did not work
Someone please tell me how to set the MQMD parameters for MQGEt call using MQGet node.
I am using Broker v.6.0.0.3.
Any help on this would be appreciated.
Thanks _________________ Thimk |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun May 20, 2007 8:16 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You do not set the CCSID on the MQGet node...you may set it on the MQPut node (usually done in code at the compute node)...
The broker will automatically handle any CCSID conversion, this of course assumes that the message has the CSSID corresponding to its content.
IIRC the message tree is always in unicode.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Monk |
Posted: Sun May 20, 2007 11:21 am Post subject: |
|
|
 Master
Joined: 21 Apr 2007 Posts: 282
|
Hi
Thanx for the reply.
but I am trying to convert ebcidic to ascii using MQget node...
I did set the convert option, but did not work..
as per documentation ts says we need to have the right CCSID set before converting.
So how can I do this sort of conversion using MQget node.
the message content is in ebcidic format , when I do a MQget i need it to be in ascii format.
any suggestions...would be helpful...
Thanx _________________ Thimk |
|
Back to top |
|
 |
Vitor |
Posted: Sun May 20, 2007 12:04 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Make sure the EBCDIC message has a valid EBCDIC CCSID when it's put, and it's one for which you have a conversion table installed at system level. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
XZ |
Posted: Mon May 21, 2007 12:24 am Post subject: |
|
|
 Apprentice
Joined: 22 May 2006 Posts: 45 Location: IBM Hursley
|
This looks like a known bug. Try setting "Use complete input MQMD" as a workaround. Also, make sure the "minimum message buffer size" is big enough. _________________ Regards,
-XZ
WMQI Development |
|
Back to top |
|
 |
Paul D |
Posted: Wed Jun 27, 2007 9:50 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 200 Location: Green Bay Packer Country
|
I also can't get this to work. I was trying to call an MQGet after an aggregate reply node. I ended up copying the MQMD from my first valid reply message in the aggregate folder and using that as a base for the MQMD heading into the MQGet. I'd just reset the correl id for the get. This did work for me. Was anyone else in the same situation as me and did something else? _________________ Thanks!!!
Paul D |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Wed Jun 27, 2007 10:46 am Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
This will be a long reply -
-----------------------------------------------------------------------------------------
My test msg flow consisted of a MQInput -> Compute -> Trace -> MQget ->Trace ... I sent a msg using rfhutil that had been captured from another msg flow so that it had a MsgId already in the MQMD. I sent another msg to the 2nd queue where it had a CorrelId that matched the MsgId of the 1st msg. The 2nd msg was also using CCSID 1200 and I wanted it in 1208.
Notes about the flow:
This is the test message flow. The two important parts are the Compute node that does the setup work and the MQGet node that reads the second queue. Since the Compute node is building an OutputLocalEnvironment, its “Compute mode property” must be LocalEnvironment and Message.
The MQInput node also supports the conversion to a different CCSID and Encoding. This action is specified in the properties of the node.
Note: The queue used by the MQInput node and the queue used by the MQGet node must be different.
-----------------------------------------------------------------------------------
This is the ESQL for the Compute Node - I was testing several optons:
BEGIN
CALL CopyMessageHeaders();
-- Mim requirements is for the headers
-- Example assumes Queue is the ReplyToQ
SET OutputLocalEnvironment.MQ.GET.QueueName =
InputRoot.MQMD.ReplyToQ;
-- Allows override of the mim buffer alloc,
-- for Get w/ Convert, must be > msg size
SET OutputLocalEnvironment.MQ.GET.InitialBufferSize = 12;
-- Processing for MQGet with convert
-- Requires Use Complete MQMD property on MQGet
-- We first set the MQGMO options to request conversion
SET OutputLocalEnvironment.MQ.GET.MQGMO.Version = 1;
SET OutputLocalEnvironment.MQ.GET.MQGMO.Options = MQGMO_CONVERT;
-- Allows an override of the value specified, must be > 0
SET OutputLocalEnvironment.MQ.GET.MQGMO.WaitInterval = 15000;
-- The CCSID is the target for the Get with Convert
SET OutputLocalEnvironment.MQMD.CodedCharSetId = 1208;
-- Only character data can be converted
SET OutputLocalEnvironment.MQMD.Format = 'MQSTR ';
RETURN TRUE;
END;
----------------------------------------------------------------
Notes on the Compute node:
1. Only the Message Headers are passed to the MQGet node. This is a minimum requirement.
2. The override value for the name of the queue to be read is passed in the InputRoot.MQMD.ReplyToQ. Note that you should also check to make sure that this field contains a value before using it as an override. This value is placed in the OutputLocalEnvironment.MQ.GET.QueueName.
3. When doing an MQGet with Convert requested, the InitialBufferSize must be larger than the requested message and associated headers. This restriction will be removed in a future fixpack. However, by setting this value, you also benefit by eliminating a second memory allocation. The ESQL shows how the property specification (which must be > 0) can be changed at runtime.
4. An MQGet with Convert uses a combination of the CCSID from the MQMD and a set of MQGMO options. The MQGMO information should be built in the OutputLocalEnvironment.MQ.GET tree structure. This is done by the two statements.
5. The ability to dynamically change the WaitInterval for an MQGet may also be useful. The override value, in milliseconds, is placed in the same tree as OutputLocalEnvironment.MQ.GET.WaitInterval. Note that the Wait Interval property in the node must be greater than 0.
6. The second part of an MQGet with Convert is the CCSID that is set in the OutputRoot.MQMD.CodedCharSetId. In this example, the value is set to 1208. As will be mentioned later, another current requirement is that the node property “Use complete MQMD” must also be set for an MQGet with Convert. The MQGet node will build a “default” MQMD and apply the needed information from the LocalEnvironment.MQMD that is passed from the Compute node.
7. An MQGet with Convert also requires that the MQMD Format field be set to MQSTR (MQ String), as shown in the last SET statement.
8. Although not shown in the example, The MQOutput node stores the message ID in the LocalEnvironment.WrittenDestination.MQ.DestinationData.msgId. This can then be used if an MQGet by setting the value in the MQMD prior to the MQGet.
----------------------------------------------------------------------------------
Concerning the Configuration of the MQGet node - specifically the Advanced, Request and TResult abs:
Advanced: Make sure that:
1. The Generate mode is set to Message and LocalEnvironment
2. The Copy local environment is set to Copy Entire LocalEnvironment
3. The Wait interval is appropriate for your situation. If you plan on providing an override, the value here must be greater than zero.
4. The Minimum message buffer size must be larger than the inbound message and headers if you plan on using an MQGet with Convert. You can override this value.
Request: Make sure that:
1. Set the Input MQMD Location to InputLocalEnvironment.MQMD
2. Click the check box for Use complete input MQMD if you plan on providing a MQGMO (for example, for MQGet with Convert). This requirement may be removed in a future fixpack.
3. Check the appropriate check box if you plan on doing a Get by correlation ID or message ID. You will also need to provide that information in the MQMD.
Result: Set the Output data location to OutputRoot
This is what I found in the two race outputs:
The MQInput node in this example also did a Get with Convert and specified a CCSID or 500. This can be seen in both the Properties and the MQMD folders. Other information has been omitted.
(0x01000000):Properties = (
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 500
(0x01000000):MQMD = (
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 500
(0x03000000):Format = ''
-------------------------------------
The Compute node also built (and passed) information in the LocalEnvironment. Note that this is the complete LocalEnvironment from the trace file. If an MQGet by CorrelId had also been needed, then the Compute node would have set that information in the MQMD.
(0x01000000):MQ = (
(0x01000000):GET = (
(0x03000000):QueueName = 'MQGET2 '
(0x03000000):InitialBufferSize = 12
(0x01000000):MQGMO = (
(0x03000000):Version = 1
(0x03000000):Options = 16384
(0x03000000):WaitInterval = 15000
)
(0x01000000):MQMD = (
(0x03000000):CodedCharSetId = 1208
(0x03000000):Format = 'MQSTR '
----------------------------------------------------------------------------------
After the MQGet is completed, the CodedCharSetId information now shows 1208 as the CCSID. Other information has been omitted.
(0x01000000):Properties = (
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 1208
(0x01000000):MQMD = (
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 1208
(0x03000000):Format = 'MQSTR '
------------------------------------------------------------------------------
The LocalEnvironment now contains additional information created by the MQGet Node.
Note that the MQGMO is now fully filled out. In addition, the binary version of the MQMD is included as well as the Condition Code (CC) and Return Code (RC) from the MQGet operation.
(0x01000000):MQ = (
(0x01000000):GET = (
(0x03000000):QueueName = 'MQGET2 '
(0x03000000):InitialBufferSize = 12
(0x01000000):MQGMO = (
(0x03000000):StrucId = X'474d4f20'
(0x03000000):Version = 1
(0x03000000):Options = 16384
(0x03000000):WaitInterval = 15000
(0x03000000):Signal1 = 0
(0x03000000):Signal2 = 0
(0x03000000):ResolvedQName = X'000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
(0x03000000):MatchOptions = 0
(0x03000000):GroupStatus = 32
(0x03000000):SegmentStatus = 32
(0x03000000):Segmentation = 32
(0x03000000):Reserved1 = 32
(0x03000000):MsgToken = X'00000000000000000000000000000000'
(0x03000000):ReturnedLength = -1
)
(0x03000000):MQMD = X'4d442020020000000000000008000000ffffffff0000000022020000b8040000d4d8e2e3d9404040ffffffff0200000000000000000000000000000000000000'... (data of len 364 truncated)'
(0x03000000):CC = 0
(0x03000000):RC = 0
)
)
(0x01000000):MQMD = (
(0x03000000):CodedCharSetId = 1208
(0x03000000):Format = 'MQSTR '
)
)
-----------------------------------------------
End of Example _________________ Bill Matthews |
|
Back to top |
|
 |
GreenLight |
Posted: Thu Jun 28, 2007 5:27 am Post subject: Your doing great job |
|
|
Newbie
Joined: 26 Jun 2007 Posts: 6
|
Hey Bill your really excelent Job using MQGet node ..
I have one question My Flow Like Below
MQinput>>MQTrace>>Compute>>Output>>MQGet>>MQReplay
I got Out put secussfully ...I wnat replay back to sender using MQMD properties(Some 3 only) .in this case MQGet node is usefull or not .If it is usefull where can I modify the Esql code ... |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Thu Jun 28, 2007 7:21 am Post subject: Re: Your doing great job |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
GreenLight wrote: |
Hey Bill your really excelent Job using MQGet node ..
I have one question My Flow Like Below
MQinput>>MQTrace>>Compute>>Output>>MQGet>>MQReplay
I got Out put secussfully ...I wnat replay back to sender using MQMD properties(Some 3 only) .in this case MQGet node is usefull or not .If it is usefull where can I modify the Esql code ... |
I do not understand what you are trying to do. What is the purpose of the MQOutput and MQGet following the Compute node that is followed by a MQReply. This seems to be totally unnecessary. _________________ Bill Matthews |
|
Back to top |
|
 |
GreenLight |
Posted: Thu Jun 28, 2007 9:57 am Post subject: |
|
|
Newbie
Joined: 26 Jun 2007 Posts: 6
|
I am sorry ...
I saw Raghug Req/rep Method I have to test such way REP/REQ flow ...In This case I want replay back to sender after receving the message (Output) with same flow only some fields like QManagername,CoreID ..like that .I used Above flow structure But u said that is not usefull ...Is there any other way Rep/Reqk method structure ... |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Thu Jun 28, 2007 1:29 pm Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
A Request/Reply flow is very simple.
The client application sends a MQ message and in the MQMD sets the ReplyToQ field for the name of the queue to receive the response.
The msg flow gets the message, does its work and then in a Compute node,
after calling the either the Copyheaders or Copy Entire message procedure -
does a Set OutputRoot.MQMD.CorrelId - InputRoot.MQMD.MsgId;
The flow is then connected to a MQReply node that will send the message back to the client application.
------------------------------------------------------------------
Does this describe what you need to do?
------------------------------------------------------------------
I can describe another scenario where the broker sits between the client and a back end service. In this case, the msg flow may need to do some transformation of the original msg and then pass that msg to a backend service. Now, the MQMD ReplyToQ and ReplyToQmgr values need to be pointed to a queue on the broker. Since the msg flow need to save the original information, the MQMD of the original request, ie replyto information, msgid, etc can be saved in the Environment. In this case, the transformed request is sent to the backend and a MQGet is used to retrieve that response, where it is transformed back to what the client needs and the MQMD updated with the information saved in the Environment and then a MQReply is used.
------------------ _________________ Bill Matthews |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 28, 2007 3:01 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
@ Bill & Monk
I followed your stuff but find extremely complicated...
a) If I use a compute node between the MQGet and the MQPut why do I need to do a convert on GET?
The broker holds the Data in Unicode anyway so.
b) I have the data of the MQGet parsed (coming as Cobol) with no conversion needed. I would expect a MessageSet... etc...
c) before the MQOutput node in the compute node I'd specify:
SET OutputRoot.Properties.CodedCharSetId=1208;
My Output should then be in UTF-8 ....
In Fact having to parse data in ccsid 37 or 500 according to a copy book, you better keep it there and not try to parse it from a UTF-8 byte stream.
Special characters like n tilde (Spanish) are single byte chars in ccsid 37 or 500 but multi-byte chars in UTF-8. This would cause a parsing failure...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Thu Jun 28, 2007 4:27 pm Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
The purpose of my example was to illustrate how things could be done with a MQGet - that are not in the documentation - not that they were required ..
In my case, all the messages were in xmlns - with no schemas and thus no message definitions.
The orignal problem was that the data returned that I had to read via an MQGet was in UCS-16 without the ucs marker and was not recognized as such by the MQGet node.
Hopefully together we can help Monk understand what he needs to do... and maybe learn a bit ourselves. _________________ Bill Matthews |
|
Back to top |
|
 |
|