Jim,

I think it's always been this way, actually I've considered this type of
compare to be flaky at best. I prefer to use COMP variables for numeric
comparisons for this very reason.

When you added the sign to your variable you increased the size from 4 bytes to

5. The 5th bytes will hold the sign, however in your example it would be a
space (Decimal 32), which is less than decimal 48 ("0"). Without the COMP
clause the evaluation is actually a string (ASCII) evaluation, looking for "0",

but the 5th byte is a space.

Solution: Move this to a COMP variable before the evaluation.
Then you can decide if it a positive zero, or a negative zero ;-)


--
Michael Anderson.
Houston, Texas.



JIM McINTOSH wrote:

> Hello.
>
> Please consider the following code.  The result is that DATE-ERR-NUM is not
> equal to ZERO.  When the picture is changed to PIC 9(4) (without the
> negative sign), the result is that DATE-ERR-NUM is equal to ZERO.  The
> question is: has it always been thus?  Thanks in advance.
>
> $CONTROL VALIDATE,BOUNDS,CMCALL
>  IDENTIFICATION DIVISION.
>  PROGRAM-ID.    JCMTESTC.
>  AUTHOR.        JC MCINTOSH.
>  DATE-WRITTEN.  DECEMBER 1999.
>  DATE-COMPILED.
>  REMARKS.
>
>  ENVIRONMENT DIVISION.
>  CONFIGURATION SECTION.
>  SOURCE-COMPUTER.  HP-3000.
>  OBJECT-COMPUTER.  HP-3000.
>
>  DATA DIVISION.
>  WORKING-STORAGE SECTION.
>
>  01  DATE-ERR-NUM             PIC 9(4)-.
>
>  PROCEDURE DIVISION.
>  00-MAIN.
>      MOVE ZERO TO DATE-ERR-NUM.
>
>      IF DATE-ERR-NUM NOT = ZERO
>        DISPLAY "NOT ZERO " DATE-ERR-NUM
>      ELSE
>        DISPLAY "ZERO     " DATE-ERR-NUM
>      END-IF.
>
>      STOP RUN.
>
> Jim McIntosh
> Professional Data System, Inc.
> (206) 789-5163
> [log in to unmask]