#964 Low-Values is erroneously accepted as a valid numeric

[Vince Esparza]

Hello,
I have found a failure in the Class Condition test for IF NUMERIC.
Low-Values are being accepted as valid data. Both IBM and Micro Focus
document that the valid range for a numeric is 0-9 (with or without an
operational sign).
I also tested High-Values and it is flagged as invalid. So it seems
only Low-Values are being allowed invalidly.
I am including 3 test programs, but you need to only look at lovalues.cbl.
Thanks, Vince

[Arnold Trembley]

when I compile and run "lovalues.cbl", I do not see any error.

Microsoft Windows [Version 10.0.22631.3447]  2024-04-23  22:13:20
C:\cobol>cobc -V
cobc (GnuCOBOL) 3.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Jul 28 2023 22:59:53
Packaged  Jul 28 2023 17:02:56 UTC
C version (MinGW) "9.2.0"

Microsoft Windows [Version 10.0.22631.3447]  2024-04-23  22:14:15
C:\cobol>lovalues
 Low-Values test
  Valid Numeric Test
  False: Invalid Data Found      <==  It's not numeric
  True: Compare = Zero
 Low-Values test
  Not Spaces And Not Alphabetic
  Test is True

Microsoft Windows [Version 10.0.22631.3447]  2024-04-23  22:14:30
C:\cobol>

[Vince Esparza]

Hello Arnold, Look at the DISPLAY output. GnuCobol says Low-Values are Zero.
MF takes both False paths and says Low-Values are Not Zero. Look as lovalues.jpg for side by side compares. Thanks, Vince

[Vince Esparza]

! Sorry. IF NUMERIC does state it is invalid. Compare to Zero fails. I was checking various condition in the same program.

[Arnold Trembley]

WS1A has picture 9(5) usage DISPLAY, but contains non-numeric data X'0000000000'.

If you compare WS1A to zero, what result would you expect?

A. WS1A equals zero
B. WS1A is NOT equal to zero
C. Program terminates abnormally for WS1A contains invalid non-numeric data
D. Something else?

Apparently Microfocus COBOL chooses B and GnuCOBOL chooses A. I believe certain older IBM mainframe COBOL compilers also chose A (due to S/360 instruction set).

I no longer have access to an IBM Enterprise COBOL compiler for z/OS, so I don't know what IBM's current COBOL compiler would do in this situation. But I know many IBM COBOL applications programmers who are capable of coding applications to prevent problems with invalid data like this.

Kind regards,

[Simon Sobisch]

From what I see:

• invalid DISPLAY data is noted as NOT NUMERIC
• you do get runtime aborts when using invalid display data together with runtime checks -fec=all, or --debug
• the arithmetic value in all places but an "overpunch" only considers the second half byte - so you don't get "strange overflows" and all of low-value, ASCII and EBCDIC ZEROand ASCII and EBCDIC SPACE are handled as zero

I don't see a bug here. Did I miss something?

[Vince Esparza]

Hello, So x'00' and x'20' are taken as x'30' (ASCII or ANSI) since only the right-most half-byte value is used. The mainframe also has this behavior. That explains what is happening. The reason why IBM did that is because the underlying Assembler code used a PACK and UNPK for decimal conversion. Those operations ignored the first half of the numeric byte and so it allowed for a SPACE or LOW-VALUE to be used as a Zero. Thank You! Please close this as a non-bug. Vince