Generated code differences in COBOL

Why would cause a difference in generated code for IF FIELDA > 0 GO TO A-EXIT.? FIELDA is defined as PIC 9(8). if compiled in Endevor the generated code is L 5,412(0,9) MVC 720(8,13),4012(5) OI 727(13),X'F0' CLC 720(8,13),21(12) BC 13,3812(0,11) and it compares to 'F0F0F0F0F0F0F0F0' compiled outside of Endevor, we get PACK 720(5,13),4012(8,4) CP 720(5,13),24(1,12) BC 13,3744(0,11) and it compares to '0C' Obviously, the second case abends if the field is not initialized properly. Both processes use the Enterprise COBOL for z/OS and OS/390 3.2.1 compiler. The compiler options appear to be the same in both cases. Any insight would be helpful. Thanks

Answer Wiki

Thanks. We'll let you know when a new response is added.

Its been a long time since I used cobol, but here goes. The F0F0F0 compare is a string compare. And the other looks like a numeric compare with a packed decimal (0C). It probably the zero you’re comparing to FieldA. To fix this we normally used a constant of the same datatype as FieldA, for example:
05 KN-ZERO PIC 9(8) Value 0.

Then and did someting like this: if FieldA > KN-ZERO

To get different machine code it must be a complier option that is different. That is the only explanation I can think of.

Good luck

Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Mrmullins
    It has to be either a compiler option, or a difference in the field definition. Check SYSLIB concatenations between Endeavor and non-Endeavor. Kind regards, Ray Mullins
    0 pointsBadges:
  • Fskovacs
    As it were, for the NUMPROC option, the default value where I am (MIG) is different from what is provided by IBM (NOPFD). What MIG does is force all numeric compares to be decimal compares as opposed to logical compares. Thanks for your help
    0 pointsBadges:
  • LeahDawn
    I'm not familiar with Endevor, but, it appears that when the assembler code is generated for the Endevor, it is designed to treat a blank in the numeric field as a zero to surpress abends and does a character compare. Where as the other version uses a compare packed to do so. This could explain why we have abends in our software that others do not when fields aren't initialized to zero.
    0 pointsBadges:
  • GeneInAK
    As mentioned by another previously, you could try declaring a variable of the same type as FieldA Pic S9(3) value +0. Notice the sign of 0 is positive, the sign bit could be your problem.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: