Re: checking if NUMERIC
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 18 Oct 2007 02:23:51 +1300
"Binyamin Dissen" <postingid@xxxxxxxxxxxxxxxxxx> wrote in message
On Wed, 17 Oct 2007 12:30:33 +1300 "Pete Dashwood"
:>A numeric field, by definition, should be numeric.
:> IBM hardware has
:>allowed crap in numeric fields and then interrupted the OS when it is
IBM hardware does not have a "numeric type" field.
The field type is how it is used. If used as a source or source/result
in a packed instruction, it must be packed.
:> Therefore, they HAD to allow a Class test on numeric fields
:>COBOL, so that programmers could detect the crap and take action to
:>the program being aborted.
This is so silly that it must have been written by someone with no
of IBM hardware.
I worked on this hardware for decades. In BAL and COBOL. I have some
knowledge of it. However, I really don't care about it any more because I am
unlikely to ever work on it again.
Not all non-numeric fields generated invalid packed data. PIC
9(3) with the value "ABC" will not cause a fault.
I know that. What's your point?
The numeric test is to validate externally generated input.
Oh? Says who? I can code it ANYWHERE in a COBOL program on any field that
the compiler will let me. Please be kind enough to cite an IBM publication
which limits it to "externally generated input".
Actually, in a subsequent post I have agreed that that is the most popular
use for it, but COBOL does not require that use.
:>The alternative is to simply let incorrect numeric values be processed
:>several platforms I have worked on did this). It was surprising how
:>programmers became after a few instances of incorrect results being
:>The IBM way is NOT the ONLY way, and some of the alternatives are more
:>logical, although they don't provide the "safety net" that S0C7 does.
The IBM way was one of many ways to generate an undefined result. In fact,
there ain't no way to incorrectly generate an undefined result.
:>If a field is defined as ALPHANUMERIC it can hold anything, and it
:>makes sense to apply a Class test on it. It does NOT make sense to apply
:>Class test to a field defined as ALPHABETIC or NUMERIC (because, by
:>definition, the contents MUST be ALPHABETIC or NUMERIC), and the only
:>you need to do so is because of sloppy programming, and the fact that
:>hardware may crash your program if you don't.
Or the data was mis-entered on a punched card (in the old days) or on the
screen (nowadays). Or the wrong transaction tape was mounted. Etc.
Then why have these types in the Language?
:>Sure, everybody has moved spaces to a group level that included numeric
:>fields, and then suffered the consequences (at least on IBM hardware),
:>that's a good argument for using INITIALIZE.
Spaces (when the last digit of a numeric field) will cause a fault on IBM.
Yes. It won't be the last digit if you use initialize.
:>I remember in the old days you could test a field for numeric, it would
:>pass, and it would STILL be wrong... The test had to be "NUMERIC and
:>POSITIVE" to ensure that zoned sign overpunches were not confused with
:>alphabetic character, inadvertently introduced into the card. Again, an
:>illogical workaround, necessitated by inadequate hardware.
If the PICTURE allows for a sign, an overpunch is correct. If it did not,
That is implied by what I said. I don't disagree.
Also, an overpunch can be positive.
And it is not a hardware issue. By COBOL definition, the results of using
non-numeric in a numeric operation is undefined.
Are you pulling all of this out of your ass?
Why, is that where you're looking for it :-)?
:>For myself, the ONLY time I would use a Class test is on an ALPHANUMERIC
:>field (PIC X).
:>And even then it would probably be because I had lost the plot (or was
:>validating raw input); if you don't know whether the contents of your
:>fields are what they are supposed to be or not, then maybe truck driving
:>might be a better occupation for you... :-)
:>Validation of raw input excepted, to me, using a Class test is simply
That is what it is used for. I don't think folk use class tests for data
validation on master file fields.
As it happens, I don't either. But that is down to common sense and not a
Anyway, I made it quite clear that what I said is a personal opinion.
Your disagreement has been noted and filed appropriately :-)
"I used to write COBOL...now I can do anything."
- Re: checking if NUMERIC
- From: Binyamin Dissen
- Re: checking if NUMERIC
- Prev by Date: Re: checking if NUMERIC
- Next by Date: Re: checking if NUMERIC
- Previous by thread: Re: checking if NUMERIC
- Next by thread: Re: checking if NUMERIC