Question on IS NUMERIC clause

ravikumar15 · New User Joined: 27 Mar 2006 Posts: 68

Can we use IS NUMERIC clause on COMP (Binary) data item.

Craq Giegerich · Posted: Wed Dec 17, 2008 5:59 pm

Any values in a comp field would be valid, so the test would be worthless.

Robert Sample · Posted: Wed Dec 17, 2008 6:34 pm

From the COBOL Language Reference manual:

hikaps14 · Active User Joined: 02 Sep 2005 Posts: 189 Location: Noida

Hi,

Quoted by robert:

Robert Sample · Posted: Wed Dec 17, 2008 7:12 pm

A COMP variable is always numeric. You cannot have a non-numeric COMP value since it is a 2, 4, or 8 byte field and every possible bit pattern represents a numeric value. Asking if a COMP field is numeric would be like asking if 1 = 1: always gonna be true.

The IS NUMERIC test looks at bit patterns to determine whether or not a variable has numeric bit patterns -- for example COMP-3 fields must have zero through nine in all nibbles (half-bytes) except the last, which must be C, D, or F. An A through F in any nibble except the last is not numeric, so the test would fail -- as it would if the variable had a zero through nine in the last nibble.

hikaps14 · Active User Joined: 02 Sep 2005 Posts: 189 Location: Noida

So, you mean to say that :

Comp can never have any non-numeric values.
Comp-3 can have non-numeric values at times.

I don't know abt Comp but yes, I have seen scenario's where spaces were moved to group level variables and the lower level var were defined as comp-3.

I don't know if the above scenario could be recreated with comp. If we can replicate it on comp. Then we must allow IS NUMERIC on comp fields as well.

Thanks,
-Kapil.

dbzTHEdinosauer · Posted: Wed Dec 17, 2008 8:04 pm

Robert,

have fun with Kapil.
I have tried three posts, but none of them passed the
'am I being an asshole with my comments?' test.

I will have to be content with this remark:

IS NUMERIC will indicate if arithmetic instructions can be used against a field w/o error/abend.
Since any possible content of a BINARY field is valid BINARY data,
any arithmetics would be problem free.

Craq Giegerich · Posted: Wed Dec 17, 2008 8:31 pm

hikaps14 · Active User Joined: 02 Sep 2005 Posts: 189 Location: Noida

Hi,

I would like to thank all of you for your comments and bearing few of my silly questions.

Sometimes things do get stuck in mind. Finally, Craq Giegerich's post made things crystal clear to me.

Apollogise, if I wasted your time.
Thanks,
-Kapil.

dbzTHEdinosauer · Posted: Wed Dec 17, 2008 9:07 pm

Kapil,

you would have wasted our time had you not responded.

Not only have you responded, apparently you now understand,
and that was our goal.

thx for the feedback.

Bill O'Boyle · Posted: Wed Dec 17, 2008 9:25 pm

Here's a series of scenarios which could rear their ugly head and raise a false positive.

Examples -

You issue a NUMERIC check against a 4-Byte COMP-3 Signed field, but for some reason, if the sign-nibble is "F", your NUMERIC check will FAIL.

You issue a NUMERIC check against a 4-Byte COMP-3 Unsigned field, but for some reason, if the sign-nibble is valid but is NOT an "F", your NUMERIC check will FAIL.

This same type of mismatched signs can occur for Signed/Unsigned DISPLAY-NUMERIC.

Unreliable sign-nibbles can occur when you have data passed which was created with different PICTURE clauses. So, if you have this situation and the data is questionable, a definition/redefinition of both types of associated PICTURE clauses will allow you to issue a NUMERIC check against both fields and ensure you don't raise the false positive.

COBOL will build and use different translate-tables, based on PICTURE clause definitions during the NUMERIC check. So (for example), sign-nibble "F" validation is not included in the translate-table when a NUMERIC check is issued against a COMP-3 Signed field and instead, the NOT NUMERIC condition will be raised.

HTH....

Regards,

Bill