checking if NUMERIC

On Wed, 10 Oct 2007 09:13:26 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>if you're just asking if the field is "NUMERIC".  Therefore, we had to
>define the numeric field as alphanumeric (or as a group level field) and
>then if this definition was numeric we could then access the field using it
s
>
>numeric definition.  A real pain.  It sounds like VSE/ESA has this problem
>sorted."
>
>This does not appear to me to be accurate.  Can anyone shed some light on
>the subject?

Maybe it's a mainframe issue - I have been doing so for years (not
tested lately) because I found this to be a requirement.

Howard,
What have you been doing for years?  Certainly every IBM mainframe compilers
for YEARS has allowed for the IF NUMERIC test on numeric fields.

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
 news:3pn9h31b1pfdn8e5ie4r0ml8hh0fq0gest@
4ax.com...
> On Wed, 10 Oct 2007 09:13:26 -0600, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
> 
>
> Maybe it's a mainframe issue - I have been doing so for years (not
> tested lately) because I found this to be a requirement.

On Tue, 16 Oct 2007 19:55:17 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Howard,
>  What have you been doing for years?  Certainly every IBM mainframe compil
ers
>for YEARS has allowed for the IF NUMERIC test on numeric fields.

I might have used a different compiler on a different computer when I
developed this habit.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:EG8Ri.134871$zt4.81850@fe08.news.easynews.com...
> Howard,
>  What have you been doing for years?  Certainly every IBM mainframe
> compilers for YEARS has allowed for the IF NUMERIC test on numeric fields.
>

Yes, they have, and it is totally illogical.

A numeric field, by definition, should be numeric. IBM hardware has  always
allowed crap in numeric fields and then interrupted the OS when it is
detected. 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.

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.

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.

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.

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  with an
alphabetic character, inadvertently introduced into the card. Again, an
illogical workaround, necessitated by inadequate hardware.

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.

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


> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Howard Brazee" <howard@brazee.net> wrote in message
>  news:3pn9h31b1pfdn8e5ie4r0ml8hh0fq0gest@
4ax.com... 
>
>

"Howard Brazee" <howard@brazee.net> wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> 
>
> I might have used a different compiler on a different computer when I
> developed this habit.

A number of years ago (10-20?) I remember having a problem with one
COBOL compiler where invalid (non numeric) data caused a program fault
when you tested a display numeric item for "IF NUMERIC". It worked if
it was only the zone bits that were wrong, but if you had a hex value of
A-F in the numeric bits, the program crashed. IIRC, it was the Unisys A
Series COBOL74 compiler.
--
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

On Wed, 17 Oct 2007 12:30:33 +1300, "Pete Dashwood" <dashwood@removethis.ent
ernet.co.nz>
wrote:

>
>
>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>news:EG8Ri.134871$zt4.81850@fe08.news.easynews.com... 
>
>Yes, they have, and it is totally illogical.
>
>A numeric field, by definition, should be numeric. IBM hardware has  always
>allowed crap in numeric fields and then interrupted the OS when it is
>detected. 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.
>
>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.
>
>If a field is defined as ALPHANUMERIC it can hold anything, and it therefor
e
>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 reaso
n
>you need to do so is because of sloppy programming, and the fact that the
>hardware may crash your program if you don't.
>
>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.
>
>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  with an
>alphabetic character, inadvertently introduced into the card. Again, an
>illogical workaround, necessitated by inadequate hardware.
>
>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.

You cannot test packed decimal for numeric using a group name, nor can you t
est a signed
number. I think a NUMERIC test on PIC X is illogical, because the definition
 of numeric is
ambiguous.  A NUMERIC test on PIC X acts as though the PIC is all 9s, unsign
ed. If that's
the type you intend, it would be clearer to say so explicitly.

The '02 Standard introduced VALIDATE. When applied to a group name (such as 
a record), it
tests each elementary field individually, according to its picture.