| Author |
Message
|
| ctsaltaf |
 Posted: Thu Apr 14, 2005 2:23 am Post subject: Problem reading RFH2 <usr> NameValue data on Mainframe |
 |
|
Newbie
Joined: 27 Mar 2005
Posts: 7
|
Hi,
We are receiving messages send by a JMS application on to mainframe queue manager (MQ 5.3).
When we try to parse usr information passed in NameValueData field of RFH2 header, I am not able to read it in EBCIDIC character set.
NameValueCCSID on RFH2 is 1208.
Has anyone got any idea how can i convert 1208 format characters into EBCIDIC characters so that i will be able to read an interpret the data in NameValueData field in RFH2.
Urgent response will be highly appreciated.
Thanks
Altaf |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Apr 14, 2005 4:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Application Programming Reference wrote: |
| NameValueData is unusual because it is not converted to the character set specified on the MQGET call when the message is retrieved with the MQGMO_CONVERT option in effect; NameValueData remains in its original character set. However, NameValueData is converted to the encoding specified on the MQGET call. |
It took me two minutes to find this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 14, 2005 4:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also,
| Application Programming Reference wrote: |
Character set and encoding: Special rules apply to the character set and encoding used for the MQRFH2 structure:
* Fields other than NameValueData are in the character set and encoding given by the CodedCharSetId and Encoding fields in the header structure that precedes MQRFH2, or by those fields in the MQMD structure if the MQRFH2 is at the start of the application message data.
The character set must be one that has single-byte characters for the characters that are valid in queue names.
When MQGMO_CONVERT is specified on the MQGET call, the queue manager converts these fields to the requested character set and encoding.
* NameValueData is in the character set given by the NameValueCCSID field. Only certain Unicode character sets are valid for NameValueCCSID (see the description of NameValueCCSID for details).
Some character sets have a representation that is dependent on the encoding. If NameValueCCSID is one of these character sets, NameValueData must be in the same encoding as the other fields in the MQRFH2.
When MQGMO_CONVERT is specified on the MQGET call, the queue manager converts NameValueData to the requested encoding, but does not change its character set. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ctsaltaf |
| Posted: Thu Apr 14, 2005 7:22 am Post subject: Re: Problem reading RFH2 <usr> NameValue data on Mainf |
|
|
Newbie
Joined: 27 Mar 2005
Posts: 7
|
Thanks jeff for your response.
"However, NameValueData is converted to the encoding specified on the MQGET call" -> What does this exactly mean ?
Does it mean that there is no other way other than writing a seperate parser / encoder which could convert incoming Unicode character set into EBCIDIC ?
Thanks a lot
Altaf |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 14, 2005 7:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Encoding is for numeric data. So what that means is that Numeric data will be converted to mainframe numeric formatting, but String data will not be converted to EBCDIC.
I don't know of any other way to convert String data to EBCDIC than writing something that will do the conversion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 14, 2005 7:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The purpose of the RFH header is to facilitate JMS. So why would you want to read / manipulate it in a CCSID not supported by Java ?
Even Java on the MF will support the right CCSID for the JMS header.
Enjoy  |
|
| Back to top |
|
|
|
|
