Cobol COMP-2 fields getting scrambled by MQ?

David Vancelette · New User Joined: 03 Feb 2012 Posts: 4 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?

sergeyken · Posted: Fri Jan 07, 2022 11:53 pm

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...

Rohit Umarjikar · Posted: Sat Jan 08, 2022 4:02 am

Try MQGMO_CONVERT- www.ibm.com/docs/en/ibm-mq/7.5?topic=queue-application-data-conversion
But is there a reason you can't send it as readable or char format ?

This might help but you also need help from MQ admin at your site to opine.
www.ibm.com/docs/en/ibm-mq/8.0?topic=objects-data-conversion

David Vancelette · New User Joined: 03 Feb 2012 Posts: 4 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!

David Vancelette · New User Joined: 03 Feb 2012 Posts: 4 Location: USA

Still looking for a numeric edited picture string I can use to MOVE a COMP-2 field to Display edited Numeric. Any takers?

I am currently trying this string: PIC +.9(16)E+99

This string is 22 bytes long. Not getting good results (sort of).

When I move this Comp-2 field to the PIC above I get what looks like good results BUT I have NO IDEA how the conversion took place. I would love to know the STEPS needed to manually convert COMP-2 to Decimal, so I know my code is correct.

COMP-2: 4001 A3D7 0A3D 70A4

Translates to this after a Cobol MOVE:

+.6500000000000000E-01
44FFFFFFFFFFFFFFFFC6FF
EB65000000000000005001

All 3 lines are 22 characters long. The result looks great! But look at the COMP-2 again. How in the WORLD does such a complex-looking number turn into .065? THAT's what I don't get. HOW exactly does one manually convert Comp-2 to display decimal?

Any takers?
[/img]

Robert Sample · Posted: Tue Jan 24, 2023 8:00 pm

Have you looked in the COBOL Language Reference or Programming Guide manuals for details on the format of COMP-2 variables? If not, I recommend starting there.

The format for COMP-1 and COMP-2 variables only varies in the number of bits for the mantissa. The first bit denotes the sign of the value; 0 for positive and 1 for negative. The next 7 bits represent the exponent, which is stored in excess-64 (so X'43' means the exponent is 3 so the value is multiplied by 1000 which is 10 to the 3rd power) and the remainder of the variable contains the mantissa.

Since the bits are significant, you CANNOT convert EBCDIC to ASCII without completely scrambling the value of COMP-1 and COMP-2 variables, not to mention COMP and COMP-3 variables.

sergeyken · Posted: Wed Jan 25, 2023 7:07 am

You need to start from here: IBM hexadecimal floating-point

There is no chance you to reach your goal unless you have learned the basics of the issue.

Both COMP-1, and COMP-2 are IBM internal data formats. You have no chance neither to transfer those data to another platform as it is, nor to "convert from EBCDIC to ASCII" unless having your COMP-2 field(s) converted (or unpacked) to an appropriate character format, defined via PIC without any COMP-n!!!