Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Evaluating COBOL expression gives unexpected result

SOLVED
Go to solution
Homer Shoemaker
Frequent Advisor

Evaluating COBOL expression gives unexpected result

I'm probably missing something basic here. Please help if you can.

AlphaServer 800 5/333
OpenVMS V7.1-1H2
DEC COBOL V2.4
OpenVMS Alpha DEBUG Version V7.1-000

I'm not getting branching in my program the way I'm expecting to. I compare a variable whose value is zero (according to debug examine and evaluate)to see if it's less than one. Then if it is less than one, I move the value one to one of the variables.

Anyway, if you look at the debug list attached, the system is evaluating 0 < 1 as FALSE.

Both variables are PIC 9(3).

Although one is a redefine of a PIC X(3).
12 REPLIES
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

Trying again to post the attachment.
Hoff
Honored Contributor

Re: Evaluating COBOL expression gives unexpected result

Please try your COBOL test code over on EISNER:: (DECUServe), or on the HP test drive systems.

EISNER:: has COBOL 2.8 and OpenVMS Alpha V8.3.

Or post up a concise source code example reproducer of what you're doing here.
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

I think I found a clue using the debug evaluate /bin (/hex /dec).

DBG> ev ORDER-BATCH-PS-PRINT-RUN
0

DBG> ev /hex ORDER-BATCH-PS-PRINT-RUN
202020

DBG> ev /bin ORDER-BATCH-PS-PRINT-RUN
00100000 0010000000100000

DBG> ev /dec ORDER-BATCH-PS-PRINT-RUN
2105376

I'll post again when I'm sure.
Hoff
Honored Contributor
Solution

Re: Evaluating COBOL expression gives unexpected result

0x0202020 is ASCII spaces, which can point to a buffer overrun or to a variable that contains string data.
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

The ASCII spaces is what I'm checking into.

I'm getting the data from the rededined field and it previously had no data (undefined or spaces). Some records will have had the new numeric data written to the field and some not.

Looks like I can't test that field to determine whether it's been updated or not.

Let me make sure.

Thanks Hoff.
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

Okay, that was it.

I thought that if I referred to the redefined (numeric) name in the expression, that the compiler would know to change the spaces to a zero. Or at least complain.

NOPE.

John Reagan
Respected Contributor

Re: Evaluating COBOL expression gives unexpected result

Think of REDEFINES as a C UNION or Pascal variant-record. Multiple names for the same piece of memory. The compiler really has no way of knowing what you've last shoved into the memory. There is no invisible conversion behind your back.
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

Thanks John, and now that I think of it, I'm pretty sure we actually take advantage of that behavior on occasion.

Sometimes you just get stuck, and it helps just to define what you're seeing well enough to ask for help.

Turns out that in this case, if the redefined field hasn't been updated with numeric data then it always contains spaces.

So my comparison needed to be:

if redefined-variable = spaces

instead of

if redefined-variable < 1
Dennis Handly
Acclaimed Contributor

Re: Evaluating COBOL expression gives unexpected result

>John: Think of REDEFINES as a C UNION or Pascal variant-record.

Level 66 RENAMES also is like that.
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

Thanks Dennis. Interesting. I didn't know that. I've never had occasion to use a level 66 item. I'll look into it.

Richard J Maher
Trusted Contributor

Re: Evaluating COBOL expression gives unexpected result

Hi Homer,

Don't forget IS NUMERIC and INSPECT REPLACEING ALL.

To expect the compiler to produce more than a compile-time error when performing some sort of Java casting or generics check would, IMHO, be a worthless exercise.

You're just mapping a chunck of memory, and COBOL, like most other 3GLS, let's you describe it however you like. Works for me.

Cheers Richard Maher
Homer Shoemaker
Frequent Advisor

Re: Evaluating COBOL expression gives unexpected result

Thanks Richard. I considered the IS NOT NUMERIC solution after I had already moved on to the next section of code, but I'll probably go back. That's probably a better solution than checking for spaces.