Numeric validation

Hi all,

Been trying for quite a while now searching for a solution to my
problem..

I use cobol v2.7 on an alpha-system(7.3.1).

Is there a 100% way of telling if a numeric edited field really
contains valid data and not crap data like "20202".

My fields:

01 field1 PIC S9(9)V99 COMP-3

To validate, I've been trying:

IF FIELD1 IS NUMERIC THEN
MOVE FIELD1 TO ...
ELSE MOVE 0 TO ...
END-IF

and,

IF NOT FIELD1 IS NUMERIC THEN
MOVE 0 TO ...
ELSE
MOVE FIELD1 TO ...
END-IF


In my desperation, I've even tried moving field1 to a alfabetic
temporary field and then to see what is there and then convert it back
to numeric.

MOVE FUNCTION NUMVAL (FIELD1) TO ...

MOVE FUNCTION NUMVAL-C (FIELD1) TO ...

Even so, I get "20202" in my recieving field.

My frustration is complete and I'm too far behind schedule, please help
me get a fool-proof way of testing for bad data in numeric edited
fields.

--
Mark

On 08 Jun 2005 12:34:32 GMT "Mark V. Svanesteen"
<mark.svanesteen(snabela)mail.dk> wrote:

:>Been trying for quite a while now searching for a solution to my
:>problem..

:>I use cobol v2.7 on an alpha-system(7.3.1).

:>Is there a 100% way of telling if a numeric edited field really
:>contains valid data and not crap data like "20202".

What is the picture of your numeric edited field?

x'20' is a space in ascii.


:>My frustration is complete and I'm too far behind schedule, please help
:>me get a fool-proof way of testing for bad data in numeric edited
:>fields.

There are consulting firms in the USA which can assist, for a fee.

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

In article <xn0e399p0e5qps000@news.tele.dk>,
Mark V. Svanesteen <mark.svanesteen(snabela)mail.dk> wrote:
>Hi all,
>
>Been trying for quite a while now searching for a solution to my
>problem..
>
>I use cobol v2.7 on an alpha-system(7.3.1).
>
>Is there a 100% way of telling if a numeric edited field really
>contains valid data and not crap data like "20202".

20202 is a perfectly valid number... and it nicely fills a bit of the void
between twenty thousand, two hundred one and twenty thousand, two hundred
three.

>
>My fields:
>
>	01 field1 PIC S9(9)V99 COMP-3

Naughty, naughty... no VALUE clause?  It 'smells' to me like you're
getting SPACES as the uninitialised data (ASCII x'20')... try

01 field1 PIC S9(9)V99 COMP-3 VALUE +0.

... and see what happens.

DD

> :>Is there a 100% way of telling if a numeric edited field really
> :>contains valid data and not crap data like "20202".

Guessing.this would be worth a try...

SPECIAL-NAMES.
CLASS VALID-EDITED-NUMERIC  VALUES  '0' TO ''9-', ',', ','  (and whatever)

IF EDITED-NUMERIC-FIELD  NOT VALID-EDITED-NUMERIC
DISPLAY 'CRAP IN EDITED-NUMERIC FIELD'

.. or something along those lines

MCM

"Mark V. Svanesteen" <mark.svanesteen(snabela)mail.dk> wrote in message
news:xn0e399p0e5qps000@news.tele.dk...
> Hi all,
>
> Been trying for quite a while now searching for a solution to my
> problem..
>
> I use cobol v2.7 on an alpha-system(7.3.1).
>
> Is there a 100% way of telling if a numeric edited field really
> contains valid data and not crap data like "20202".
>
Mark, you didn't say whether that is hex or not. If it isn't, then the field
is valid... If it is, why would you only show two and a half bytes?

> My fields:
>
> 01 field1 PIC S9(9)V99 COMP-3

Is there more to this definition? I see no full stop. Is it redefined so
that it might have spaces in it? Or uninitialized?

>
> To validate, I've been trying:
>
> IF FIELD1 IS NUMERIC THEN
> MOVE FIELD1 TO ...
> ELSE MOVE 0 TO ...
> END-IF
>

That's pretty usual. You might need to say 'NUMERIC AND POSITIVE' to avoid
the possibility of an alpha in the last position of your input field being
considered a sign.

There are several things here that don't add up. This is NOT a numeric
edited field; you said  your problem was with such a field. This is an
internal packed decimal field that will occupy 5 bytes. I would expect you
have moved a field from an input device to this field. If that field had
spaces in it, this field will be invalid. Applying the 'NUMERIC AND
POSITIVE' test above should trap this.


> and,
>
> IF NOT FIELD1 IS NUMERIC THEN
> MOVE 0 TO ...
> ELSE
> MOVE FIELD1 TO ...
> END-IF
>
>
> In my desperation, I've even tried moving field1 to a alfabetic
> temporary field and then to see what is there and then convert it back
> to numeric.
>
> MOVE FUNCTION NUMVAL (FIELD1) TO ...
>
> MOVE FUNCTION NUMVAL-C (FIELD1) TO ...
>
> Even so, I get "20202" in my recieving field.
>

It looks like packed ASCII blanks.

> My frustration is complete and I'm too far behind schedule, please help
> me get a fool-proof way of testing for bad data in numeric edited
> fields.
>

Personally, I use a numeric validation component  (COM) I wrote some time
ago. It will trap anything and allows a single sign and decimal point.

I understand and sympathise with your frustration. We have all been there.
If the suggestion above doesn't work, mail me privately and I'll give you
the source of the validation component (it is written in COBOL), so you
could call it as a subroutine.

Pete.

I am not sure what you are trying to accomplish. I know lot's of people
are going to say comp-3 is implementor dependant, but comp-3 is almost
always packed decimal so lets assume field-1 is packed okay?

But your question is incoherent with the example. A comp-3 field
is by definition NOT numeric edited. Numeric edited is something
like Pic Z,ZZ9 which will never be numeric because of the (possible)
spaces and the comma.

Why can't you say IF field-1 is numeric? If it contains
valid packed data it is numeric, if not it isn't. Note that the sign must
be consistent with the field definition picture otherwise it will test not n
umeric.
It sounds you're saying you are getting garbage or non-numeric data in field
1
that somehow is testing numeric? Can you please post some specific
examples of your input and the results you are receving? There must
be something else we are missing.

A few comp-3 examples:
PIC S999V99  X'12345C' Numeric
X'12345D' Numeric
X'12345F' NOT Numeric
X'020202' NOT Numeric
X'1234AD' NOT Numeric

PIC 999V99   X'12345F' Numeric
X'12345C' NOT Numeric

"Mark V. Svanesteen"  wrote:

[snip]

> My frustration is complete and I'm too far behind schedule, please help
> me get a fool-proof way of testing for bad data in numeric edited
> fields.

First, as others have pointed out, the field you gave in your example is not
numeric edited.  I assume you are asking how to check for valid data in a
numeric data item with usage COMP-3.

Next, COBOL doesn't define what constitutes valid data in a COMP-3 data
item, so it's up to your compiler's implementor to define that and, maybe,
give you a way to test for it.

Finally, as you have perhaps noticed, the NUMERIC class test might be
problematic when applied to a COMP-3 data item.  In standard [1985] COBOL,
you can't do that (even if use a standard usage, such as PACKED-DECIMAL).
If you test for NUMERIC on a COMP-3 field, you are at the mercy of whatever
your particular compiler does for that test.  If you want to reliably test a
numeric data item for valid contents using the NUMERIC class test, the item
must have usage DISPLAY, in other words, it can't be COMP or COMP-3.

So I'm afraid the answer to your question will be specific to the compiler
and platform you are using.

Walter



----== Posted via mcse.ms - Unlimited-Uncensored-Secure Usenet News==-
---
http://www.mcse.ms The #1 Newsgroup Service in the World! 120,000+ New
sgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Wed, 8 Jun 2005 18:07:17 -0500, "Ron" <NoSpam@SpamSucks.Org> wrote:

>I am not sure what you are trying to accomplish. I know lot's of people
>are going to say comp-3 is implementor dependant, but comp-3 is almost
>always packed decimal so lets assume field-1 is packed okay?
>
>But your question is incoherent with the example. A comp-3 field
>is by definition NOT numeric edited. Numeric edited is something
>like Pic Z,ZZ9 which will never be numeric because of the (possible)
>spaces and the comma.
>
>Why can't you say IF field-1 is numeric? If it contains
>valid packed data it is numeric, if not it isn't. Note that the sign must
>be consistent with the field definition picture otherwise it will test not 
numeric.
>It sounds you're saying you are getting garbage or non-numeric data in fiel
d1
>that somehow is testing numeric? Can you please post some specific
>examples of your input and the results you are receving? There must
>be something else we are missing.
>
>A few comp-3 examples:
>PIC S999V99  X'12345C' Numeric
>                        X'12345D' Numeric
>                        X'12345F' NOT Numeric
For IBM COBOL compilers for the z series (nee 390, etc.) whether the
previous value is numeric depends on the NUMPROC option.  If your shop
uses CSP and possibly some other software, the NUMPROC option should
treat it as numeric.
>                        X'020202' NOT Numeric
>                        X'1234AD' NOT Numeric
>
>PIC 999V99   X'12345F' Numeric
>                       X'12345C' NOT Numeric
>
>
>
>