| Author |
Message
|
| KAKEZ |
 Posted: Fri Dec 05, 2003 2:24 am Post subject: URGENT: fixed part of MQRFH2 not converted !!!! |
 |
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi all,
we have the following pb:
- an application on windows 2K send messages with an MQRFH2 header to a remote unix platform
- the receiving appli on unix (hpux) MQGET the message with the option MQGMO_CONVERT
- before sending the message, within the sending appli the following MQMD fields have the values:
CCSID = 850
Encoding=546 -- normal values for windows platfrom
- for the the receiving appli :
+ BEFORE mqget in the MQMD structure the following fiels are:
CCSID=819
encoding=273 -- normal values for unix platfrom
+ AFTER mqget with convert option those fields in the MQMD structure have the values:
CCSID=850
encoding=546 -- again the values for windows platform !
those of windows --> means that the conversion failed !
where is the pb ? because that's a very common mecanim ??
some help/idea is welcome
Jack |
|
| Back to top |
|
 |
| KAKEZ |
| Posted: Fri Dec 05, 2003 2:37 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
to complete the preceeding info:
on the windows appli before sending the message, the value of the MQRFH2 field 'Version' = 02000000
on the receiving appli after mqget the MQRFH2 field 'Version' = 02000000
instead of 00000002 under unix integer representation
more, the in the receiving appli completion code after the mqget is 0 !!!
Jack |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Dec 05, 2003 2:52 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
You are right - and similar to my obserations. Some platform doesn't like RFH2 binary converting (Tandem, HP-UX), that's why my multiplatform applications handling it inside.
This is very strange because Tandem knows RFH2 at API level, but MQGMO_CONVERT give me an error...
We had a lot of misbehavior on HP-UX boxes, independently of CSD level  . By contrast, AIX, Linux, Solaris, etc works fine.
Tibor |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Fri Dec 05, 2003 3:02 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi Tibor,
is that to say that you never succeded to convert the binary fields of the MQRFH2 header when receiving message with MQRFH2 header?
how did you solve the pb?
thanks
Jack |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Dec 05, 2003 3:15 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Hi Jack,
I'm working mostly in C, so I wrote a little function swap32() to handle byte ordering.
In Java it is very simple, just set encoding property because ReadInt() use it.
Tibor
| Code: |
void Swap32( MQLONG *pVal )
{
MQLONG lTemp = *pVal; /* temp var for swapping */
MQLONG *pTemp = &lTemp; /* pointer to temp var */
((MQBYTE*)pVal)[0] = ((MQBYTE*)pTemp)[3];
((MQBYTE*)pVal)[1] = ((MQBYTE*)pTemp)[2];
((MQBYTE*)pVal)[2] = ((MQBYTE*)pTemp)[1];
((MQBYTE*)pVal)[3] = ((MQBYTE*)pTemp)[0];
}
|
|
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Dec 05, 2003 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I'm not 100% clear on what you are trying to do here, but I can tell you that there is a disclaimer in the Application Programming Reference regarding the MQRFH2 and what is and is not converted. Have you looked at this to see if it applies to your situation? |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Fri Dec 05, 2003 6:46 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi grandmaster, thanks replying
- just to resume the pb:
creating a message within an appli under windows2K with MQRFH2 header
& sending this message to an appli running under hpux, the binary fields within the fixed part of MQRFH2 header are not converted to the encoding
of the unix machine
- i give you the exact info extracted from the mqseries documentation:
>>>>>>>>>>>>>>>>>>>>
Application Programming Guide
Chapter 8. MQGMO – Get-message options
page 113
---------------
MQGMO_CONVERT
Convert message data.
This option requests that the application data in the message should be
converted, to conform to the CodedCharSetId and Encoding values specified
in the MsgDesc parameter on the MQGET call, before the data is copied to
the Buffer parameter.
The Format field specified when the message was put is assumed by the
conversion process to identify the nature of the data in the message.
Conversion of the message data is by the queue manager for built-in
formats, and by a user-written exit for other formats. See Appendix F,
“Data conversion”, on page 581 for details of the data-conversion exit.
* If conversion is performed successfully, the CodedCharSetId and Encoding fields specified in the MsgDesc parameter are unchanged on
return from the MQGET call.
----------------- that's exactly the case we get -----------------------------
* If conversion cannot be performed successfully (but the MQGET call
otherwise completes without error), the message data is returned
unconverted, and the CodedCharSetId and Encoding fields in MsgDesc are
set to the values for the unconverted message. The completion code is
MQCC_WARNING in this case.
----------------------------------------------------------------------------
In either case, therefore, these fields describe the character-set identifier
and encoding of the message data that is returned in the Buffer parameter.
<<<<<<<<<<<<<<<<<<<<
remenber that the MQRFH2 data is considered as data by the queue manager
cheers,
Jack |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 05, 2003 7:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| KAKEZ wrote: |
| remenber that the MQRFH2 data is considered as data by the queue manager |
No, no it's not.
From the Application Programming Reference, in the Overview of the MQRFH2 header, there is a section on Character Set and Encoding, as follows
| 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.
|
So some parts of the MQRFH2 header are converted fully, and others are only partially converted. And other parts are not converted at all ("Fields other than NameValueData are in the character set and encoding given by the CodedCharSetId and Encoding fields in the header structure "), as bower5932 said.
_________________
I am *not* the model of the modern major general.
Last edited by jefflowrey on Fri Dec 05, 2003 8:25 am; edited 1 time in total |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Fri Dec 05, 2003 8:04 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi Jeff,
I understand clearly what you says and the doc you refer to but the question is:
why the conversion of the binary fields within MQRFH2 are not converted from windows encoding to unix encoding?
Jack |
|
| Back to top |
|
|
| Tibor |
| Posted: Sat Dec 06, 2003 12:07 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| JeffLowrey wrote: |
| ...So some parts of the MQRFH2 header are converted fully, and others are only partially converted. And other parts are not converted at all (...), as bower5932 said. |
Hi Jeff,
But I don't understand why it isn't true in particular cases? As I wrote in previously I had to make conversion manually, bacause platform.
Tibor |
|
| Back to top |
|
|
|
|
