View previous topic :: View next topic
|
Author |
Message |
lcmontanez
New User
Joined: 19 Jun 2007 Posts: 50 Location: Chicago
|
|
|
|
Is there a compiler option or version that will accept a
05 SAVED-WALG-DEPT-NUMBER PIC 99.
field with X'40F0' as equal to zero?
IF SAVED-WALG-DEPT-NUMBER = ZERO
PERFORM BUILD-MB180203 THRU BUILD-MB180203-EXIT
GO TO BUILD-MB180200-EXIT.
I expected the alpha numeric field to be not equal and therefore
the build not be performed but instead the build actually occured? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
You could set an 88 level, but I'm not aware of any option to cause COBOL to treat X'40F0' as zero. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
You said, "alpha numeric field", but the field you show is numeric; which is it? Please paste exact definition, not a keyed version. |
|
Back to top |
|
|
lcmontanez
New User
Joined: 19 Jun 2007 Posts: 50 Location: Chicago
|
|
|
|
The field is defined as numeric PIC 99 although the value is X'40F0' which
is alpha.
Cobol is not complaing/erroring out on having a blank in a numeric field. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
you should have:
Code: |
IF SAVED-WALG-DEPT-NUMBER NUMERIC
THEN
IF SAVED-WALG-DEPT-NUMBER = ZERO
PERFORM BUILD-MB180203 THRU BUILD-MB180203-EXIT
GO TO BUILD-MB180200-EXIT
END-IF
ELSE
PERFORM SAVED-WALG-DEPT-NUMBER-INVALID
GO TO BUILD-MB180200-EXIT
END-IF.
|
NUMERIC DISPLAY (PIC 9) is famous for allowing any bullshit to be
mathematically manipulated without error.
my advice:
never use a NUMERIC DISPLAY field without first checking for NUMERIC |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Absolutely what Dick says about not using numeric display fields (and also not moving to a numeric display field unless you know for a fact that the sending data is numeric) -- somebody moved a variable with spaces to the field, and COBOL moved the two blanks in, then did the unsigned conversion to ensure the last byte is F0, and voila you have X'40F0' in a numeric field. |
|
Back to top |
|
|
lcmontanez
New User
Joined: 19 Jun 2007 Posts: 50 Location: Chicago
|
|
|
|
Thank you all for your comments.
I was more concern how the old process BASEV programs (combines Cobol/assem Arthur Anderson technique) would process a X'40F0' as
equal to zero but Cobol II was not (expected result).
I thought this was due to a compiler option or release version. |
|
Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
|
|
|
|
lcmontanez wrote: |
I was more concern how the old process BASEV programs (combines Cobol/assem Arthur Anderson technique) would process a X'40F0' as equal to zero but Cobol II was not (expected result).
I thought this was due to a compiler option or release version. |
No, probably the BASEV used a packed compare (since a PACK instruction would lose the 4) vs COBOL probably just does a character compare. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Quote: |
Arthur Anderson technique |
ah! there's your problem. |
|
Back to top |
|
|
|