Re: Why would COBOL act like this?
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 6 Oct 2007 15:49:28 +1300
"Tom" <thasselb@xxxxxxxxx> wrote in message
news:1191632165.666985.110840@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I had an issue surrounding the following COBOL statement. We use LE
COBOL on z/OS.
IF PCT> 0
When the value of PCT, which is defined as PIC 9.99, was 0.00, the
0.00 was greater than 0. This surprised me; I thought a numeric 0.00
should be the same as a numeric 0.
I tried to change the offending statement to
IF PCT> 0.00.
COBOL didn't like that. I got a compile error.
My next approach was to define a constant like so:
05 C-ZERO PIC 9.99 VALUE 0.
COBOL hated that. Another compile error.
My next approach was to define the constant like so:
05 C-ZERO PIC 9.99 VALUE ZERO.
That compiled OK, but the value of C-ZERO was 0000, and I was looking
for 0.00.
The final attempt worked like a charm:
05 W-ZERO PIC 9.99.
MOVE 0 TO W-ZERO
IF PCT > W-ZERO
All of these findings surprised me. I was disappointed that I had to
define a variable and initialize it to zero in the procedure division.
You don't have to do that, Tom. You are missing the difference between a .
in a picture and a V in a picture.
pic 99.9 is an edited string
pic 99v9 is considered to be a decimal number with one implied decimal
place.
Check your manual on the PICTURE clause use of V and . for examples.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Re: Why would COBOL act like this?
- From: Tom
- Re: Why would COBOL act like this?
- References:
- Why would COBOL act like this?
- From: Tom
- Why would COBOL act like this?
- Prev by Date: Re: Do you have a Knowledge Officer?
- Next by Date: Re: Why would COBOL act like this?
- Previous by thread: Why would COBOL act like this?
- Next by thread: Re: Why would COBOL act like this?
- Index(es):
Relevant Pages
|
