| Author |
Message
|
| Sam99 |
 Posted: Wed Oct 10, 2012 10:58 am Post subject: CCSId/Encoding Issue from Mainframe to AIX |
 |
|
Apprentice
Joined: 19 Jul 2012
Posts: 43
|
Hello MB Champs,
I have a MB flow on AIX box which send an xml to a Mainframe system via MQ(Remote queue) and get a response(xml) in another queue(Local Queue), which we pick up using an MQGet node (by correlation Id)
While sending the message we set the Encoding as 285, CCSId as 785 and MQMD.Format as MQFMT_STRING;
Problem :
Mainframe application is not able to change the Encoding and CCSId and is sending the same back to us because of which the MB flow is not able to pick the message from the queue based on correlation Id.
I have read few threads and found below mentioned option,
If I use CONVERT(YES) on the Channel then this problem can be solved but what I understand is this can cause serious problems.
Is there any other option ?
Last edited by Sam99 on Wed Oct 10, 2012 11:11 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 10, 2012 11:08 am Post subject: Re: CCSId/Encoding Issue from Mainframe to AIX |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam99 wrote: |
Problem :
Mainframe application is not able to change the Encoding and CCSId and is sending the same back to us because of which the MB flow is not able to pick the message from the queue based on correlation Id. |
This is not your problem. At least not directly. The correlation id is not a string but a byte array and is never converted between platforms. The hex value of the id remains constant, irrespective of the ccsid or coding in use.
If your design treats it like a string and puts a character value in there, you're in a trap of your own making.
| Sam99 wrote: |
I have read few threads and found below mentioned option,
If I use CONVERT(YES) on the Channel then this problem can be solved but what I understand is this can cause serious problems. |
It can cause serious problems and will not help you. None of the WMQ convert options affect the correlation or message id.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam99 |
| Posted: Wed Oct 10, 2012 12:11 pm Post subject: |
|
|
Apprentice
Joined: 19 Jul 2012
Posts: 43
|
Thanks Vitor,
I am definetly not treating it like a string. - Currently looking into this issue
Meanwhile I have written another flow which picks the messages from this queues and accepts it in BLOB format and then I am using the below mentioned code to convert it.
XML Message Used :
<?xml version="1.0" encoding="UTF-8"?><Data><Uniqueid></Uniqueid><DocOccurence>1</DocOccurence><Errorcode>00</Errorcode><Errormessage>Successful Processing</Errormessage></Data>
Code:
DECLARE pdfBlob REFERENCE TO InputRoot.BLOB.BLOB;
DECLARE inCCSID INT 1208;
DECLARE inEncoding INT 273;
CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(pdfBlob,inEncoding,inCCSID);
But I am getting parsing error. Anything wrong ? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 10, 2012 12:20 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 10, 2012 12:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It does no good to mark an XML message that is stored in a queue under CCSID 732 as being in UTF-8. So you shouldn't be sending them and you shouldn't be trying to parse them.
In general, all of the problems you are experiencing are a direct result of defects in the mainframe program you are talking to.
You should be working with them to resolve the defects in their code, rather than asking for help to fix your correctly configured side of things. |
|
| Back to top |
|
|
| Sam99 |
| Posted: Wed Oct 10, 2012 12:42 pm Post subject: |
|
|
Apprentice
Joined: 19 Jul 2012
Posts: 43
|
When I debug it, I see this,
"XML Parsing Errors have occurred" |
|
| Back to top |
|
|
| Sam99 |
| Posted: Wed Oct 10, 2012 12:54 pm Post subject: |
|
|
Apprentice
Joined: 19 Jul 2012
Posts: 43
|
Thanks mqjeff,
Yes we are talking to them regarding a permanent solution at Mainframe end.
But meanwhile I want to know if I can parse that message(Encoding as 285, CCSId as 785) in MB. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 10, 2012 1:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can only parse it if it's not been corrupted by trying to write UTF-8 data to a 785 character stream.
That corruption would have occured *at the sending application*. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Oct 10, 2012 1:34 pm Post subject: Re: CCSId/Encoding Issue from Mainframe to AIX |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Sam99 wrote: |
| While sending the message we set the Encoding as 285, CCSId as 785 ... |
These seem to be backwards. 285 is not a native encoding for any supported platform, and 785 is not a supported ccsid. Perhaps that should be ccsid=285 (UK EBCDIC) and Encoding=785 (z/OS).
| Sam99 wrote: |
| ... the MB flow is not able to pick the message from the queue based on correlation Id. |
The MQMD.ccsid and MQMD.Encoding does not affect how any of the other MQMD elements are interpreted, particularly BLOB-type elements, such as the correlation id.
| Sam99 wrote: |
| If I use CONVERT(YES) on the Channel then this problem can be solved ... |
It's not clear how this would solve the problem. Please provide more details, such as the MQGET node properties and mainframe message header contents, and any Exception details. |
|
| Back to top |
|
|
| Sam99 |
| Posted: Thu Oct 11, 2012 1:05 am Post subject: |
|
|
Apprentice
Joined: 19 Jul 2012
Posts: 43
|
Thanks rekarm01,
you are right.. That was a typo(sorry about that)
MQMD.Format = MQFMT_STRING;
MQMD.CodedCharSetId = 285;
MQMD.Encoding = 785; |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 11, 2012 2:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Isn't this the old story of the mainframe app not using MQGMO_CONVERT as it should?
The first thing to check is that you have got a valid message. Browse the queue in MO71 with the convert option off (right button menu).
Check the format, ccsid and encoding look correct. Now set convert on (right button menu) and refresh.
Does MO71 convert the messages into a readable form? If not there is something basically wrong with your message data.
Only when you are sure the message is being generated precisely as you wished it to be, should you then send the messages to z/OS and inspect them there. Are they still readable in ISPF? |
|
| Back to top |
|
|
|
|
