| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RFH2 Format Field not converted |
« View previous topic :: View next topic » |
| Author |
Message
|
| migstr |
 Posted: Thu Sep 04, 2003 7:37 pm Post subject: RFH2 Format Field not converted |
 |
|
Apprentice
Joined: 05 Jun 2002
Posts: 34
Location: New York
|
Hello,
I have message:
MQMD + MQRFH2 + MQHSAP + DATA
I need to strip off the MQRFH2 and print it's contents and put MQMD+MQHSAP+DATA back on source queue. Message is 819, QMRG 500.
So I do Get w/Convert and get 2110. Ok, I handle it assuming RFH2 has been converted but not MQHSAP+DATA. I need to take the RFH2.FORMAT field and put it in the new MQMD. But when I print the RFH2.FORMAT it is still showing as ASCII, not EBCIDIC. I thought it would have converted it since its a MQCHAR8 field. Can anyone tell me if the RFH2.FORMAT field gets converted on a GET?
_________________
Thanks, Margaret
-------------------------------------------------------
IBM Certified Specialist - MQSeries, Websphere MQ Integrator
IBM Certified Solutions Expert - MQSeries, Websphere MQ Integrator
IBM Certified Developer - MQSeries |
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri Sep 05, 2003 8:47 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Because of the 2110, the message is not converted. I believe that the GET with convert will try and convert the entire message, not just the 1st header.
What is the format of the data. Does the MQHSAP have the right format name in it. If it's not MQSTR, do you have a conversion routine for it.
Take a look in the Error logs to see if that points to which part of the convert failed.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| migstr |
| Posted: Fri Sep 05, 2003 10:38 am Post subject: |
|
|
Apprentice
Joined: 05 Jun 2002
Posts: 34
Location: New York
|
Hi, I don't care if the message data does not get converted, I just need the RFH2 converted because the RFH2 structure tells me how long the name value data is and the 'format' of the data following it. I need to strip off the RFH2 w/name value data, print it, and then put original message back on source queue with the correct format in the MD format field.
According to App Ref manual for 2110: "If the message consists of several parts (like DLH), each of which is described by it's own CCSID and Encoding, some parts may be converted and other parts may not be converted. "
I don't know maybe this isn't possible. But I'm assuming it's converting parts of the RFH2 because I can read the MQLONG fields just fine. Maybe when it converts the RFH2 Format field it checks whether it's a common format (and MQHSAP is not on 390) and therefore does not do anything with it? not sure. I should try with another format to see.
_________________
Thanks, Margaret
-------------------------------------------------------
IBM Certified Specialist - MQSeries, Websphere MQ Integrator
IBM Certified Solutions Expert - MQSeries, Websphere MQ Integrator
IBM Certified Developer - MQSeries |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Sep 05, 2003 12:36 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
The important word in that description is "may". The fact that the Format name hasn't been converted means that none of the header has, as you will get either all the header converted or none.
Unfortunately, there is no way to tell MQSeries that you only want part of the payload converted. It will always try to convert all.
Again, look in the logs to see if there is a message telling you which part failed. From your comment about the MQHSAP, I'm guessing that it might be the culprit. Could you convert in the channel on the way to the mainframe from the platform that does understand this header. That's how the CICS bridge works where only the mainframe knows the formats.
The reason that you can read the MQLONG fields is because the way the values are actually held on Solaris (I think that's the 819 CCSID) and the mainframe are both the same 'endian-ness'. You would have problems if the 2 ends were different: Intel and mainframe.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
