ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker (ACE) SupportMsgDesc "2"..

Post new topicReply to topic Goto page 1, 2  Next
MsgDesc "2".. View previous topic :: View next topic
Author Message
guest_2008
PostPosted: Fri May 26, 2006 3:28 am Post subject: MsgDesc "2".. Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

Hi All,

What is the different between the MQMD V1 & V2 message types?

In the payload message we are getting RFH2 header is prefixed with MQMDE header and unable parse the RFH2 header and esql code is failed.

In the payload how we can read or remove the MQMDE header values?

Back to top
View user's profile Send private message Send e-mail
pottas
PostPosted: Fri May 26, 2006 3:50 am Post subject: Reply with quote

Disciple

Joined: 27 Oct 2005
Posts: 185
Location: South Africa

Hi guest_2008,

What is the error you're getting? Please elaborate.

If you're referring to the MQMD, and how to access/manipulate the values in it with esql:

Quote:

SET OutputRoot.MRM.Identifier = InputRoot.MQMD.MsgId;
...or:
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;

...or you can use the RFHUTIL for the above.

for manipulating the MQRFH2 Header:
Quote:

SET OutputRoot.MQRFH2.(MQRFH2.Field)Version = 2;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Format = 'MQSTR';
SET OutputRoot.MQRFH2.(MQRFH2.Field)NameValueCCSID = 1208;
SET OutputRoot.MQRFH2.psc.Command = 'RegSub';
SET OutputRoot.MQRFH2.psc.Topic = "InputRoot"."MRM"."topel";
SET OutputRoot.MQRFH2.psc.QMgrName = 'DebugQM';
SET OutputRoot.MQRFH2.psc.QName = 'PUBOUT';
SET OutputRoot.MQRFH2.psc.RegOpt = 'PersAsPub';


The MQRFH2 header is used to pass messages to and from a message broker belonging to WebSphere Message Broker. The MQRFH2 header follows the MQMD (WebSphere MQ message descriptor) and precedes the message body, if there's a body present.

Hope this helps.
Back to top
View user's profile Send private message
guest_2008
PostPosted: Fri May 26, 2006 9:07 am Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

Hi,

Thanks for your reply...
Now I am able to understand the MQMD version2 structure, actually it is
MQMD2 = MQMD1+MQMDE

I am using the MRM message set and reading payload data for parsing the rfh2 values, the question is, can I use the same MRM for MQMD1 & MQMD2 versions?

If not, what are the fields I have to populate in the MRM for validating the MQMD2 message?

Back to top
View user's profile Send private message Send e-mail
wschutz
PostPosted: Fri May 26, 2006 9:27 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

You shouldn't need to do anything. The MQMD parser in the broker knows where you received a message v1 or v2 and handles it accordingly. Furthermore, you'll only have the MQMDE if fields have been set in it prior to the PUT (like Grouping information)


Is something not working the way you expect?
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
guest_2008
PostPosted: Fri May 26, 2006 12:59 pm Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

Hi Wayne,

Thanks for your mail...

I have message flow which is reading the message and doing the following steps:

1. Using MRM (message set) parsed the MQMD1 version values and removing 424 bytes
2. Remaining payload data (rfh2+application data) stored in the MRM variable, again parsing the rfh2 data, after parsing getting the rfh2 values and inserted the same parsed data’s in the database.

If the message comes with MQMD1 version the flow is processing the message, but MQMD2 version the flow is throwing parser exception…. like "Structure id mismatch”.

I think MQMD2 version extra bytes are not removed from the MRM and the extra bytes are causing the issue while parsing…


Back to top
View user's profile Send private message Send e-mail
wschutz
PostPosted: Fri May 26, 2006 2:48 pm Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Are you saying that you're parsing the MQMD yourself (via a MRM definition)?
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
guest_2008
PostPosted: Sat May 27, 2006 3:45 am Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

Hi,

The logic behind this...

Input message is passed to the input node and MQXQH values are verified using MRM and the same header values loaded into local environment
Input Root = MQXQH and payload in MRM Format.
And my doubt is MQMD 2 header can be verified using the same MRM or required different MRM to validate MQXQH header?

Generally,

MQXQH header length is (MQMD1= XMitQ header + MQMD 1 and total is =104+ 320 = 424

What is the MQXQH header length for MQMD2 header?
I am assuming that
MQXQH header length is(MQMD2) : XMitQ header + MQMD 1+ MQMDE and total is= 104+ 320+72 =496.

Back to top
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Sat May 27, 2006 3:46 am Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

guest_2008 wrote:
What is the MQXQH header length for MQMD2 header?


You shoud not be doing anything with messages that have MQXQH headers on them!

NOTHING.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
wschutz
PostPosted: Sat May 27, 2006 4:00 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

So exactly why are you readying messages with a xmit header on them? I assume you're reading them out of an xmitq.... why??
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
guest_2008
PostPosted: Sat May 27, 2006 4:25 am Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

We are not reading the XMitq valuse but if the message format is MQRFH2, then we are parsing the Rfh2 header to get the usr folder values.

If the application is sending the MQMD 2 message then we are unable to parse the rfh2 header values.

Back to top
View user's profile Send private message Send e-mail
wschutz
PostPosted: Sat May 27, 2006 4:31 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Quote:
Input message is passed to the input node and MQXQH values are verified using MRM
MQXQH==transmission queue header. Please explain whats going on here then. If you have an MQXQH, that (most likely) means you are reading a message directly off a transmission queue, which you shouldn't be doing (as only MQ channels should be reading messages off xmitq's).
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
guest_2008
PostPosted: Sat May 27, 2006 4:48 am Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

See,our design is :

Whatever the message is passing to broker, we are talking the copy of message from channel using channel exit program and it is changing the MQMD & payload information and the same information is stored in the database for logging facility.

If the application is sending the MQMD 2 message then we are unable to parse the rfh2 header values.

Back to top
View user's profile Send private message Send e-mail
wschutz
PostPosted: Sat May 27, 2006 5:21 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

so have the channel exit program strip off the MQXQH before sending it to the broker and then life for you will be much easier, as the broker then can easily handle the mqmd-v2 for you.
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
guest_2008
PostPosted: Sat May 27, 2006 6:15 am Post subject: Reply with quote

Novice

Joined: 25 May 2006
Posts: 14

Thanks for your reply..

I can’t ignore the complete MQXQH and expecting unique values in the AppliIdentitydata field to our meet our business requirement and also the same flow is working fine with MQXQH-MQMD1 header structure, if message contains the MQMDE values in the MQXQH header structure then we are unable to parse the rfh2 header values?

Is it any alternative way to fix the issue in the flow using MRM?
Back to top
View user's profile Send private message Send e-mail
wschutz
PostPosted: Sat May 27, 2006 9:51 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Okay, the mqmd/mqmde parsers are built-in:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac00570_.htm

so you don't need to make your own definition of the mqmd (v1/2). I *think* (becuase I've never tried) that you should be able to strip off the first 104 bytes of the XQH (leaving MQMD1) and then use the CREATE statement with a domain of MQMD to PARSE the remaining payload (including the RFH2 and then your data). See:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ak04950_.htm

Like I said, I've never tried it... let me know how you get on....
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexWebSphere Message Broker (ACE) SupportMsgDesc "2"..
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.