IS NUMERIC check for SPACES
yogi
I had a question regarding blanks or SPACES in numeric
fields. Would SPACES pass the IS NUMERIC test used for checking if the
value is numeric or not. Since SPACES can be compared arithmetically
(> SPACES), I was wondering if it would pass the IS NUMERIC test.
Thanks in advance
Richard
SPACE is not a numeric digit.
William M. Klein
fail when a field contains spaces. It will also have "unpredictable
results" if a field deinfed as numeric includes spaces when compared to
SPACERS or anything else - at run-time.
HOWEVER, results with specific ompiler may vary. In particular, the use of
the ZWB compiler option (IBM and MF) impacts how USAGE DISPLAY numeric
fields are treaded when some "bytes" contain spaces.
"yogi" <yog...@gmail.com> wrote in message
news:ac1c02d1-64a3-400b...@f16g2000yqm.googlegroups.com...
Howard Brazee
<wmk...@nospam.netcom.com> wrote:
>Easy answer, when running in "standard conformance" mode, IF NUMERIC will
>fail when a field contains spaces. It will also have "unpredictable
>results" if a field deinfed as numeric includes spaces when compared to
>SPACERS or anything else - at run-time.
I never cared for the definition of IF NUMERIC.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison
William M. Klein
it up today) whether the '02 Standard allows an "If numeric" test on a
numeric-edited field, If so, then where the picutre string has "Z" or if
the data definition has "blank when zero", then IF numeric would "pass" when
spaces were in such a field. As I say, I don't remember is this is either
Standard conforming or allowed by any, many, or no compilers - buti it does
make sense for spaces to be "allowed' where the data definition says they
are allowed.
(I am out of town and can't easiy est or research this. If I get a "better"
answer later in the week, I will post that)
"Howard Brazee" <how...@brazee.net> wrote in message
news:9bdah59bd3mm0f2l5...@4ax.com...
Doug Miller
>Hi All,
> I had a question regarding blanks or SPACES in numeric
>fields.
In the time it took you to post this question and read the responses, you
could have written, compiled, and tested a program that would show you the
answer -- and you'd have learned a lot more from doing so than you will by
reading the responses here. Having said that... here are the answers to your
questions:
>Would SPACES pass the IS NUMERIC test used for checking if the
>value is numeric or not.
No. Performing the IS NUMERIC test on a field that contains spaces will
generate an exception.
>Since SPACES can be compared arithmetically
No, it can't.
>(> SPACES),
That's a lexical comparison, *not* an arithmetic comparison. That simply tests
to see whether a particular byte falls before, or after, space in the
collating sequence.
>I was wondering if it would pass the IS NUMERIC test.
Of course not. SPACE is not a numeric digit. Numeric digits are 0 through 9.
Richard
> In article <ac1c02d1-64a3-400b-9c9a-63989d519...@f16g2000yqm.googlegroups.com>, yogi <yogi...@gmail.com> wrote:
>
> >Hi All,
> > I had a question regarding blanks or SPACES in numeric
> >fields.
>
> In the time it took you to post this question and read the responses, you
> could have written, compiled, and tested a program that would show you the
> answer -- and you'd have learned a lot more from doing so than you will by
> reading the responses here. Having said that... here are the answers to your
> questions:
>
> >Would SPACES pass the IS NUMERIC test used for checking if the
> >value is numeric or not.
>
> No. Performing the IS NUMERIC test on a field that contains spaces will
> generate an exception.
The result of the test will be 'false'. 'Generating an exception'
would rather defeat to purpose of doing the test (which can be to
avoid an exception).
>
> >Since SPACES can be compared arithmetically
>
> No, it can't.
>
> >(> SPACES),
>
> That's a lexical comparison, *not* an arithmetic comparison. That simply tests
> to see whether a particular byte falls before, or after, space in the
> collating sequence.
>
> >I was wondering if it would pass the IS NUMERIC test.
>
> Of course not. SPACE is not a numeric digit. Numeric digits are 0 through 9.
Note, however, that the sign representation may lead to other
characters in the field, usually an 'overpunched' digit on the leading
or trailing character or a + or - if 'sign separate'.
docd...@panix.com
Doug Miller <spam...@milmac.com> wrote:
[snip]
>Of course not. SPACE is not a numeric digit. Numeric digits are 0 through 9.
Ow... Mr Miller, it might be best to stay with the question of 'will
(thing) pass an IS NUMERIC test?' and avoid the depths of what constitutes
'numeric digits'. The characters 0 through 9 are, as we all know,
represted in DISPLAY format by the hexadecimal characters X'F0' through
X'F9' (unless one is dealing with ASCII, in which case they are X'C0'
through X'C9') or the binary equivalents 1111 0000 through 1111 1111 (or
ASCII 1100 0000 through 1100 1001).
Now my memory is, admittedly, porous but I recall that IBM mainframe
compilers (IKFCBL00 and IGYCRCTL) will successfully test COMP-3 (packed
decimal format) fields with IS NUMERIC... and as a COMP-3 field, in my
experience, often has its least significant nibble reserved for the
field's sign (usually C for positive, D for negative) then a COMP-3 field
containing X'123D' may pass an IS NUMERIC test while not, by your
standard, containing an numeric digit.
Next week... Are Other Representational Systems Numeric or Not? After
All, This *is* the XXIth Century!
DD
Doug Miller
>On Dec 2, 5:24=A0pm, spamb...@milmac.com (Doug Miller) wrote:
>> In article <ac1c02d1-64a3-400b-9c9a-63989d519...@f16g2000yqm.googlegroups=>> > =A0 =A0 =A0 =A0 =A0 =A0I had a question regarding blanks or SPACES in n=
>umeric
>> >fields.
>>
>> In the time it took you to post this question and read the responses, you
>e
>> answer -- and you'd have learned a lot more from doing so than you will b=
>y
>> reading the responses here. Having said that... here are the answers to y=
>our
>> questions:
>>
>> >Would SPACES pass the IS NUMERIC test used for checking if the
>> >value is numeric or not.
>>
>> No. Performing the IS NUMERIC test on a field that contains spaces will
>> generate an exception.
>
>The result of the test will be 'false'. 'Generating an exception'
>would rather defeat to purpose of doing the test (which can be to
>avoid an exception).
You are of course correct. Serves me right for posting so late at night.
>
>>
>> >Since SPACES can be compared arithmetically
>>
>> No, it can't.
>>
>> >(> SPACES),
>>
>> That's a lexical comparison, *not* an arithmetic comparison. That simply =
>tests
>> to see whether a particular byte falls before, or after, space in the
>> collating sequence.
>>
>> >I was wondering if it would pass the IS NUMERIC test.
>>
>> Of course not. SPACE is not a numeric digit. Numeric digits are 0 through=
Doug Miller
>Now my memory is, admittedly, porous but I recall that IBM mainframe
>compilers (IKFCBL00 and IGYCRCTL) will successfully test COMP-3 (packed
>decimal format) fields with IS NUMERIC... and as a COMP-3 field, in my
>experience, often has its least significant nibble reserved for the
>field's sign (usually C for positive, D for negative) then a COMP-3 field
>containing X'123D' may pass an IS NUMERIC test while not, by your
>standard, containing an numeric digit.
1, 2, and 3 are numeric digits, no? The sign nybble is ignored.
docd...@panix.com
If the sign is ignored then a COMP-3 field containing X'0000' would pass
an IS NUMERIC test... and as I recall - porous memory and all - it
doesn't. COMP (binary) fields, no problem... but COMP-3 needs a valid
sign.
Perhaps some testing is in order.
DD
slade
> In article <hf94sb$aq...@news.eternal-september.org>,
>
> Doug Miller <spamb...@milmac.com> wrote:
> >In article <hf5t5t$og...@reader1.panix.com>, docdw...@panix.com () wrote:
> >>Now my memory is, admittedly, porous but I recall that IBM mainframe
> >>compilers (IKFCBL00 and IGYCRCTL) will successfully test COMP-3 (packed
> >>decimal format) fields with IS NUMERIC... and as a COMP-3 field, in my
> >>experience, often has its least significant nibble reserved for the
> >>field's sign (usually C for positive, D for negative) then a COMP-3 field
> >>containing X'123D' may pass an IS NUMERIC test while not, by your
> >>standard, containing an numeric digit.
>
> >1, 2, and 3 are numeric digits, no? The sign nybble is ignored.
>
> If the sign is ignored then a COMP-3 field containing X'0000' would pass
> an IS NUMERIC test... and as I recall - porous memory and all - it
> doesn't. COMP (binary) fields, no problem... but COMP-3 needs a valid
> sign.
>
> Perhaps some testing is in order.
>
> DD
In an IBM mainframe environment, depending on the NUMPROC/NUMCLS COBOL
compiler options selected, your sign choices are limited, at best, to
X'A" thru X'F'; at worst, to X'F'. Any other nybble will result in a
"FALSE" return from IF NUMERIC.
So, as Doc said, the sign for numeric DISPLAY (and COMP-3) fields is
not ignored; X'F1F203' will generate a "FALSE" return.
If the item is defined w/SIGN IS SEPARATE (not an issue here,
apparently) there are other criteria.
docd...@panix.com
slade <jnj...@optonline.net> wrote:
>On Dec 3, 3:16?pm, docdw...@panix.com () wrote:
>> In article <hf94sb$aq...@news.eternal-september.org>,
>>
>> Doug Miller <spamb...@milmac.com> wrote:
>> >In article <hf5t5t$og...@reader1.panix.com>, docdw...@panix.com () wrote:
>> >>Now my memory is, admittedly, porous but I recall that IBM mainframe
>> >>compilers (IKFCBL00 and IGYCRCTL) will successfully test COMP-3 (packed
>> >>decimal format) fields with IS NUMERIC... and as a COMP-3 field, in my
>> >>experience, often has its least significant nibble reserved for the
>> >>field's sign (usually C for positive, D for negative) then a COMP-3 field
>> >>containing X'123D' may pass an IS NUMERIC test while not, by your
>> >>standard, containing an numeric digit.
>>
>> >1, 2, and 3 are numeric digits, no? The sign nybble is ignored.
>>
>> If the sign is ignored then a COMP-3 field containing X'0000' would pass
>> an IS NUMERIC test... and as I recall - porous memory and all - it
>> sign.
>>
>> Perhaps some testing is in order.
>
>compiler options selected, your sign choices are limited, at best, to
>X'A" thru X'F'; at worst, to X'F'. Any other nybble will result in a
>"FALSE" return from IF NUMERIC.
>
>So, as Doc said, the sign for numeric DISPLAY (and COMP-3) fields is
>not ignored; X'F1F203' will generate a "FALSE" return.
That's as I recall it, aye... but it was from Long Ago and perhaps things
had changed. Has anyone done any testing? If so, might they post the
code and results, so that experiment's reproducibility be verified?
DD