Re: checking if NUMERIC



"Clark F Morris" <cfmpublic@xxxxxxxxxxxxxxx> wrote in message
news:5phnp39cnk3nd7vc4nsi2flb4psm9emmco@xxxxxxxxxx
On Sun, 21 Oct 2007 18:33:22 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:



"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:1eASi.226775$vo5.15659@xxxxxxxxxxxxxxxxxxxxxxxxx
I certainly don't want to claim your "opinions" are wrong - however, I
just
don't agree with them (exactly).

No problem. I didn't expect agreement; neither do I expect everyone to
understand why I hold such an opinion... :-)

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.

At this point we diverge a bit. I don't believe it was ORIGINALLY designed
to do that, but I certainly agree that is how everyone sees it.

I believe it was DESIGNED to validate data in AN fields, much as I have
described, but I can't prove that and I'm certianly not going to argue it
:-)

As someone who has used COBOL since May 1963 (RCA 301, after that
varying flavors of IBM COBOL), I have always used it such that input
field were defined as expected and done the test accordingly. In the
case of numerics with sign overpunches, the picture (or SIZE and CLASS
in the Codasyl COBOL 61 I started with) determined how the IF NUMERIC
would work.

I started with COBOL 61 as well :-) You forgot to mention that, prior to the
introduction of PICTURE, data was defined with SIZE, CLASS, and *USAGE*
clauses.

I assumed the input from cards could be bad

Yep, me too... and it very often was :-)

and thus
tested it using the descriptions of the fields as I wanted them.

Well, I did it similarly, ensuring the input record was defined with what
was required, but then testing each supposedly numeric field in an AN field.
If they all passed, it was safe to proceed. My programs did this stuff in a
VALIDATE-INPUT SECTION. It worked pretty well and I seldom had 0c7 crashes
caused by bad input (usually it was bad programming... Ah, happy days, when
we were learning...:-))

Given
that an alphanumeric field could not be easily moved to a signed
field, I doubt that the intent was to have all input in Alphanumeric
fields.

Maybe. The problem was that with packed fields as soon as you tried to use
them, you'd crash with 0c7. It therefore was better to ensure that what you
stored there was valid...



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

Your assumption is right on the button and you saved me posting the
solution
I would have. :-)

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

That is one reason I believe it to be flawed...

However, if each programmer (site, whatever) does use its own
"component" to do the validation, this could be made to work.

Or... a vendor supplied component could ensure consistency...


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.

Fine. We have no issues. Thanks for a civilized post, Bill.

Pete.

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


.

Quantcast