So here's an "interesting" situation.

000001         000100 identification division.                       000002         000200 program-id. numchek5.                          000003         000300                                                000004         000400 data division.                                 000005         000500 working-storage section.                       000006         000600 01  input-area                value low-values.000007         000700     05  input-number          pic 9(3).        000008         000800                                                000009         000900 procedure division.                            000010         001000     accept input-area                          000011         001100     if input-number = low-values               000012      1  001200         display 'low values'                   000013         001300     else                                       000014      1  001400         display input-number                   000015         001500     end-if                                     000016         001600     goback.                                    000017         001700                                                000018         001800 end program numchek5.                          

Test 1 input
//SYSIN   DD *
123
/*

Test 1 Results
SYSOUT:
123

CEEMSG not present

Test 2 input
//SYSIN   DD *
/*

Test 2 Results
SYSOUT:
low values

CEEMSG:
IGZ0279W The value X'000000' of data item INPUT-NUMBER at the time of reference by statement number 1 on line 11 in program
         NUMCHEK5 failed the NUMERIC class test generated by the NUMCHECK compiler option.                                 

Test 3 input
//SYSIN   DD *
ABC
/*

Test 3 Results
SYSOUT:
ABC

CEEMSG:
IGZ0279W The value X'C1C2C3' of data item INPUT-NUMBER at the time of reference by statement number 1 on line 11 in program
         NUMCHEK5 failed the NUMERIC class test generated by the NUMCHECK compiler option.                                 
IGZ0279W The value X'C1C2C3' of data item INPUT-NUMBER at the time of reference by statement number 1 on line 14 in program
         NUMCHEK5 failed the NUMERIC class test generated by the NUMCHECK compiler option.                                 

Essentially, with NUMCHECK(ZON) being specified, any time the test to low-values is true it also fails the numeric test.  Kind of a conflict there.

Truly, the test should probably be IF INPUT-NUMBER IS NUMERIC.  But as it is it is allowed, even if perhaps it doesn't actually make sense.  An option to do the same test but eliminate the warning is to use reference modification to force it to be an alphanumeric/alphanumeric test:

IF INPUT-NUMBER(1:) = LOW-VALUES

This behaves exactly the same except no implicit numeric test is done, because the refmod casts the numeric item to alphanumeric.

But it still seems to me to be a bit of a conundrum.  Should NUMCHECK in this case not come in to play?  That seems to go against its "definition", but I can't think of any alternative, since this is technically a valid test.

Thoughts?

Frank

LOW-VALUES doesn't make sense for zoned or packed data; x'00000' isn't numeric in either case, because for packed, it has no sign code (e.g. x'00000C'), and for zoned, it has no sign code or zone bits (e.g. x'F0F0C0'). So yes, NUMCHECK is going to identify that as a problem. You can't move LOW-VALUES to a zoned item and then successfully do arithmetic on it, for example, so NUMCHECK should catch it.

As for using reference modification to avoid a NUMCHECK check on the sender, that does kind of make sense, both because of how COBOL V4 handled it (and possibly the language standard as well) and because it would be possible to use reference modification to turn a valid numeric item into an invalid one (such as by including every byte except the final byte, with the sign code); we wouldn't want NUMCHECK to fail in that case.

I agree it may seem a bit odd, but if you think of NUMCHECK as only doing checks when you read the data in a numeric item in a numeric context, that pretty much covers it.

Hi Frank,

Sorry for such a late response on this, but I just wanted to chime in and say that other users have raised this issue as well, and I think there is an argument to be made that we should at least allow users the option to avoid the check in this particular case.  One thing in particular that jumps out at me is that we specifically say in the books that we provide the NOZWB option to allow users to successfully compare display numeric data items to SPACES for pretty much the same reason you show in your example.  We also discuss in the books how a comparison of a zoned decimal item to an alphanumeric item is treated as an alphanumeric comparison with the zoned decimal item being first moved to an alphanumeric temp for the comparison.

Right now, we are exploring a new NUMCHECK suboption (an alternative to ZON) that will still do checking of zoned items but will avoid doing the check when the display numeric item is compared against an alphanumeric literal, including SPACES, LOW-VALUES and HIGH-VALUES.  It's possible we should do it for non-literal alphanumeric items as well, but we're hesitant to water it down too much as it seems the main usage pattern is the one you show above, i.e., the zoned item is initialized to SPACES (or LOW-VALUES) and then later tested to see if it still has that initial value in order to determine if it was set or  not.

Thanks for looking in to this!  Do you think that an additional option is truly necessary, rather than simply changing the behavior of the existing option?  Has anyone said they truly would expect the existing behavior?

It's a fair question. We don't get a lot of complaints about the existing behaviour, to be honest.   One of the things I was considering was tying this behaviour to the NOZWB option, since it seems that if you have a signed zoned decimal item, you cannot reliably compare it to something like SPACES unless NOZWB is in effect; otherwise the sign nibble foils the comparison.  I think this is why there is some resistance to us watering this down too much by default because there still seems to be some recognition that this is a numeric item in this context, even though as I said before we specifically say that we copy the zoned item to an alphanumeric to do an alphanumeric comparison in these cases.

In any case, I moved away from tying this to NOZWB because one of the customers that was interested in this wasn't aware of NOZWB but still wants this behaviour.  Not sure if you use NOZWB or not.  In the end, I don't think it hurts to give people a choice.  We can have "strict" checking by default and, for those who want it, something weaker.  What do you think?

We use ZWB, not NOZWB.  I don't know if we have any cases where we attempt to compare a zoned decimal field to spaces.  Given what you've said about the behavior, I am thinking we don't.

Let me add some context about the reason that we are comparing zoned decimal to low-values.  Basically, we initialize a group (record) field to all low-values.  We then may or may not set a particular item in the group to a value.  Those that are left as low-values are essentially treated as "NULL" (in SQL terms) fields.  We check for this condition in the above manner, and when true we bypass processing of said field.

It just seems to me that there is no reason to check the field for a valid numeric value when you're checking it for low-values (or spaces, I guess).  Too many options sometimes just make it hard to decide on the correct option.  Just one person's opinion.

So it looks like IBM has addressed this issue with the new NUMCHECK(ZON(NOALPHNUM)) suboption.  See PI98480: NEW FUNCTION: ADD TWO NEW SUBOPTIONS TO THE NUMCHECK SUBOPTION ZON - ZON(ALPHNUM) & ZON(NOALPHNUM) (https://www-01.ibm.com/support/docview.wss?uid=swg1PI98480).

Cool!

I hate to look a gift horse in the mouth, but is there a way to turn this option on, leaving the PAC and BIN options?  The default sub-options if NUMCHECK is specified are NUMCHECK(ZON(ALPHNUM),PAC,BIN,MSG).  But in order to specify the NOALPHNUM suboption I have to specify each individual sub-option, i.e.: NUMCHECK(ZON(NOALPHNUM),PAC,BIN,MSG).

One thing I think could make sense would be to have a special compile option BUILD with sub-options like RELEASE and DEBUG.  This could allow specification of different "default" compile options, depending on which BUILD sub-option is chosen.  For example, BUILD(RELEASE) might have:

NOSSRANGE
NONUMCHECK
NOINITCHECK
NOPARMCHECK

While BUILD(DEBUG) might have:

SSRANGE(ZLEN,ABD)
NUMCHECK(ZON(NOALPHNUM),PAC,BIN,MSG)
INITCHECK
PARMCHECK(MSG,100)

These are only examples.  The options that correspond to the build type should be configurable by the customer.

What I imagine is to be able to specify the IGYCOPT macro twice (or thrice?) when building the IGYCDOPT compiler options module.  For example:

         COPY IGYCOPT                                                   
IGYCDOPT CSECT                                                          
IGYCDOPT AMODE ANY                                                      
IGYCDOPT RMODE ANY                                                      
         IGYCOPT BUILD=DEFAULT,                                        X
               [...all default options...]
         IGYCOPT BUILD=RELEASE,                                        X
               SSRANGE=NO,                                             X
               NUMCHECK=NO,                                            X
               INITCHECK=NO,                                           X
               PARMCHECK=NO
         IGYCOPT BUILD=DEBUG,                                          X
               SSRANGE=(ZLEN,ABD),                                     X
               NUMCHECK=(ZON(NOALPHNUM),PAC,BIN,MSG),                  X
               INITCHECK=YES,                                          X
               PARMCHECK=(MSG,100)
         END   IGYCDOPT

If the JCL or source does not specify a BUILD option then only the first set would be utilized.  BUILD(RELEASE) would use both the first and second set, while BUILD(DEBUG) would use the first and third set.

If I open and RFE does this sound like something that might be a possibility?

Frank,

  Anything is possible, but this would be very difficult and require a lot of work on our side.  Besides that, this functionality is already

provided by SCLM, Changeman, RTC, Endevor, etc etc so why re-invent the wheel?

Tom

Just a thought.

Sounds like its not likely to be accepted, so I'll just drop it.

Frank