|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Converting from ASCII to EBCDIC format, in Message broker |
« View previous topic :: View next topic » |
Author |
Message
|
Vakku |
Posted: Mon Jan 26, 2009 4:22 am Post subject: Converting from ASCII to EBCDIC format, in Message broker |
|
|
Novice
Joined: 13 Oct 2008 Posts: 20 Location: California
|
Hi,
Using a message flow, I need to convert an XML message into a Cobol copy Book message and needs to place in a directory.
In the copybook, certain fields are mentioned as COMP-3 format. My understanding is that COMP-3 fields are expected to be in EBCDIC format.I need to convert only these fields into EBCDIC format, rest all feilds as ASCII format itself.
I would like to know
1) Is my understanding on COMP-3 correct?
2) Is there any way can this be achieved in broker?
a) By specifying any specific propeties/datatypes in Message set. Will using the datatype as "Packed Decimal" helps in some way?
b) By specifically casting it to EBCDIC Code page(CCSID) for these COMP-3 fields ? Is this a good approach? Any other solutions?
Please help me in this. I'm totally struck up.
Regards,
Vakku. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jan 26, 2009 4:37 am Post subject: Re: Converting from ASCII to EBCDIC format, in Message broke |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Vakku wrote: |
1) Is my understanding on COMP-3 correct? |
No. A COMP-3 is a COBOL datatype reflecting a packed numeric, not a character value. It has nothing to do with ASCII and EBCDIC, except that EBCDIC machines (nearly all mainframes) use different packed numeric encoding.
If you're sending COMP-3 and character fields to an EBCDIC machine, and only converting the COMP-3, the character fields are likely to be gibberish.
Vakku wrote: |
2) Is there any way can this be achieved in broker?
a) By specifying any specific propeties/datatypes in Message set. Will using the datatype as "Packed Decimal" helps in some way? |
COMP-3 fields should only ever be described as packed decimal.
Vakku wrote: |
b) By specifically casting it to EBCDIC Code page(CCSID) for these COMP-3 fields ? Is this a good approach? |
The code page of a message should reflect the code page it's currently in. WMQ uses the "receiver makes good" principle. The reading EBCDIC machine should do the conversion.
And packed decimal fields are controlled by the encoding fields, not the code page. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jan 26, 2009 4:52 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
COMP-3 ( packed decimal ) is a binary format, so the code page has no effect on the writing of a packed decimal. Set OutputRoot.Properties.CodedCharSetId to your ASCII code page, and it should just work. If not, please explain what you tried, and what happened. |
|
Back to top |
|
 |
Vakku |
Posted: Thu Mar 05, 2009 2:05 am Post subject: |
|
|
Novice
Joined: 13 Oct 2008 Posts: 20 Location: California
|
Hi,
I was able to convert the numeric fields into Compressed format as required by Destination mainframe systems(In the CWF message set, I mentioned the datatypes as packed decimal and specified the packing length and Broker is automaticallydoing the packing; whatever fields in the same message, which don't require this compression are written to file as as CHAR data only.
Now I'm stuck up with another problem. While opening the output file which I've generated in some Text editors(Textpad,Notepad++), it looks good, as same as Actual file produced by existing Legacy system.
But when the file is FTP-ed to the mainframes using BINARY mode, the Packed values are appearing correctly in mainframe. But the normal text data is going for the toss. If the use ASCII mode for FTP, the reverse is happening like Packed data is getting corrupted.
What is happening here?Any solutions on this?
1)I found a post stating that this problem can be solved if I construct COMP-3 data as packed Data and Text/ASCII data as EBCDIC and then use BINARY mode for FTP. How will convert to EBCDIC? Does broker provides any built in functions?
2)Will setting the CCSID to 37 specifically, while constructing the Output message wil solve this FTP corruption?My understandig is that 37 is the code page for mainframe systems.Correct me If I'm wrong in this regard.
Regards,
Vakku |
|
Back to top |
|
 |
zpat |
Posted: Thu Mar 05, 2009 3:26 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
It's not corruption - it is ASCII to EBCDIC conversion, which does not work for packed decimal fields!
Either make your message data convertible (all text) or don't convert it!
If you construct a mainframe format message in EBCDIC it will not require conversion and providing that you don't convert it will be OK with packed decimal.
However if you set message MQMD.Format = MQSTR, you are saying that it only contains text data and is convertible.
Much better to not use packed decimal fields in messages for reasons that must be obvious to you now!
Code page 37 is US EBCDIC, other common ones are 500 and 235 (UK). |
|
Back to top |
|
 |
Vakku |
Posted: Thu Mar 05, 2009 4:40 am Post subject: |
|
|
Novice
Joined: 13 Oct 2008 Posts: 20 Location: California
|
Thanks for the reply.
The destination mainframe application willnot be doing the packing of Numeric values. Broker has to Pack it and provide it in packed format to mainframes. So I can't avoid Packing of data in broker.
At the same times, those fields which don't need packing has to be provided in unpacked text format. I was not aware that this packed/Unpacked mix will cause problems:(
This is what I'm doing now. My Output Structure has 2 fields FieldA : Numeric9(Pack it to 5) FieldB:(String)
So in the message set FieldA is made PackedDecimal of length 5. FieldB is made string. In esql, I'm directly mapping it. I'm writing it to a file. So output is appearing correctly, If I view the file in some text editors.But while putting into Mainframes, it was failing for FieldB.
Now I'm added an esql statement to make CCSID to 37. Now the Packed data FieldA is appearing as same as before and FieldB is getting converted into EBCDIC format. So i feel it will serve the purpose. Will post, once we FTP into actual Mainframe and if it works. |
|
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
|
|
|
|