Hi Paul,
Regarding question 1; I don't really need to know what every bit is for,
but I am certain there is a length and codepage in the TSH header. I can
tell from the AIX qmanger trace that MQ looks at the inbound stream on the
channel and translates the first x'76' bytes of the message. This x'76'
bytes includes the TSH header and part of the MD. Like I said, I was just
looking for some of the basic fields.

Regarding question 2; well, please take another look at the question, which
I have included below with a few more qualifications...
2) I have a WEB application that is initiated by COM+ on Win2000 and calls
DB2 and MQSeries using the MQ Client. This application MQPuts a message to
an AIX qmanager. The MD.CodedCharSetId is set to MQCCSI_Q_QMGR (zero). In
the Win2000 registry of the MQClient server at
HKLM\SYTEM\CurrentControlSet\Control\NLS\CodePage I have:
   ACP (Windows ASCII codepage)=1252
   OEMCP (DOS, cmd.exe codepage)=437
When I trace a MQPut from this client to the AIX qmanager, the TCP receive
of a message has a TSH header with a codepage=437 and the MD has a
codepage=0.  MQ translates part of the transmission using 437 -> 819 and
determines this is a MQPut. MQ then "puts" the message on the queue, but
has now plugged in a codepage of 437 in the MD - presumably defaulting to
the codepage from the TSH header.
Here is a snipet from the qmanager trace:
      MQS Receiving Data
            54534820 000004C5 02863000 00000000 TSH
                        00000000 11010000 B5010000 000004C5
                                00000000 00000000 F8583320 4D442020 MD
                                01000000 00000000 01000000 70170000 
                                00000000 22020000 00000000 4D515354 MQST
                                52202020 FFFFFFFF 02000000 00000000 R
ÃÃÃÃ
                                00000000 00000000 00000000 00000000
                                00000000 00000000 00000000 00000000
                                00000000 00000000 00000000 00000000
                                4D464E2  . . . ..
            fromCCSID:437 toCCSID:819, in length:76, out length:76
            30E 108031      3.633820502       0.003892   translated out
length:76

from the trace segment above you can see that the code page in the TSH
header is x'01b5' / 437 and the MD.CodedCharSetId is zero. The length of
the translation, x'76' will cover the TSH and part of the first part of the
message, that in this example includes the MD.

QUESTION is, why is this 437 instead of 1252?  Initially I thought it was
because DB2CODEPAGE on the MQ client (i.e, the WEB server) was 437, but I
removed this setting and restarted DB2 and IIS where the client is ruuning
but still get 437 assigned to the MQ messages. It seems that the Win2000
WEB application should be running as codepage 1252 since ACP=1252 in the
registry.
Thanks again,
Rick




                                                                                       
                       
                                                                                       
                       
              Paul Clarke                      To:       [EMAIL PROTECTED]             
                 
              <[EMAIL PROTECTED]>        cc:                                           
                 
              Sent by: MQSeries List           Subject:  Re: CCSID and TSH header      
                       
              <[EMAIL PROTECTED]>                                                      
                 
                                                                                       
                       
              03/24/2004 01:05 PM                                                      
                       
                                                                                       
                       
              Please respond to MQSeries                                               
                       
              List                                                                     
                       
                                                                                       
                       
                                                                                       
                       
                                                                                       
                       




Rick,

Sorry to hear IBM has 'missed the mark'. I'm slightly nervous that I too
will miss; believe me it's not intentional.

1/ IBM does not publish the format of the data it flows either between
Queue Managers or Queue Managers and a client. This is not because we're
trying to be awkward but to prevent anyone from getting 'tied in' to one
way of working. We do publish the meaning of the 10th bit (99 in this case)
in one of the manuals. Anyway, 99 is an MQINQ response. The application is
actually issuing an MQINQ on the current depth of the queue.

2/ In general message conversion is done at MQGET time when the
MQGMO_CONVERT option is used. For clients though, life is a little more
awkward. Firstly you have the problem of what codepage to assume is the
default. On the server it's easy because you can use the QM's codepage.
However, on a client the QM's codepage may well be meaningless so we use
the codepage of the machine (exactly how this is calculated varies by
platform). You can, if you choose, override this value with an MQCCSID
environment variable. Now, when the message arrives on the server we check
whether the client has used any MQ headers in its message (such as MQMDE or
MQDH etc). These headers should always be in the codepage of the Queue
Manager so if we find them we convert them accordingly. This code is fairly
complex since we have to ensure the chain of Format/CCSID/Encoding is
maintained and the structures may well not be byteswapped for the platform
we're on. Anyway, there were some problems in the early versions of the
product for some combinations, I'm talking pre-5.2 here so these should be
fixed. However, there may be problems I'm unaware of.

If you like you could send me your server trace  and I will see whether I
see anything odd in it if you like. You should also tell me what your AIX
QM CCSID is since that is what it should be translating too,

Cheers,
P.

Paul G Clarke
WebSphere MQ Development
IBM Hursley




|    Rick Miles
|    <[EMAIL PROTECTED]>
|    Sent by: MQSeries List <[EMAIL PROTECTED]>

|       To:       [EMAIL PROTECTED]

|       Subject:  CCSID and TSH header



Hi all, I have 2 questions that I cannot seem to find an answer to - seems
as though IBM does not understand the question and continues to miss the
mark.
1) What is the format of the TCP TSH header you see in a trace?  For
example:
             Receiving Data:-
         54 53 48 20 00 00 00 40 02 99 30 00 00 00 00 00  : TSH
[EMAIL PROTECTED]
         00 00 00 00 11 03 00 00 B5 01 00 00 00 00 00 40  :
........Â......@
         00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00  :
................
         01 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00  :
................

2) I have a WEB application that is initiated by COM+ on Win2000 and calls
DB2 and MQSeries. This application MQPuts a message to an AIX queue. The
MD.CodedCharSetId is set to MQCCSI_Q_QMGR (zero). In the Win2000 registry
at HKLM\SYTEM\CurrentControlSet\Control\NLS\CodePage I have ACP (Windows
ASCII codepage)=1252, OEMCP (DOS, cmd.exe codepage)=437.
When I trace a MQPut from this client to AIX, the TCP receive of a message
has a TSH header with a codepage=437 and the MD has a codepage=0.  MQ
translates part of the transmission using 437 -> 819 and determines this is
a MQPut. MQ then "puts" the message on the queue, but has now plugged in a
codepage of 437 in the MD - presumably defaulting to the codepage from the
TSH header.
QUESTION is, why is this 437 instead of 1252?  Initially I thought it was
because DB2CODEPAGE was 437, but I removed this setting and restarted DB2
and IIS where the client is ruuning  but still get 437 assigned to the MQ
messages.

Thanks for any insights.
Rick'²ÚîrØžÇè®f§j§ƒ*.®f¢–)à–+-²æìr¸©¶*'j·©®‹âuçbžØ^.+-±êïéÞ©T±êìèy«ÚV›•æÛiÿü0Â[(~×(˜
Ü+ÞÛiÿûæjHp‰éÚq«1ž®'¬j·!Š÷

Reply via email to