topic Re: Evaluating COBOL expression gives unexpected result in Operating System - OpenVMS

Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Wed, 18 Jun 2008 19:10:57 GMT

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

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Wed, 18 Jun 2008 19:13:04 GMT

Trying again to post the attachment.

Re: Evaluating COBOL expression gives unexpected result

Hoff — Wed, 18 Jun 2008 19:30:27 GMT

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.

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Wed, 18 Jun 2008 19:35:06 GMT

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.

Re: Evaluating COBOL expression gives unexpected result

Hoff — Wed, 18 Jun 2008 19:51:35 GMT

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

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Wed, 18 Jun 2008 19:59:15 GMT

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.

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Wed, 18 Jun 2008 20:13:14 GMT

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.

Re: Evaluating COBOL expression gives unexpected result

John Reagan — Fri, 20 Jun 2008 11:21:05 GMT

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.

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Fri, 20 Jun 2008 12:50:43 GMT

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

Re: Evaluating COBOL expression gives unexpected result

Dennis Handly — Fri, 20 Jun 2008 14:51:17 GMT

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

Level 66 RENAMES also is like that.

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Fri, 20 Jun 2008 17:03:42 GMT

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

Re: Evaluating COBOL expression gives unexpected result

Richard J Maher — Sat, 21 Jun 2008 09:36:36 GMT

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

Re: Evaluating COBOL expression gives unexpected result

Homer Shoemaker — Mon, 23 Jun 2008 15:17:54 GMT

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.