View previous topic :: View next topic
|
Author |
Message |
David Vancelette
New User
Joined: 03 Feb 2012 Posts: 3 Location: USA
|
|
|
|
I have an MQ msg coming from a Java platform that triggers a cobol program on our mainframe. The cobol program simply reads a VSAM file with a key supplied in the message, then returns the record via MQ to the Java program. But the returned record contains 4 COMP-2 (floating point) hex fields that apparently are getting scrambled by MQ when it converts EBCDIC to ASCII.
Any ideas on how to correctly convert these 4 COMP-2 fields during the transit from mainframe to Java platform? Is there a way to stop MQ from doing a conversion of EBCDIC to ASCII on only these fields in the message? |
|
Back to top |
|
 |
sergeyken Warnings : 2 Senior Member

Joined: 29 Apr 2008 Posts: 1412
|
|
|
|
Mixture of character fields and binary ones in the same record, when transmitting from one environment to another one, is a bad idea.
Even if you are able to find a non-trivial way how to do this... |
|
Back to top |
|
 |
Rohit Umarjikar
Global Moderator

Joined: 21 Sep 2010 Posts: 2862 Location: NYC,USA
|
|
Back to top |
|
 |
David Vancelette
New User
Joined: 03 Feb 2012 Posts: 3 Location: USA
|
|
|
|
No real reason to not convert to character. I just thought there would be a simple way to keep specified columns of the message from being translated from EBCDIC to ASCII. Then the hex fields could have been converted by a Java routine on the return message.
Since the data has already been corrupted by the time Java does the MQGET, looks like doing the conversion in the cobol program is the best bet.
Anyway, does anyone have a preferred PICTURE string to handle the move of COMP-2 to zoned decimal?
Thanks for the advice! |
|
Back to top |
|
 |
|