IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Cobol COMP-2 fields getting scrambled by MQ?


IBM Mainframe Forums -> Java & MQSeries
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
David Vancelette

New User


Joined: 03 Feb 2012
Posts: 4
Location: USA

PostPosted: Fri Jan 07, 2022 10:18 pm
Reply with quote

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
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 2011
Location: USA

PostPosted: Fri Jan 07, 2022 11:53 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sat Jan 08, 2022 4:02 am
Reply with quote

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
Back to top
View user's profile Send private message
David Vancelette

New User


Joined: 03 Feb 2012
Posts: 4
Location: USA

PostPosted: Sat Jan 08, 2022 6:01 am
Reply with quote

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
View user's profile Send private message
David Vancelette

New User


Joined: 03 Feb 2012
Posts: 4
Location: USA

PostPosted: Tue Jan 24, 2023 7:26 pm
Reply with quote

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]
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jan 24, 2023 8:00 pm
Reply with quote

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.
Back to top
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 2011
Location: USA

PostPosted: Wed Jan 25, 2023 7:07 am
Reply with quote

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!!!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> Java & MQSeries

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 2
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts Generate random number from range of ... COBOL Programming 3
Search our Forums:

Back to Top