COMP Data item.

[Jayaganesh]

Hi,
Getting arithmetic fault runtime error when a comp data item is
having spaces.
Details :

01 TEMP PIC 9(02) COMP.

Temp = spaces or blank.
SUBTRACT TEMP FROM VAR1 GIVING VAR2 .

Temp data item value is Spaces or Blank . When displayed in inspect
it shows 8224.
What can we do to check the comp data item for spaces .

For eg :.

IF TEMP IS NOT NUMERIC OR SPACES --- this is not working .
MOVE ZEROS TO TEMP.
END-IF

Thanks.

[Jayaganesh]

[Doug Miller]

In article <b66f5fd1-146e-4aa7...@x3g2000yqa.googlegroups.com>, Jayaganesh <jayga...@gmail.com> wrote:
>Hi,
>Getting arithmetic fault runtime error when a comp data item is
>having spaces.
>Details :
>
> 01 TEMP PIC 9(02) COMP.
>
> Temp = spaces or blank.
> SUBTRACT TEMP FROM VAR1 GIVING VAR2 .
>
>Temp data item value is Spaces or Blank . When displayed in inspect
>it shows 8224.

That's because the space character is hex 20. Two spaces obviously is hex
2020, which is decimal 8224.

>What can we do to check the comp data item for spaces .

The *first* thing you should do is find the bug in your program that is
allowing SPACES to be moved to a COMP field. It may be nothing more than your
failure to properly initialize the field (note the VALUE clauses in the
definitions below), or it may be something worse.

01 TEMP PIC 9(2) COMP VALUE ZERO.
01 TEMP-X REDEFINES TEMP PIC X(2).

-or-

01 TEMP-X.
03 TEMP PIC 9(2) COMP VALUE ZERO.

..

IF TEMP-X = SPACES
MOVE ZEROS TO TEMP
END-IF

[hans-fried]

Make:

compute var2 = var1 - temp
on size error
move var1 to var2
end-compute

[Keith Dick]

I imagine the reason for raising the error is that the value in TEMP (8224) is too large for the two digits of the PIC 9(2) declaration. You are lucky that the field was not declared PIC 9(4)COMP -- then you would have just gotten an incorrect result rather than a runtime error.

The reason the test for NOT NUMERIC did not work is that the NUMERIC test only works for fields that are DISPLAY usage, not for COMP fields. If you think about it a minute, I think you will realize that a NUMERIC test against a COMP field doesn't make any sense, since the data in a COMP field is not represented as characters. I am a little surprised that the compiler even accepted it.

I do not know quite what the test against SPACES actually did. The rules for comparing a numeric field with a non-numeric value are not straightforward. I am not surprised that it did not detect the condition, but I cannot precisely explain why it did not detect it.

I completely agree with Doug that the first thing you should do is figure out why spaces are appearing in that COMP field. It almost certainly indicates either a logic error in your program or that you are missing some validation of some input data. Once you find and correct that problem, you should not have to include any test to protect against having spaces in TEMP.

Further, depending on exactly how the alphanumeric data is getting into TEMP, the bad data might not always be spaces, so a test that checks just for spaces might not catch every case of bad data. Further still, just catching the cases where there is a bad value in TEMP and using 0 in place of the bad value is not, in general, a proper solution to the problem. In some situations, it might be the right thing to do, but not in all situations. Without knowing the details of your program, I cannot say whether it is right in your situation.

We cannot tell you where the logic error or missing validation is without studying the program. You are going to have to do that yourself.

There might be some situations in which you really do need to check whether a COMP field, such as your TEMP field, contains spaces. You do that as Doug showed, or any other way that gives you an alphanumeric field that names the same storage as the COMP field does. Then a comparison agains SPACES would work as you expect it should because both items in the comparison would be alphanumeric.