Re: checking if NUMERIC



"Binyamin Dissen" <postingid@xxxxxxxxxxxxxxxxxx> wrote in message
news:piebh39reol3s00mrelp7n3qqr1upumc9e@xxxxxxxxxx
On Wed, 17 Oct 2007 12:30:33 +1300 "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

:>A numeric field, by definition, should be numeric.

Granted.

:> IBM hardware has
always
:>allowed crap in numeric fields and then interrupted the OS when it is
:>detected.

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
field
in a packed instruction, it must be packed.

:> Therefore, they HAD to allow a Class test on numeric fields
for
:>COBOL, so that programmers could detect the crap and take action to
avoid
:>the program being aborted.

This is so silly that it must have been written by someone with no
knowledge
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
(and
:>several platforms I have worked on did this). It was surprising how
careful
:>programmers became after a few instances of incorrect results being
:>produced...

:>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.

Sure.


:>If a field is defined as ALPHANUMERIC it can hold anything, and it
therefore
:>makes sense to apply a Class test on it. It does NOT make sense to apply
a
:>Class test to a field defined as ALPHABETIC or NUMERIC (because, by
:>definition, the contents MUST be ALPHABETIC or NUMERIC), and the only
reason
:>you need to do so is because of sloppy programming, and the fact that
the
:>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),
but
:>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
an
:>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,
it
was incorrect.

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
a
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
data
:>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
poor
:>programming.

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
language restriction.

Anyway, I made it quite clear that what I said is a personal opinion.

Your disagreement has been noted and filed appropriately :-)

Pete.
--
"I used to write COBOL...now I can do anything."



.

Relevant Pages

  • Re: New Cobol compiler written in Cobol
    ... I don't regard pre-95 Windows as a milestone. ... MY 20 year cycles are based on hardware platform. ... >IBM manufacturing the chips while PS/3 also uses IBM tecnology which ... China doesn't want that, it wants millions of low priced ...
    (comp.lang.cobol)
  • Re: Ten Things I Miss about Big Iron
    ... from ordinary workspace to allow for a raised floor to limit dust and ... floor and went with overhead cable trays. ... through the floor like they had 15 years before with Big VAX hardware. ... programmers or the guys from IBM. ...
    (misc.invest.stocks)
  • Re: XPS to IDS - a positive note for all from the road
    ... than double those from hardware. ... "Maybe IBM should get out of the software business ... If you can't download XPS and play with it, ... their XPS environments to IDS (along with doing POC's against other ...
    (comp.databases.informix)
  • Re: checking if NUMERIC
    ... Certainly every IBM mainframe ... makes sense to apply a Class test on it. ... The reason to validate a field is because the source is suspect. ... ALPHANUMERIC field, which is defined as being able to hold "anything". ...
    (comp.lang.cobol)
  • Re: checking if NUMERIC
    ... Certainly every IBM mainframe ... IBM hardware has always ... so that programmers could detect the crap and take action to avoid ... makes sense to apply a Class test on it. ...
    (comp.lang.cobol)