Cobol - checking if NUMERIC

Author

checking if NUMERIC

Frank Swarbrick

2007-10-10, 6:55 pm

In a discussion with a vendor he mentioned an issue with a numeric field
(USAGE DISPLAY PIC 9(9) or whatever) not having numeric data in it. I
mentioned that I simply check if the field is NUMERIC prior to attempting to
use it further. Here is his response:

"I'm used to using COBOL under MVS (Z/OS) where you get a "data exception"
error whenever you access a numeric field containing non-numeric data - even

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 its

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?

Thanks,
Frank

William M. Klein

2007-10-10, 6:55 pm

Easy answer. They're WRONG. (And as far as I know they were never correct).

1) See
http://publibz.boulder.ibm.com/cgi-...gy3lr31/6.1.6.2
for rules that explicitly ALLOW testing of NUMERIC

2) You don't *always* get a data exception when referencing a numeric data item
when it has invalid data. For a discussion of this they should see the
Migration Guide and look at the NUMPROC compiler option.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:470C97B6.6F0F.0085.0@efirstbank.com...
> In a discussion with a vendor he mentioned an issue with a numeric field
> (USAGE DISPLAY PIC 9(9) or whatever) not having numeric data in it. I
> mentioned that I simply check if the field is NUMERIC prior to attempting to
> use it further. Here is his response:
>
> "I'm used to using COBOL under MVS (Z/OS) where you get a "data exception"
> error whenever you access a numeric field containing non-numeric data - even
>
> 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 its
>
> 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?
>
> Thanks,
> Frank
>

Frank Swarbrick

2007-10-10, 6:55 pm

Thanks, Bill. I had a hard time imagining that this issue ever actually
existed. I'm guessing the vendor is getting this issue

with some
other issue.

n 10/10/2007 at 12:08 PM, in message
<Ly8Pi.91443$6L.44713@fe03.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> Easy answer. They're WRONG. (And as far as I know they were never
> correct).
>
> 1) See
>
> http://publibz.boulder.ibm.com/cgi-...S/igy3lr31/6.1.
> 6.2
> for rules that explicitly ALLOW testing of NUMERIC
>
> 2) You don't *always* get a data exception when referencing a numeric
> data item
> when it has invalid data. For a discussion of this they should see the
> Migration Guide and look at the NUMPROC compiler option.

Arnold Trembley

2007-10-11, 3:55 am

William M. Klein wrote:
> Easy answer. They're WRONG. (And as far as I know they were never correct).
>
> 1) See
> http://publibz.boulder.ibm.com/cgi-...gy3lr31/6.1.6.2
> for rules that explicitly ALLOW testing of NUMERIC
>
> 2) You don't *always* get a data exception when referencing a numeric data item
> when it has invalid data. For a discussion of this they should see the
> Migration Guide and look at the NUMPROC compiler option.
>

As a working programmer, I have frequently used the numeric test on
DISPLAY USAGE and COMP-3 (PACKED-DECIMAL) numbers without any
problems, going back as far as IBM OS/VS COBOL.

If I recall correctly, it is pretty much impossible for a COMP
(binary) number to test out as non-numeric on IBM Mainframe COBOL
compilers.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Howard Brazee

2007-10-16, 6:55 pm

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

William M. Klein

2007-10-16, 6:55 pm

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.

Howard Brazee

2007-10-16, 6:55 pm

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

Pete Dashwood

2007-10-16, 6:55 pm

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

Judson McClendon

2007-10-16, 9:55 pm

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

Robert

2007-10-16, 9:55 pm

On Wed, 17 Oct 2007 12:30:33 +1300, "Pete Dashwood" <dashwood@removethis.enternet.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 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.

You cannot test packed decimal for numeric using a group name, nor can you test 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, unsigned. 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.

William M. Klein

2007-10-17, 3:55 am

"Robert" <no@e.mail> wrote in message
news:fkoah3t4gh1kflcked2o0srpd2n0d42r10@
4ax.com...
> On Wed, 17 Oct 2007 12:30:33 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
<snip>
> 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.

The '02 Standard also allows you to do an IF NUMERIC class test against a field
defined as numeric - but with a USAGE other than DISPLAY (or NATIONAL). The
interest thing (to me) is that an IF NUMERIC against a USAGE BINARY field will
check if it matches the PICTURE clause, so,

01 Group-1 Value All X"FF".
05 Bin1 Pic S99 Binary.
05 Bin2 Binary-Short.

If Bin1 Numeric
will FAIL

while
If Bin2 Numeric
will pass

(The '85 Standard id NOT allow a NUMERIC class test against a USAGE
Packed-Decimal field, but IBM has for many years. I can't remember if it was
allowed for OS/VS COBOL or not But VS COBOL II did, see:

http://publibz.boulder.ibm.com/cgi-...gyl1101/2.8.5.2

and it was documented as an extension.)

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein

2007-10-17, 3:55 am

Pete,
Help me understand your objection, please.

I have always considered it a GOOD PRACTICE to "validate" numeric fields (once,
not every time they are referenced within an application).

As far as I know, the ANSI Standards have ALWAYS allowed one to use the IF
NUMERIC class test against a USAGE DISPLAY numeric field (with or without sign -
and the test paid attention to what was defined). What is "illogical" about
using this construct to do this test? To do the test on an alphanumeric
"redefinition" of the field doesn't work - because there is no way to tell if
"good" data should or should not have a sign.

If this were 1975 or so, I would say that the VALIDATE facility introduced in
the '02 Standard would be "great" - but most applications have already had to go
beyond what that feature offered.

I think the thing that you are missing (as I read things) is that the class
tests are INTENDED to check fields to see if their contents DO "match" how they
are defined. That is why you can do an IF ALPHABETIC test against a PIC A field
(not that people use these very often).

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5nkvslFitpa0U1@mid.individual.net...
>
>
> "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 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."
>
>
>
>

Binyamin Dissen

2007-10-17, 3:55 am

On Wed, 17 Oct 2007 12:30:33 +1300 "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> 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. Not all non-numeric fields generated invalid packed data. PIC
9(3) with the value "ABC" will not cause a fault.

The numeric test is to validate externally generated input.

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

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

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

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

If the PICTURE allows for a sign, an overpunch is correct. If it did not, it
was incorrect.

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?

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

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Pete Dashwood

2007-10-17, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:M1fRi.176686$zh6.105497@fe10.news.easynews.com...
> Pete,
> Help me understand your objection, please.
>
> I have always considered it a GOOD PRACTICE to "validate" numeric fields
> (once, not every time they are referenced within an application).
>
I think it is good practice to validate fields that are supposed to be
numeric (once), but I don't think it is good practice to use a class test to
do so.

I simply take the text from the screen (or whatever) and pass it as a string
(Pic X) to a component that tells me if it is numeric, if a decimal point
(.) is present, if signs (+/-/CR/DR) are present, how many digits before the
point, how many after the point, ignoring trailing or leading spaces if I
want them ignored, and sets object properties that give me the number
(integer and decimal parts, and both together if there are less than 19
digits) in any valid format the platform supports: binary, packed, display,
and floating point.The component returns a Boolean that specifies true or
false if the string passed is a number. Once I know it is a number, I can
pick up whatever format for it I want.

Since I first wrote this code as a COM component in OO COBOL, I have NEVER
had a single validation failure on numeric data in any of my applications.

The class test is primitive and incomplete. It lets certain signs through
whether they are valid or not, and, in my opinion, it is illogical to have a
class (type) that is NUMERIC and then have to test to make sure it has
NUMERIC data in it. It logically makes sense to apply it to ALPHANUMERIC
data because it might be ALPHABETIC or NUMERIC or a mixture of both; any
other test is simply silly.

Let's check if Bill is Bill or Pete is Pete :-) Gosh! it returned true...
surprise! surprise!

> As far as I know, the ANSI Standards have ALWAYS allowed one to use the IF
> NUMERIC class test against a USAGE DISPLAY numeric field (with or without
> sign - and the test paid attention to what was defined). What is
> "illogical" about using this construct to do this test?

What is illogical about testing blood to see if it's blood? (after it has
been established as being blood... :-))

COBOL students are taught that there are three classes of data handled by
COBOL; ALPHABETIC, NUMERIC, and ALPHANUMERIC. It is fair and resonable that
if something is stored in one of those types the compiler will have ensured
it is what it is supposed to be (It should check before storing it
there...). It doesn't, and it can't (on some platforms) because the NUMERIC
class is subdivided down into hardware oriented formats that defeat the
purpose of a NUMERIC type. Hence, we see NUMERIC fields (by definition)
being tested IF NUMERIC... and hence my comment that this is illogical.

> To do the test on an alphanumeric "redefinition" of the field doesn't
> work - because there is no way to tell if "good" data should or should not
> have a sign.

Validation applies to external data; once you let it in, it has a sign or it
doesn't. Once it is in your (OK...MY) program I know what it is and what it
has in it. I'd be worried if I didn't... :-)

>
> If this were 1975 or so, I would say that the VALIDATE facility introduced
> in the '02 Standard would be "great" - but most applications have already
> had to go beyond what that feature offered.

Yes, see above.
>
> I think the thing that you are missing (as I read things) is that the
> class tests are INTENDED to check fields to see if their contents DO
> "match" how they are defined.

No I'm not missing that at all. They have had to be extended to do that
because of the reasons we already covered. In COBOL 59 these tests were
INTENDED to check ONLY ALPHANUMERIC fields and right through to COBOL 68 (if
memory serves) that was what they did. The compilers I worked with threw a
diagnostic if the field being tested was NOT ALPHANUMERIC.

> That is why you can do an IF ALPHABETIC test against a PIC A field (not
> that people use these very often).

This was probably added for consistency... :-) (And because group moves make
them spaces...)

I guess the bottom line for me is this:

1. If you have a type that is defined as a certain type, then the compiler
should ensure that that type is what the field contains.

(I can't define something in C# as an integer, and move something
non-integer to it; or define something as a string, then move something that
is not a string to it; the Assembler has a hissy fit. If something is
defined as a type, the programmer has a right to expect it to be that type.)

2. The current COBOL NUMERIC class test can fail, depending on what it is
applied against. This is not only misleading, it is downright dangerous.

So the facility is either inadequate (necessitating replacement with a
componet that does the job properly) or it is illogical, because it has to
be applied to things that it shouldn't have to be applied to, if proper
typing were implemented.

Either way, in my book it is marked as "Best Avoided" and if I DO use it, I
use it only on felds that are ALPHANUMERIC.

Pete.

Pete Dashwood

2007-10-17, 6:55 pm

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:piebh39reol3s00mrelp7n3qqr1upumc9e@
4ax.com...
> On Wed, 17 Oct 2007 12:30:33 +1300 "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> 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

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

Robert

2007-10-17, 6:55 pm

On Thu, 18 Oct 2007 02:08:55 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>Validation applies to external data; once you let it in, it has a sign or it
>doesn't. Once it is in your (OK...MY) program I know what it is and what it
>has in it. I'd be worried if I didn't... :-)

Validation is often used on external flat files created by another system, to check the
data before letting it in. Batch programs don't get their input from keyboards.

Binyamin Dissen

2007-10-17, 6:55 pm

On Thu, 18 Oct 2007 02:23:51 +1300 "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

:>"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
:> news:piebh39reol3s00mrelp7n3qqr1upumc9e@
4ax.com...
:>> On Wed, 17 Oct 2007 12:30:33 +1300 "Pete Dashwood"
:>> <dashwood@removethis.enternet.co.nz> 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.

Your memory plays tricks on you.

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

Your statement was that "so that programmers could detect the crap and take
action to avoid the program being aborted". My point was that not all
non-numeric values will cause a program to be aborted.

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

Now you are just being silly.

Your statement was "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."

Its logical use is not to validate data presumed to be good, such as the
master file. Its use is to validate data that was human generated. Ergo,

"The numeric test is to validate 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.

As above.

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

You mean, why not use a REXX type approach and treat all data as strings and
let the run time determine if the string is a number?

Historical reasons. Files take less space, compiler can generate more
efficient code, etc. As a side point, these reasons still apply to some
extent.

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

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.

Your statement was "The test had to be "NUMERIC and POSITIVE" to ensure that
zoned sign overpunches were not

with an alphabetic character".

"33F" in a PIC S9(3) field would pass both the class test and the positive
test while "33M" would pass the class test and not the positive test.

Show your case where POSITIVE would add to the validation.

:>> 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 :-)?

I really don't see where you are coming from.

In any language, one codes validation routines for human entered input to
verify that it is consistent with what is expected.

:>> :>For myself, the ONLY time I would use a Class test is on an ALPHANUMERIC
:>> :>field (PIC X).

Why?

What will you do if it is true? False?

How would the code be any different if it was PIC 9?

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

The Language doesn't know that certain data is more suspect than others. That
is programming.

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

And I don't see where it comes from.

:>Your disagreement has been noted and filed appropriately :-)

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Pete Dashwood

2007-10-17, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:um3ch3dsvrc05cld8osi4lfh8injpc9hu6@
4ax.com...
> On Thu, 18 Oct 2007 02:08:55 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> Validation is often used on external flat files created by another system,
> to check the
> data before letting it in. Batch programs don't get their input from
> keyboards.

Data should be validated at source. Besides, I'm not interested in batch
programming.... :-)

Proper design of online systems can obviate it anyway. :-)

Actually, I take your point, Robert. There obviously ARE cases where
interfaces to other programs and files will require re-validation (or it
will make everyone feel better even if it isn't actually required.). I would
move "numeric" fields to a string (pic x) and then pass the string to my
validation component. If it returns isNumeric as true then it is safe.

Pete.

Howard Brazee

2007-10-17, 6:55 pm

On Tue, 16 Oct 2007 19:26:01 -0500, "Judson McClendon"
<judmc@sunvaley0.com> wrote:

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

I have used that compiler, so that may be where I came across it.

Frank Swarbrick

2007-10-17, 6:55 pm

>>> On 10/16/2007 at 5:30 PM, in message
<5nkvslFitpa0U1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:

>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:EG8Ri.134871$zt4.81850@fe08.news.easynews.com...
> 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.

Interesting argument.

Comments:
The Cobol 2002 standard 8.8.4.1.3.2 states "2) If the NUMERIC phrase is
specified, identifier-1 shall reference a data item whose usage is display
or national or whose category is numeric."

This says to me that it's wholly valid to check, say, a PIC 9(9) DISPLAY or
PACKED-DECIMAL field for NUMERIC. In fact, it appears you could even check
a BINARY field for NUMERIC, though I'm guessing on most platforms this would
always result in a result of true.

The specific case where I am checking for NUMERIC that brought up this issue
is in an XML parser. You can pass to the parser an XML document and a Cobol
copybook that represents the elements and attributes in that document. By
default, if a particular element/attribute is not present then the COBOL are
that represents that element/attribute is initialized to spaces, if it's
alphanumeric or zeroes, if it's numeric. However there is also an option to
initialize it to other values, if desired. I chose to use low-values for
both alphanumeric and numeric items. This allows me to distinguish between,
say, a numeric element that is present and happens to contain a value of
zeroes, and one that is simply not present in the XML document.

This seems to me to be an absolutely reasonable thing to do. Feel free to
disagree. :-)

In "regular" Cobol processing (no XML involved) there is certainly the
possibility of doing other things to allow you to distinguish between a
field that simply has a value of zeroes and one that is 'not applicable'.
For instance, consider an 'accrued interest' field. In our demand (checking
account) system we have some accounts that earn interest and some that
don't. We certainly have code that checks to see if the account type
specifies an interest-bearing account prior to attempting any interest
calculations. I doubt we have anything that specifically checks the accrued
interest field for numeric (though we might; who knows).

Still, it seems to me that there are situations where checking a particular
field itself, rather than some other flag or whatever, for valid numerics is
a very useful way to distinguish between a 'zero' field and what one might
call a 'null' field (kind of like in an RDBMS). In fact, I would love it if
when inserting a record in to an RDBMS you could set a numeric field to a
non-numeric value and the RDBMS would treat it as if you were setting that
field to NULL. I believe I have tried this and it does not work (I didn't
really think it would), but I thought it would be nice.

Now if Cobol supported some sort of intrinsic NULL value for numeric and
alphanumeric data items that would seem to me ideal. But until then...

Anyway, those are my thoughts on the matter.

Frank

Robert

2007-10-17, 6:55 pm

On Thu, 18 Oct 2007 03:07:41 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>
>"Robert" <no@e.mail> wrote in message
> news:um3ch3dsvrc05cld8osi4lfh8injpc9hu6@
4ax.com...
>
>Data should be validated at source. Besides, I'm not interested in batch
>programming.... :-)

Q. Do we still need to support IF NUMERIC?
A. Don't know. Call Pete, ask whether he's interested. If Pete doesn't need it, we'll
delete it from the compiler.

>Proper design of online systems can obviate it anyway. :-)
>
>Actually, I take your point, Robert. There obviously ARE cases where
>interfaces to other programs and files will require re-validation (or it
>will make everyone feel better even if it isn't actually required.). I would
>move "numeric" fields to a string (pic x) and then pass the string to my
>validation component. If it returns isNumeric as true then it is safe.

Moving an invalid packed decimal value to display will cause (depending on options) either
the abend you're trying to avoid OR a false positive.

Howard Brazee

2007-10-17, 6:55 pm

On Thu, 18 Oct 2007 03:07:41 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Data should be validated at source. Besides, I'm not interested in batch
>programming.... :-)
>
>Proper design of online systems can obviate it anyway. :-)
>
>Actually, I take your point, Robert. There obviously ARE cases where
>interfaces to other programs and files will require re-validation (or it
>will make everyone feel better even if it isn't actually required.). I would
>move "numeric" fields to a string (pic x) and then pass the string to my
>validation component. If it returns isNumeric as true then it is safe.

I have received data from sources (outside companies) that had
adequate editing for their needs. And I have passed data that had
adequate editing for my needs. But different systems have different
needs.

Robert

2007-10-17, 6:55 pm

On Wed, 17 Oct 2007 10:14:33 -0600, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com>
wrote:

>Still, it seems to me that there are situations where checking a particular
>field itself, rather than some other flag or whatever, for valid numerics is
>a very useful way to distinguish between a 'zero' field and what one might
>call a 'null' field (kind of like in an RDBMS). In fact, I would love it if
>when inserting a record in to an RDBMS you could set a numeric field to a
>non-numeric value and the RDBMS would treat it as if you were setting that
>field to NULL. I believe I have tried this and it does not work (I didn't
>really think it would), but I thought it would be nice.

Try the word NULL.

01 a-number.
05 a-number-n pic 9(9).99.

move 'NULL' to a-number
insert into (table) values (:a-number)

move zero to a-number-n
insert into (table) values (:a-number)

Howard Brazee

2007-10-17, 6:55 pm

On Wed, 17 Oct 2007 12:32:09 -0500, Robert <no@e.mail> wrote:

>Moving an invalid packed decimal value to display will cause (depending on options) either
>the abend you're trying to avoid OR a false positive.

That latter can be a problem - IF NUMERIC doesn't know how the data
got there - a false positive will pass this test.

The IF NUMERIC test can often be similar to the

If MY-COUNT = zero
COMPUTE MY-PRICE = MY-SUM / MY-COUNT
else
COMPUTE MY-PRICE = ZERO
end-if

It is irritating to use up CPU cycles every time I do a divide instead
of when exceptions occur.

William M. Klein

2007-10-17, 6:55 pm

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:kk4ch39nirj6mqfrtvnqjmu4h7l92u9sso@
4ax.com...
> On Thu, 18 Oct 2007 02:23:51 +1300 "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
<much sinppage>
> :>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".
>
> Now you are just being silly.
>
> Your statement was "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."
>
> Its logical use is not to validate data presumed to be good, such as the
> master file. Its use is to validate data that was human generated. Ergo,
>
> "The numeric test is to validate 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.
>

Pete,
I think we are in agreement on "int3ent" but not methodology.

A generally (not universal <G> ) accepted consensus is that ALL data (but
especially what COBOL calls numeric or numeric-edited) should be "validated" as
close to the time that it is "input" as possible. For an online system, this
can usually (always?) be done at point of user-entry. For systems where the
owner of the "initialization" process is NOT the same as the "owner" of the user
application(s), then the data should be validated at "time of transfer".

The COBOL "IF NUMERIC" test is "but one" method for validating data. (The '02
Standard, for example, introduces a number of COBOL intrinsic functions of the
form TEST-xxxx - which validates that fields are "good" for use in other
intrinsic functions.) If *all* that a COBOL application needs to know is that a
field passes the IF NUMERIC test (which DOES in COBOL "guarantee" that it can be
used wherever COBOL uses numeric fields), then I see it as a perfectly valid
test. I (myself) have yet to see a "real-world" application that did not
require MORE data validation than just this, e.g. is a number non-zero? is a
state abbreviation a valid abbreviation, is a currenty sign leading when
required, etc).

Bottom-Line (IMHO)
- If you can trust your data, then do so
- If you are at the "beginning" of the data stream validate your input
- If you are getting data from an "outside source" then you MAY need to
(re)validate it
- If you are getting "outside" data needed to be used in a COBOL numeric
statement, then the IF NUMERIC test (where allowed) is a perfectly adequate way
to test the data (once).

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein

2007-10-17, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5nmfr1FivobkU1@mid.individual.net...
<snip>
> The class test is primitive and incomplete. It lets certain signs through
> whether they are valid or not, ... <snippage - so quote is out of context>

Pete,
I would be interested in when you think this happens. As far as I know, the
COBOL "IF NUMERIC" test (when allowed - and it isn't always allowed) DOES
"guarantee" that the field can subsequently be used wherever COBOL allows a
numeric field to be used - and with the "expected" results.

The opposite is NOT true. There are character/bit strings that MIGHT work for
some numeric statements - but would fail a NUMERIC class test.

There are also (for many? most? vendors) compiler options/directives that impact
what will and will not pass an IF NUMERIC class test. However, within the same
compiled program, I believe that fields that PASS numeric class test - will work
"as expected" in other numeric fields - whatever the compiler option is.

As I say, I would be interested if you know of cases where this isn't true
(other than "bugs" in earlier compilers).

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2007-10-17, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:sfhch3h6la2ul3svv0g010q5d8qpu476p6@
4ax.com...
> On Thu, 18 Oct 2007 03:07:41 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> Q. Do we still need to support IF NUMERIC?
> A. Don't know. Call Pete, ask whether he's interested. If Pete doesn't
> need it, we'll
> delete it from the compiler.

Quite right too... :-)

I already made my COM component available for free download, in conjunction
with an article I wrote for the now defunct COBOL website
"aboutlegacycoding" a few years back. (25000 people read the article, and
several hundred downloaded the component).

You can rely on me to provide what's needed... :-)

Honest Pete's.... software, components, free advice....AND a set of steak
knives for every 5th customer...

>
>
> Moving an invalid packed decimal value to display will cause (depending on
> options) either
> the abend you're trying to avoid OR a false positive.

As far as I recall, (and it has been a while), moving a packed field to
alphanumeric will NEVER cause S0C7. As for a false positive, you can get
that with IF NUMERIC...

I said above: "If it returns isNumeric as true then it is safe." I didn't
say it was valid. Further checking might be required, but at least those
checks can be done safely.

To be frank, I really don't care whether people use IF NUMERIC or they
don't. I expressed what is a very personal view and I'm perfectly happy for
people to disagree (in fact the reaction is very much what I expected :-)).

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

Pete Dashwood

2007-10-17, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:7ouRi.53866$m81.46809@fe01.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5nmfr1FivobkU1@mid.individual.net...
> <snip>
>
> Pete,
> I would be interested in when you think this happens.

I remember being caught by it on a number of occasions, but it may have been
in the days of overpunching.

I also remember having to add AND POSITIVE at that time. Binyamin pointed
out that that depended on whether the receiving picture was signed or not (I
had forgotten that bit :-))

I guess I just came to mistrust it, maybe without valid reason.

If you think it is 100% I'll take your word for it and withdraw my harsh
statement above. :-)

It really isn't important enough to me to continue arguing it; I have a
better solution that works well for me, and I'm no longer developing new
stuff in COBOL anyway.

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

As far as I know, the
> COBOL "IF NUMERIC" test (when allowed - and it isn't always allowed) DOES
> "guarantee" that the field can subsequently be used wherever COBOL allows
> a numeric field to be used - and with the "expected" results.
>
> The opposite is NOT true. There are character/bit strings that MIGHT work
> for some numeric statements - but would fail a NUMERIC class test.
>
> There are also (for many? most? vendors) compiler options/directives that
> impact what will and will not pass an IF NUMERIC class test. However,
> within the same compiled program, I believe that fields that PASS numeric
> class test - will work "as expected" in other numeric fields - whatever
> the compiler option is.
>
> As I say, I would be interested if you know of cases where this isn't true
> (other than "bugs" in earlier compilers).
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>

Pete Dashwood

2007-10-17, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:VjuRi.109323$nh4.9223@fe09.news.easynews.com...
> "Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
> news:kk4ch39nirj6mqfrtvnqjmu4h7l92u9sso@
4ax.com...
> <much sinppage>
>
> Pete,
> I think we are in agreement on "int3ent" but not methodology.
>
> A generally (not universal <G> ) accepted consensus is that ALL data (but
> especially what COBOL calls numeric or numeric-edited) should be
> "validated" as close to the time that it is "input" as possible. For an
> online system, this can usually (always?) be done at point of user-entry.
> For systems where the owner of the "initialization" process is NOT the
> same as the "owner" of the user application(s), then the data should be
> validated at "time of transfer".
>
> The COBOL "IF NUMERIC" test is "but one" method for validating data. (The
> '02 Standard, for example, introduces a number of COBOL intrinsic
> functions of the form TEST-xxxx - which validates that fields are "good"
> for use in other intrinsic functions.) If *all* that a COBOL application
> needs to know is that a field passes the IF NUMERIC test (which DOES in
> COBOL "guarantee" that it can be used wherever COBOL uses numeric fields),
> then I see it as a perfectly valid test. I (myself) have yet to see a
> "real-world" application that did not require MORE data validation than
> just this, e.g. is a number non-zero? is a state abbreviation a valid
> abbreviation, is a currenty sign leading when required, etc).
>
> Bottom-Line (IMHO)
> - If you can trust your data, then do so
> - If you are at the "beginning" of the data stream validate your input
> - If you are getting data from an "outside source" then you MAY need to
> (re)validate it

Agreed. No argument.

> - If you are getting "outside" data needed to be used in a COBOL numeric
> statement, then the IF NUMERIC test (where allowed) is a perfectly
> adequate way to test the data (once).

Maybe. I have a better solution.

(And you might recall I was not the original poster who complained about
it...)
--
"I used to write COBOL...now I can do anything."

Robert

2007-10-17, 9:55 pm

On Wed, 17 Oct 2007 12:39:53 -0600, Howard Brazee <howard@brazee.net> wrote:

>On Wed, 17 Oct 2007 12:32:09 -0500, Robert <no@e.mail> wrote:
>
>
>That latter can be a problem - IF NUMERIC doesn't know how the data
>got there - a false positive will pass this test.
>
>The IF NUMERIC test can often be similar to the
>
>If MY-COUNT = zero
> COMPUTE MY-PRICE = MY-SUM / MY-COUNT
>else
> COMPUTE MY-PRICE = ZERO
>end-if
>
>It is irritating to use up CPU cycles every time I do a divide instead
>of when exceptions occur.

Speaking of CPU cycles, IF NUMERIC on PIC X is merely testing for byte values '0' through
'9'. If the compiler calls a function, you can do that faster yourself, like this:

01 a-number.
05 a-number-n pic 9(9)v99.
01 a-number-tester pic x(11).

move a-number to a-number-tester
inspect a-number-tester converting '0123456789' to zero
if a-number-tester not equal to zero
set bad-record to true
end-if

Jeff Campbell

2007-10-17, 9:55 pm

Howard Brazee wrote:
> On Wed, 17 Oct 2007 12:32:09 -0500, Robert <no@e.mail> wrote:
>
>
> That latter can be a problem - IF NUMERIC doesn't know how the data
> got there - a false positive will pass this test.
>
> The IF NUMERIC test can often be similar to the
>
> If MY-COUNT = zero
> COMPUTE MY-PRICE = MY-SUM / MY-COUNT
> else
> COMPUTE MY-PRICE = ZERO
> end-if
>
> It is irritating to use up CPU cycles every time I do a divide instead
> of when exceptions occur.
>
Why not use

compute my-price = my-sum / my-count
on size error
move zero to my-price
end-compute

Jeff

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

SkippyPB

2007-10-18, 6:55 pm

On Thu, 18 Oct 2007 12:51:43 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>
>"Robert" <no@e.mail> wrote in message
> news:sfhch3h6la2ul3svv0g010q5d8qpu476p6@
4ax.com...
>
>Quite right too... :-)
>
>I already made my COM component available for free download, in conjunction
>with an article I wrote for the now defunct COBOL website
>"aboutlegacycoding" a few years back. (25000 people read the article, and
>several hundred downloaded the component).
>
>You can rely on me to provide what's needed... :-)
>
>Honest Pete's.... software, components, free advice....AND a set of steak
>knives for every 5th customer...
>
>
>As far as I recall, (and it has been a while), moving a packed field to
>alphanumeric will NEVER cause S0C7. As for a false positive, you can get
>that with IF NUMERIC...
>

On the IBM mainframe, you are correct. You can move spaces to a field
defined as packed (in any language) and it will not abend but will
"pack" the spaces. However, do an arithmetic operation on that field
and it will abend.

I deal with interfaces a lot. Interfaces to different systems on
different computers running who knows what systems. The data can come
to me in a transmission or on a data tape. If a field is supposed to
be numeric, it would be ignorant of me not to check the incoming field
for numerics before I used it. Standard practise is to validate the
incoming data and report things that don't pass. So yes, the numeric
class test is very important to me.

Many moon cycles ago, I worked on a conversion of an application
system that was running on a Burroughs (don't remember the model)
computer and was going to run on an IBM 4381. In attempting to
balance the data from reports given on the Burroughs to reports
produced on the IBM for the same albeit converted data, there was
always a $360.00 imbalance. I searched, the users searched and the
auditors searched but we could not account for the imbalance. As a
last resort, I began to analyze the master posting program on the
Burroughs. Not being real famaliar with Burroughs Cobol, I had dumped
a lot of records and was desk checking the data against the program.
After about 5 or 6 days of this I finally came across the problem. A
Burroughs Cobol programmer probably would have known this right off.
Burroughs allowed arithmetic on a packed field that had non numerics
in it and would not abend. There was an account on the master file
that had spaces in balance field. Burroughs happily added those
packed spaces to a final total field on a report without complaint.
When I had converted the data, I had checked for numerics and if the
field was not numeric, initialized it to zeroes so that the IBM was
happy.

Once the field was "corrected" on the Burroughs side and the reports
rerun, all was in balance.

>I said above: "If it returns isNumeric as true then it is safe." I didn't
>say it was valid. Further checking might be required, but at least those
>checks can be done safely.
>
>To be frank, I really don't care whether people use IF NUMERIC or they
>don't. I expressed what is a very personal view and I'm perfectly happy for
>people to disagree (in fact the reaction is very much what I expected :-)).
>
>Pete.

Regards,
////
(o o)
-oOO--(_)--OOo-

"I think that's how Chicago got started.
A bunch of people in New York said,
'Gee, I'm enjoying the crime and the poverty,
but it just isn't cold enough. Let's go west.'"
-- Richard Jeni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Pete Dashwood

2007-10-18, 6:55 pm

"SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
news:ciseh3hodjkng997tr8k2rbt7k4sfueepu@
4ax.com...
> On Thu, 18 Oct 2007 12:51:43 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> On the IBM mainframe, you are correct. You can move spaces to a field
> defined as packed (in any language) and it will not abend but will
> "pack" the spaces. However, do an arithmetic operation on that field
> and it will abend.
>
> I deal with interfaces a lot. Interfaces to different systems on
> different computers running who knows what systems. The data can come
> to me in a transmission or on a data tape. If a field is supposed to
> be numeric, it would be ignorant of me not to check the incoming field
> for numerics before I used it. Standard practise is to validate the
> incoming data and report things that don't pass. So yes, the numeric
> class test is very important to me.

I would just note in passing that I have never suggested data doesn't need
validating. It is a question of whether the class test is adequate or not.
I don't think it is, but Bill says it is and I respect his opinion. I also
may have just acquired a phobia about it after a few bad experiences :-)
Whatever the reasons, I have a better alternative, and whether I am right
about it being flaky or not, I still think if a field is defined as numeric
it should BE numeric, so testing it for numeric is illogical. (This is a
concept; in reality I know that it is necessary to test it, and I understand
why it is; but that is a flaw in the way the language is defined and
implemented on certain platforms, as far as I'm concerned.)
>
> Many moon cycles ago, I worked on a conversion of an application
> system that was running on a Burroughs (don't remember the model)
> computer and was going to run on an IBM 4381. In attempting to
> balance the data from reports given on the Burroughs to reports
> produced on the IBM for the same albeit converted data, there was
> always a $360.00 imbalance. I searched, the users searched and the
> auditors searched but we could not account for the imbalance. As a
> last resort, I began to analyze the master posting program on the
> Burroughs. Not being real famaliar with Burroughs Cobol, I had dumped
> a lot of records and was desk checking the data against the program.
> After about 5 or 6 days of this I finally came across the problem. A
> Burroughs Cobol programmer probably would have known this right off.
> Burroughs allowed arithmetic on a packed field that had non numerics
> in it and would not abend. There was an account on the master file
> that had spaces in balance field. Burroughs happily added those
> packed spaces to a final total field on a report without complaint.
> When I had converted the data, I had checked for numerics and if the
> field was not numeric, initialized it to zeroes so that the IBM was
> happy.
>
> Once the field was "corrected" on the Burroughs side and the reports
> rerun, all was in balance.

Good anecdote, Steve. I remember the Burroughs systems with some affection
:-)

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

Clark F Morris

2007-10-18, 9:55 pm

On Wed, 17 Oct 2007 12:30:33 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.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 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.

The reason to validate a field is because the source is suspect. If
the field should be numeric and will be operated on in that manner,
then I would use an IF NUMERIC test. Input from outside systems can
be interesting as can true raw input.
>
>Pete.

Clark F Morris

2007-10-18, 9:55 pm

On Wed, 17 Oct 2007 19:20:57 -0500, Robert <no@e.mail> wrote:

>On Wed, 17 Oct 2007 12:39:53 -0600, Howard Brazee <howard@brazee.net> wrote:
>
>
>Speaking of CPU cycles, IF NUMERIC on PIC X is merely testing for byte values '0' through
>'9'. If the compiler calls a function, you can do that faster yourself, like this:
>
>01 a-number.
> 05 a-number-n pic 9(9)v99.
>01 a-number-tester pic x(11).
>
>move a-number to a-number-tester
>inspect a-number-tester converting '0123456789' to zero
>if a-number-tester not equal to zero
> set bad-record to true
>end-if
IF NUMERIC on a z series IBM computer generates a Translate and Test
followed by a Branch On Condition for unsigned fields and slightly
more complex code for signed fields. This should be faster than your
code.

Charles Hottel

2007-10-18, 9:55 pm

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:180gh3hp6j61icd2et52s79ovo6dttkk0f@
4ax.com...
> On Wed, 17 Oct 2007 19:20:57 -0500, Robert <no@e.mail> wrote:
>
> IF NUMERIC on a z series IBM computer generates a Translate and Test
> followed by a Branch On Condition for unsigned fields and slightly
> more complex code for signed fields. This should be faster than your
> code.

I might use IF NUMERIC on a display numeric field in some limited
circumstances ( CICS fields not being one ). I do not trust it on packed
decimal. If you pack the letter A which is hexadecimal C1 you will get
hexadecimal 1C which will be treated as a valid number even though the
original input was not numeric. At least I remember that happening long ago
on IBM DOS/ or DOS/VS.

On CICS fields I do something similar to what Pete does only it is not a
component just paragrah that I PERFORM..

Robert

2007-10-18, 9:55 pm

On Thu, 18 Oct 2007 22:00:03 -0300, Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:

>On Wed, 17 Oct 2007 19:20:57 -0500, Robert <no@e.mail> wrote:
>
>IF NUMERIC on a z series IBM computer generates a Translate and Test
>followed by a Branch On Condition for unsigned fields and slightly
>more complex code for signed fields. This should be faster than your
>code.

I said "if the compiler calls a function." An inline TRT is the same idea as my code, but
faster because it raises an exception for a bad value. Too bad INSPECT .. CONVERTING
doesn't have an ON EXCEPTION clause.

Jeff Campbell

2007-10-18, 9:55 pm

Pete Dashwood wrote:
> "SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
> news:ciseh3hodjkng997tr8k2rbt7k4sfueepu@
4ax.com...
>
> I would just note in passing that I have never suggested data doesn't need
> validating. It is a question of whether the class test is adequate or not.
> I don't think it is, but Bill says it is and I respect his opinion. I also
> may have just acquired a phobia about it after a few bad experiences :-)
> Whatever the reasons, I have a better alternative, and whether I am right
> about it being flaky or not, I still think if a field is defined as numeric
> it should BE numeric, so testing it for numeric is illogical.

The preceding sentence needs a Mr. Spock raised eyebrow emoticon!! 8-) 8-)

> (This is a
> concept; in reality I know that it is necessary to test it, and I understand
> why it is; but that is a flaw in the way the language is defined and
> implemented on certain platforms, as far as I'm concerned.)
>
> Good anecdote, Steve. I remember the Burroughs systems with some affection
> :-)
>
> Pete.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Robert

2007-10-19, 3:55 am

On Fri, 19 Oct 2007 04:19:48 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>I would just note in passing that I have never suggested data doesn't need
>validating. It is a question of whether the class test is adequate or not.
>I don't think it is, but Bill says it is and I respect his opinion. I also
>may have just acquired a phobia about it after a few bad experiences :-)
>Whatever the reasons, I have a better alternative, and whether I am right
>about it being flaky or not, I still think if a field is defined as numeric
>it should BE numeric, so testing it for numeric is illogical. (This is a
>concept; in reality I know that it is necessary to test it, and I understand
>why it is; but that is a flaw in the way the language is defined and
>implemented on certain platforms, as far as I'm concerned.)

Most members of this group would say MOST or NEARLY ALL values are numeric, or in their
limited experience, they have not seen a non-numeric value. It seems arrogant, reckless
and immodest to tell the compiler ALL contents of a field are numeric, without
qualification or exception. There is no way you could know that without examining every
value that has or will appear in the field. 8-)

Richard

2007-10-19, 3:55 am

On Oct 19, 4:19 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

>
> I would just note in passing that I have never suggested data doesn't need
> validating. It is a question of whether the class test is adequate or not.
> I don't think it is, but Bill says it is and I respect his opinion. I also
> may have just acquired a phobia about it after a few bad experiences :-)
> Whatever the reasons, I have a better alternative, and whether I am right
> about it being flaky or not, I still think if a field is defined as numeric
> it should BE numeric, so testing it for numeric is illogical. (This is a
> concept; in reality I know that it is necessary to test it, and I understand
> why it is; but that is a flaw in the way the language is defined and
> implemented on certain platforms, as far as I'm concerned.)

It is not the _field_ that is tested for being numeric, it is the
current contents.

Pete Dashwood

2007-10-20, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:sp8gh3lq8mdvi9tepuaiac9njnbtf0sb6g@
4ax.com...
> On Fri, 19 Oct 2007 04:19:48 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
>
> Most members of this group would say MOST or NEARLY ALL values are
> numeric, or in their
> limited experience, they have not seen a non-numeric value. It seems
> arrogant, reckless
> and immodest to tell the compiler ALL contents of a field are numeric,
> without
> qualification or exception. There is no way you could know that without
> examining every
> value that has or will appear in the field. 8-)

1. The compiler controls what gets moved to fields.
2. The compiler recognises types.
3. Given a type (Class in COBOL) of "numeric" the compiler should ensure it
actually IS numeric when you use it. If it is unable to do so, then there is
little point in having such a numeric class in the language.

Other languages which support types, check the types and do not allow
invalid data in them. (hence the need for casting and explicit "convert"
functions in languages like C#...)

Anyway, I'm bored with this now so I probably won't respond further :-)

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

Pete Dashwood

2007-10-20, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1192773951.650923.55920@v29g2000prd.googlegroups.com...
> On Oct 19, 4:19 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
> It is not the _field_ that is tested for being numeric, it is the
> current contents.
>
>

A fine distinction, Richard.

The COMPILER should ensure that the CONTENTS stored in the FIELD, are what
the FIELD is defined to contain.

It isn't impossible; other languages do it.

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

Pete Dashwood

2007-10-20, 6:55 pm

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:nsvfh3ldmnbmj8dj2jhrmf3kco59e1n8a4@
4ax.com...
> On Wed, 17 Oct 2007 12:30:33 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> The reason to validate a field is because the source is suspect.

Precisely my point. Data stored in a numeric field should NOT be suspect; it
should be numeric. If data is "suspect" then it should be stored in an
ALPHANUMERIC field, which is defined as being able to hold "anything". Only
when it has been established that it is NUMERIC should it be moved to a
numeric field, and the compiler should not store it there if it ISN'T
numeric.

> the field should be numeric and will be operated on in that manner,
> then I would use an IF NUMERIC test.

Yes, that is the perceived wisdom and has been for decades...

My objections are:

1. Testing a NUMERIC field for IF... NUMERIC SHOULD be redundant and
illogical. The system should ensure it is numeric, because that is the type
it is defined as. IF...NUMERIC should only logically be applied to
ALPHANUMERIC fields.

2. IF... NUMERIC is suspect anyway and sometimes passes stuff that isn't
numeric. (In the light of trong objections form Bill Klein, I'm prepared to
soften that one... :-))

BOTTOM LINE:

I you REALLY want to ensure data is valid before allowing it entry to your
program, validate it in an ALPHANUMERIC field, with a subroutine or
component that does the job properly. THEN move it to whatever numeric
format suits you, secure in the knowledge it actually IS numeric and
therefore not needing to make an illogical and redundant test.

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

Binyamin Dissen

2007-10-20, 6:55 pm

On Sun, 21 Oct 2007 02:47:59 +1300 "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

:>1. The compiler controls what gets moved to fields.
:>2. The compiler recognises types.
:>3. Given a type (Class in COBOL) of "numeric" the compiler should ensure it
:>actually IS numeric when you use it. If it is unable to do so, then there is
:>little point in having such a numeric class in the language.

:>Other languages which support types, check the types and do not allow
:>invalid data in them. (hence the need for casting and explicit "convert"
:>functions in languages like C#...)

Obviously you have failed to learn the concept of records, where storage areas
may contain different types of data depending on context.

:>Anyway, I'm bored with this now so I probably won't respond further :-)

...... and remove all doubt.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

William M. Klein

2007-10-20, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5nufe4Fjqkb8U1@mid.individual.net...
>
<snip>
>
> The COMPILER should ensure that the CONTENTS stored in the FIELD, are what the
> FIELD is defined to contain.
>
> It isn't impossible; other languages do it.
>
> Pete.

So COBOL should get rid of redifines and groups? "By defnition" each of these
has potentially "invalid" definitions according to ONE of the definitions.

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2007-10-20, 9:56 pm

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:8jdkh39o3nfprmdit5jok7lpna84dkvqkl@
4ax.com...
> On Sun, 21 Oct 2007 02:47:59 +1300 "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
> :>1. The compiler controls what gets moved to fields.
> :>2. The compiler recognises types.
> :>3. Given a type (Class in COBOL) of "numeric" the compiler should ensure
> it
> :>actually IS numeric when you use it. If it is unable to do so, then
> there is
> :>little point in having such a numeric class in the language.
>
> :>Other languages which support types, check the types and do not allow
> :>invalid data in them. (hence the need for casting and explicit "convert"
> :>functions in languages like C#...)
>
> Obviously you have failed to learn the concept of records, where storage
> areas
> may contain different types of data depending on context.

Obviously? :-)

I'm sure you're right. It is probably amongst the many things I have failed
to learn over 40 years in IT.

(Makes you wonder how I make a living really, doesn't it? :-))

One of the things I HAVE learned, however, is to question the accepted
practice, and try to think about things from different perspectives.
Sometimes, this pays off; sometimes it doesn't.

If the only way to think about data was as record formats, Relational
Databases would be a bit pointless, but Messrs.Codd and Date were not
limited by the current perceived wisdom at the time they formulated the
Relational Model.

>
> :>Anyway, I'm bored with this now so I probably won't respond further :-)
>
> ..... and remove all doubt.
>

Aw, c'mon... you never had any doubt to remove... :-)

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

Pete Dashwood

2007-10-20, 9:56 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:AwtSi.175998$zt4.148384@fe08.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5nufe4Fjqkb8U1@mid.individual.net...
> <snip>
>
> So COBOL should get rid of redifines and groups? "By defnition" each of
> these has potentially "invalid" definitions according to ONE of the
> definitions.
>

Hmmmm. good point :-)

REDEFINES is one of the most powerful things about COBOL and I wouldn't want
to see it go... :-)

Group levels are a relic of hierarchical views but they ARE very useful.

Still, if INITIALIZE can deal with group levels and recognize the types
contained in the group, why can't MOVE?

It's been a while since I worked on a COBOL compiler, but I don't believe it
would be IMPOSSIBLE to type check MOVEs, even to REDEFINEd fields. (It would
be an overhead of course.)

Still, as Richard pointed out, if the contents are invalid you can't detect
this until run time. My argument is that everything should be in an
ALPHANUMERIC field until it has been validated. (And that is why it makes
sense to me to only apply CLASS tests to an ALPHANUMERIC field). Of course,
the compiler has no way of knowing whether data has been validated or not,
and that is why we have the situation we do. It is up to the programmer to
decide what gets placed in numeric fields.

Hence my comment earlier about "sloppy programming".

Not sure how serious you are being about this, Bill :-)

I accept that much (most?) of my comments are based on personal opinion; I
don't expect action on any of it :-)

(I posted my opinions in the (forlorn?) hope that some people (possibly new
to commercial computer programming) reading this might be stimulated to
think about data validation and what makes sense...The reaction from the
"old hands" is exactly what I expected :-))

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

William M. Klein

2007-10-21, 3:55 am

I certainly don't want to claim your "opinions" are wrong - however, I just
don't agree with them (exactly). COBOL is *designed* so that you can put data
into "numerically defined" fields and THEN validate them (before using them). I
am "used to" thinking this way, so there is no problem.

There is one "technical" issue with your desire to put everything into
ALPHANUMERIC fields, validate, and then move "valid" numeric data to numeric
fields. The issue is what to do with NATIONAL (usually - but not always -
Unicode data). This should NOT be "

" with ALPHANUMERIC data - but can
be NUMERIC.

I suppose (making an assumption about your views - that may not be correct), you
would accept putting "single-byte-ish" data into ALPHANUMERIC fields and
"Unicode-ish" type data into NATIONAL fields. Then validating that data and
then moving them to the appropriate numeric fields.

As I mentioned before, the COBOL "if numeric" test won't work for this (as it
explicitly cannot check for valid/invalid signs in ALPHANUMERIC or NATIONAL
fields). However, if each programmer (site, whatever) does use its own
"component" to do the validation, this could be made to work.

As I say, "thinking in traditional COBOL ways" I am perfectly happy with using
the IF NUMERIC class test (especially since it has been expanded to all
appropriate USAGEs). Doesn't mean that you should be "happy" with it, but it
meets my mind-set.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5nvnq7Fk6b8sU1@mid.individual.net...
>
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:AwtSi.175998$zt4.148384@fe08.news.easynews.com...
>
> Hmmmm. good point :-)
>
> REDEFINES is one of the most powerful things about COBOL and I wouldn't want
> to see it go... :-)
>
> Group levels are a relic of hierarchical views but they ARE very useful.
>
> Still, if INITIALIZE can deal with group levels and recognize the types
> contained in the group, why can't MOVE?
>
> It's been a while since I worked on a COBOL compiler, but I don't believe it
> would be IMPOSSIBLE to type check MOVEs, even to REDEFINEd fields. (It would
> be an overhead of course.)
>
> Still, as Richard pointed out, if the contents are invalid you can't detect
> this until run time. My argument is that everything should be in an
> ALPHANUMERIC field until it has been validated. (And that is why it makes
> sense to me to only apply CLASS tests to an ALPHANUMERIC field). Of course,
> the compiler has no way of knowing whether data has been validated or not, and
> that is why we have the situation we do. It is up to the programmer to decide
> what gets placed in numeric fields.
>
> Hence my comment earlier about "sloppy programming".
>
> Not sure how serious you are being about this, Bill :-)
>
> I accept that much (most?) of my comments are based on personal opinion; I
> don't expect action on any of it :-)
>
> (I posted my opinions in the (forlorn?) hope that some people (possibly new to
> commercial computer programming) reading this might be stimulated to think
> about data validation and what makes sense...The reaction from the "old hands"
> is exactly what I expected :-))
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>

Richard

2007-10-21, 3:55 am

On Oct 21, 2:51 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@Azonic.co.nz> wrote in message
>
> news:1192773951.650923.55920@v29g2000prd.googlegroups.com...
>
>
>
>
>
>
> A fine distinction, Richard.
>
> The COMPILER should ensure that the CONTENTS stored in the FIELD, are what
> the FIELD is defined to contain.
>
> It isn't impossible; other languages do it.

Which particular languages will ensure that a record read from a file,
for example, only contain numeric digits in particular columns of the
data and will change the contents if they are not digits ? And which
will do so if the record is implicitly or explicitly redefined such
that some definitions have it numeric and some as alphanumeric ?

Which languages will not do a move spaces to a group field when
instructed and will munt the data to fit some of the redefinitions ?
What if one redefinition is alpha and another redefinition is
numeric ? will it sit spinning bits like a perpetual motion machine ?

Richard

2007-10-21, 3:55 am

On Oct 21, 3:06 am, "Pete Dashwood"
<dashw...@