| Author |
Message
|
| shash |
 Posted: Tue Feb 08, 2005 6:02 pm Post subject: CCSID & Encoding for publishing from z/OS to winnt |
 |
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Hi,
We are writing a pub-sub application where the publisher is a cobol program running on z/OS and the subscriber is a JMS client running on winnt. The broker runs on the winnt machine.
What we have done is define a remote queue on the Queue Manager running on z/OS. This remote queue refers to the SYSTEM.BROKER.DEFAULT.STREAM on the winnt Queue Manager.
The cobol program adds a RFH header to the message indicating that it is a pub-sub message.
I register a subscriber (JMS client) for the topic the cobol program is publishing to. When the cobol program publishes the messages, it goes to the DLQ.
| Quote: |
02/08/2005 12:43:28
AMQ5882: WebSphere MQ Publish/Subscribe broker has written a message to the
dead-letter queue.
EXPLANATION:
The broker has written a message to the dead-letter queue
(SYSTEM.DEAD.LETTER.QUEUE ) for reason
'3023:MQRCCF_MD_FORMAT_ERROR'. Note. To save log space, after the first
occurrence of this message for stream (SYSTEM.BROKER.DEFAULT.STREAM
), it will only be written periodically.
ACTION:
If the message was not deliberately written to the dead-letter queue, for
example by a message broker exit, determine why the message was written to the
dead-letter queue, and resolve the problem that is preventing the message from
being sent to its destination.
|
So the broker is recognizing the message as a pub-sub message and is trying to transfer the message to the subscriber queue, which is SYSTEM.JMS.D.SUBSCRIBER.QUEUE for us.
I went through the other postings on this subject and recognize that the problem can be related to the CCSID and encoding.
The cobol program has set the following property values -
MQMD-FORMAT - 'MQHRF '.
MQMD-ENCODING - 785.
MQMD-CODEDCHARSETID - 0.
MQRFH-ENCODING - 546.
MQRFH-CODEDCHARSETID - 437.
MQRFH-FORMAT - 'MQSTR '.
MQRFH-STRUCLENGTH - 96. (i.e 32 + 64 corresp to length of namevaluestring)
NAMEVALUESTRING - "MQPSCommand Publish MQPSTopic GENERALMESSAGE MQPSPubOpts NoReg ".
TEST-MESSAGE - "Message". (length=7)
So the W00-MSGLENGTH in the following MQPUT call is 96+7=103
Also MQ-HEADER-AND-PAYLOAD in the following MQPUT call is RFH fixed part + NAMEVALUESTRING + TEST-MESSAGE
| Quote: |
CALL 'MQPUT' USING W03-HCONN
W03-HOBJ
MQMD
MQPMO
W00-MSGLENGTH
MQ-HEADER-AND-PAYLOAD
W03-COMPCODE
W03-REASON
|
Please let me know if I am setting the property value of the CCSID and encoding properly.
Thanks,
SHASH |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 08, 2005 7:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do an RFH search on the site. There is only a limited number of CCSID that are "legal" for the RFH2 header.
Check it out. Best bet would be to have the cobol program write the RFH2 header in ASCII (print format ?)
To check out the expected content publish a message from JMS and then analyse its RFH2 header....
Enjoy  |
|
| Back to top |
|
|
| shash |
| Posted: Tue Feb 08, 2005 7:58 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Do we need an RFH2 header?
I thought that RFH (version 1) header is sufficient.
We have successfully tested out the following -
1) A JMS Client publishing a message and a JMS subscriber receiving the message. The JMS message has both RFH (version 1) as well as RFH2 header.
2) A Java client publishing a message using base java MQ API and a JMS subscriber receiving the message. In our code we made sure that the Java publisher (using base API) put only the RFH (version 1) header in the message. Even then the message was published successfully and the JMS subscriber was able to receive the message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 08, 2005 8:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Sorry meant to say RFH header. Lapsus qwerty... |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Feb 09, 2005 10:20 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
MQMD-FORMAT - 'MQHRF '.
MQMD-ENCODING - MQENC_NATIVE .
MQMD-CODEDCHARSETID - MQCCSI_Q_MGR.
MQRFH-ENCODING - MQENC_NATIVE .
MQRFH-CODEDCHARSETID - MQCCSI_INHERIT .
MQRFH-FORMAT - 'MQSTR '.
MQRFH-STRUCLENGTH - 96. (i.e 32 + 64 corresp to length of namevaluestring)
NAMEVALUESTRING - "MQPSCommand Publish MQPSTopic GENERALMESSAGE MQPSPubOpts NoReg ".
TEST-MESSAGE - "Message". (length=7) |
| Quote: |
| MQRFH-ENCODING - 546 |
That's not what you are writing out.
| Quote: |
| MQRFH-CODEDCHARSETID - 437 |
That was saying that your payload was in ASCII, which obviously it wasn't.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| shash |
| Posted: Wed Feb 09, 2005 11:42 am Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Hi Eddie. Thanks for the reply.
I will ask the Cobol programmer to modify the property values and test it out.
However, there is something that is bothering me.
When we set the following values in the Cobol publishing program -
MQMD-ENCODING -> MQENC-NATIVE .
MQMD-CODEDCHARSETID -> MQCCSI-Q-MGR.
MQRFH-ENCODING -> MQENC-NATIVE.
MQRFH-CODEDCHARSETID -> MQCCSI-INHERIT.
it is in a certain characterSet and encoding driven by the z/OS configuration.
The z/OS Queue Manager interprets the message (MQMD as well as the RFH header in the payload) and sends it to the remote queue on the winnt Queue Manager.
When the winnt QM puts the message on the SYSTEM.BROKER.DEFAULT.STREAM, the broker kicks in. The broker will then have to interpret the MQMD and RFH header to figure out the topic information.
So the CCSID and encoding of the message should somehow have to change when the message lands in the winnt QM so that the broker can make sense out of it.
In our sender channel from z/OS QM to winnt QM, we have set
How does the translation work?
Am I missing something here? |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Feb 09, 2005 1:09 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
After re-reading your original post, I'm not so sure what I suggested will cure your problem. However, without my suggestions, the eventual subscriber would be in trouble.
The MD_FORMAT_ERROR points to a problem with the MQMD. What other fields in the MD are being populated by the application. Can you capture a copy of the messagte using amqsbcg, instead of feeding it to the broker.
Refer to my post in http://www.mqseries.net/phpBB2/viewtopic.php?t=20146&highlight=
for a brief description of how the CCSID/encoding works between MQ Headers.
The MQMD is always written in native CCSID/encoding on the platform where the message is PUT. MQ always converts this part when the message flows from system to system. It is up to the application that GETs the message (or the Sender channel) to decide if they want MQ to translate the remainder of the message.
For the broker, and this is complete guesswork, I would imagine that it does not convert the message on GET. It will use the information in the MQMD to internally convert the RFH(2). The resultant subscription will be send out, exactly as received, and the MQMD will have the CCSID/encoding set to the values found in the RFH(2). It is then up to the subscriber to ensure that the message is converted when it is GETted.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| shash |
| Posted: Wed Feb 09, 2005 4:09 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Eddie,
Thanks a bunch for your invaluable help. I changed the CCSID and encoding to what you had suggested.
There was another fatal error we were making in our Cobol code.
The test program we were using was moving MQFMT-STRING TO MQMD-FORMAT after we had set MQMD-FORMAT to 'MQHRF '.
Probably it was inherited from the test program that we choose to copy from.
After the Cobol programmer commented out the offending code, the message was delivered to the subscriber queue and my JMS subscriber was able to read it. We did not have to do any characterset conversion on java side.
Thanks again for your help.
shash |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Feb 09, 2005 4:35 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| we were using was moving MQFMT-STRING TO MQMD-FORMAT after we had set MQMD-FORMAT to 'MQHRF ' |
Which is what probably caused the Format Error. The broker expects all the messages to have an RFH(2) header.
| Quote: |
| We did not have to do any characterset conversion on java side |
Because JMS does it for you "under the covers". But this wouldn't have worked without the CCSID changes I gave you. 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| shash |
| Posted: Wed Feb 09, 2005 5:11 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
You bet. You're the man.
Keep doing the good work. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 09, 2005 5:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do a search on RFH on this site.
A while back there was an extensive post about the CCSIDs admissible on the RFH header for the Value fields.
And CCSID 500 wasn't one of them.
So you really need to change your cobol application to put the value pair information in one of the accepted ccsids.
Enjoy |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Feb 10, 2005 10:03 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| the CCSIDs admissible on the RFH header for the Value fields |
That's only for an RFH2 header. The name/value pairs on an RFH (which is what is being used here) are in the same CCSID as the rest of the RFH header. Which, in some ways, makes them more flexible than an RFH2 if you want to pass User Data between mainframe and distributed platforms.
So, the COBOL application is good to go, as-is.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 10, 2005 2:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
But are you sure that the pub/sub engine (essentially a JMS construct => Java) will accept and translate/process a value pair that is not in any of the "approved" CCSIDs ??
Confused |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Feb 10, 2005 2:58 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| not in any of the "approved" CCSIDs |
There are no "approved" CCSIDs for an RFH.
From the manual, for RFH:
| Quote: |
Character set and encoding: The fields in the MQRFH structure (including NameValueString) are in the character set and encoding given by the CodedCharSetId and Encoding fields in the header structure that precedes the MQRFH, or by those fields in the MQMD structure if the MQRFH 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. |
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 10, 2005 8:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So why do we have an RFH2 which forces the CCSID of the value pair to a few select ones and allows you to have a different CCSID for your RFH2 header and the Value pairs on it ?
My understanding is that the sole purpose of such a setup is to force the CCSID of the value pair to something that the broker (using java) will be able to interpret without having to undergo too much of a translation effort and preserve the CCSID of the rest Header and Data so that if your broker just does routing and no transformation the final destination will do the CCSID translation -- once only.
Am I missing anything vital there ?
Still confused.  |
|
| Back to top |
|
|
|
|
