Numeric validation revisited

>Can you please post some specific examples of your input and
> the results you are receving? There must be something else we are
> missing.

Ok, I tried to avoid a long problem-definition, but I can now see my
problem is not that easily defined. So, here we go again:

I have a user input fields:

01 VFYS PIC S9(9)V99 COMP-3.
01 VMIN PIC S9(5) COMP-3.
01 VMAX PIC S9(5) COMP-3.
01 LTAN PIC S9(7) COMP-3.

I have to add up a lot of LTAN'es and subtract VFYS from LTAN. Finally
all 4 values are to be printed out.

01 Temp-add-field PIC S9(9)V99 COMP-3.

But first, I move them into a table, contaning an exact copy of the
above fields. This way I can sort them, according to some other
irellevant field.

Then, I move them into a print-line with the fields:

01 PRINTLINE.
..
03 PFYS PIC ZZZ.ZZZ.ZZ9-.
03 PMIN PIC ZZZZ9-.
03 PMAX PIC ZZZZ9-.
03 PTAN PIC ZZZ.ZZZ.ZZ9-.
..

It seems my input-data is garbage (stupid users), because On the
printer it says:

... some-string some-thing-else	437   20202 20202   21


Actually only PMIN and PMAX is the problem.

Darn it that deadline is getting close!


I've been trying and trying. Could one of you maybe tell me where to
look.

Thanks for all your replyes (Binyamin,Docdwarf,Pete,Ron and Walter)


Mark, Denmark.

> I have a user input fields:

> 01 VFYS PIC S9(9)V99 COMP-3.
> 01 VMIN PIC S9(5) COMP-3.
> 01 VMAX PIC S9(5) COMP-3.
> 01 LTAN PIC S9(7) COMP-3.

COMP-3 is packed decimal (probably). Why are you accepting data into
COMP-3.  Why would you not have your input fields as DISPLAY ?

202020202.. is the value of a packed decimal field when the bytes it
occupies has spaces in it. This is a perfectly valid value for a
NUMERIC test for a packed decimal.

If these are in fact the subject of an ACCEPT then it is most likely
that you should be accepting into an alphabetic field and then use
NUMVAL() in a COMPUTE with a ON SIZE ERROR.

klovn wrote: 
>
> Ok, I tried to avoid a long problem-definition, but I can now see my
> problem is not that easily defined. So, here we go again:
>
> I have a user input fields:
>
> 01 VFYS PIC S9(9)V99 COMP-3.
> 01 VMIN PIC S9(5) COMP-3.
> 01 VMAX PIC S9(5) COMP-3.
> 01 LTAN PIC S9(7) COMP-3.
>
> I have to add up a lot of LTAN'es and subtract VFYS from LTAN. Finally
> all 4 values are to be printed out.
>
> 01 Temp-add-field PIC S9(9)V99 COMP-3.
>
> But first, I move them into a table, contaning an exact copy of the
> above fields. This way I can sort them, according to some other
> irellevant field.
>
> Then, I move them into a print-line with the fields:
>
> 01 PRINTLINE.
> ...
> 03 PFYS PIC ZZZ.ZZZ.ZZ9-.
> 03 PMIN PIC ZZZZ9-.
> 03 PMAX PIC ZZZZ9-.
> 03 PTAN PIC ZZZ.ZZZ.ZZ9-.
> ...
>
> It seems my input-data is garbage (stupid users), because On the
> printer it says:
>
> ... some-string some-thing-else 437   20202 20202   21
>
>
> Actually only PMIN and PMAX is the problem.

## No. PMIN and PMAX are SYMPTOMS of the problem

>
> Darn it that deadline is getting close!
>
>
> I've been trying and trying. Could one of you maybe tell me where to
> look.
>
> Thanks for all your replyes (Binyamin,Docdwarf,Pete,Ron and Walter)
>
>
> Mark, Denmark.

I don't see how a user can input a COMP-3 number. Nevertheless, IF you have
a COMP-3 number whose content you cannot control AND you must determine
whether it really IS semi-believable, you could do it the hard way.

Note the last nibble of the last byte must contain "A,B,C,D,E, or F"
(F,A,C,E imply positive). So, you strip off the last nibble and test it for
greater than 9.

Consider:
01  LTAN PIC S9(7) COMP-3.
01  WAMPUM PIC S9(7) COMP-3.
01  WAHOO-X REDEFINES WAMPUM.
02  WAHOO PIC 9(7)  COMP-4.

*> bad data in [ ], good data in { }
Move LTAN to WAMPUM.        [20 20 20 20]   {00 00 12 3F}
Move LOW-VALUES to WAHOO-X(1:3).     [00 00 00 20]    {00 00 00 3F}
Multiply WAHOO by 256.       [00 00 02 00]   {00 00 03 F0}
Move LOW-VALUES to WAHOO-X(1:3).        [00 00 00 00]   {00 00 00 F0}
Divide WAHOO by 256.     [00 00 00 00]    {00 00 00 0F}
If WAHOO > 9
PERFORM WE-HAVE-GOOD-SIGN-NIBBLE
ELSE
PERFORM SPIT-BURNING-BLOOD-ON-USER
END-IF

Of course this scheme fails if the original data contains "BARF," but you
get the idea.

> Ok, I tried to avoid a long problem-definition, but I can now see my
> problem is not that easily defined. So, here we go again:
>
> I have a user input fields:
>
> 01 VFYS PIC S9(9)V99 COMP-3.
> 01 VMIN PIC S9(5) COMP-3.
> 01 VMAX PIC S9(5) COMP-3.
> 01 LTAN PIC S9(7) COMP-3.

How does data get in these fields in the first place? I doubt users are ente
ring
packed decimal data directly. Are your reading from a screen? Moving from
a record or what? I am going to take a pure guess here that you're reading f
rom
a screen and moving into these packed fields. Here's how I would edit the sc
reen
input. I make the assumption that the screen input field can contain 5 chara
cters
plus a sign at end if they want it negative since that's how your fields are
 defined.
I do not like to use function numval because at least on the IBM mainframe t
he stupid
thing abends if the data is not valid to start with making it useless for th
e most part.

This is technique I use quite a bit and should work for most any size field.
 But I
have not compiled the exact code I've put here so suggestions for improvemen
ts
or noting dumb syntax errors welcome from the peanut gallery.


01 inp-x  pic x(6).
01 inp-9 pic S9(5) sign trailing separate.
01 inp-work redefines inp-9.
05 inp-data pic x(5) justified right.
05 inp-sign pic x.
01 tally-c pic 9(4) comp.
01 beg-char pic 9(4) comp.
01 end-char pic 9(4) comp.

move spaces to inp-x.
perform make-them-enter-something-into-inp-x.
if inp-x = spaces
display 'Enter something dumbhead'
go to p-exit
end-if.

* find the first non-blank
move zero to tally-c.
inspect inp-x tallying tallyc-c for leading spaces.
compute beg-char = tally-c + 1

* find the last non-blank
move zero to tally-c.
inspect function reverse (inp-x) tallying tally-c for leading spaces.
compute end-char = length of inp-x - tally-c.

* are there any imbedded blanks
move zero to tally-c.
inspect input-c (beg-char: end-char - beg-char + 1)
tallying tally-c for all spaces.
If tally-c > zero
display 'What kind of junk is this?'
go to p-exit
end-if.

move spaces to inp-work.

* did they enter a sign
if inp-c (end-char:) = '+' or '-'
move inp-c (end-char:) to inp-sign
subtract 1 from end-char
else
move '+' to inp-sign
end-if.

* move it to the work area
move inp-c (beg-char: end-char - beg-char + 1) to inp-data.
inspect inp-data converting spaces to zeros.

* Now FINALLY
if inp-9 is numeric
move inp-9 to VMIN
else
display 'Will you stop entering this crap?'
end-if.

p-exit.
exit.

> Note the last nibble of the last byte must contain "A,B,C,D,E, or F"
> (F,A,C,E imply positive). So, you strip off the last nibble and test
> it for greater than 9.

Will try this. I've never worked on COBOL in the byte-level, it will be
interesting to learn something new.

Very generous giving code-examples and all - is it really that obvious
that I haven't worked with COBOL that much? (Java-programmer Learning
COBOL)

Thank you all !

Mark, Denmark

> Note the last nibble of the last byte must contain "A,B,C,D,E, or F"
> (F,A,C,E imply positive). So, you strip off the last nibble and test
> it for greater than 9.
>
> Consider:
> 01  LTAN PIC S9(7) COMP-3.
> 01  WAMPUM PIC S9(7) COMP-3.
> 01  WAHOO-X REDEFINES WAMPUM.
>     02  WAHOO PIC 9(7)  COMP-4.
>
> *> bad data in [ ], good data in { }
> Move LTAN to WAMPUM.        [20 20 20 20]   {00 00 12 3F}
> Move LOW-VALUES to WAHOO-X(1:3).     [00 00 00 20]    {00 00 00 3F}
> Multiply WAHOO by 256.       [00 00 02 00]   {00 00 03 F0}
> Move LOW-VALUES to WAHOO-X(1:3).        [00 00 00 00]   {00 00 00 F0}
> Divide WAHOO by 256.     [00 00 00 00]    {00 00 00 0F}
> If WAHOO > 9
>    PERFORM WE-HAVE-GOOD-SIGN-NIBBLE
> ELSE
>   PERFORM SPIT-BURNING-BLOOD-ON-USER
> END-IF

Hi again,

Tried some variations of what you suggested, and it seems smart in
theory, but first of all I can't use COMP-4 fields (probably due to my
COBOL-environment)

Anyways, I try with these:

01 copy-of-field 	PIC S9(7) COMP-3.
01 WAMPUM 		PIC s9(7) cOMP-3.
01 WAHOO-X REDIFINES WAMPUM.
02 WAHOO 	PIC S9(7) COMP.

But, when I multiply, I move 2 places instead of 1.

---------------------
Ex. of my Crap data:

copy gives hex-value: (20 20 20 00)

clear first two:      (00 00 20 00)

multiply gives:       (00 20 00 00)

clear:                (00 00 00 00)

----------------------

Ex. of good data: (value decimal 60)

copy                  (0C 06 00 00)

CLEAR                 (00 00 00 00)

Well, that doesn't get me far.

And why do I get the value (0c 06 00 00) instead of 3C, which gives the
decimal 60.

Sorry, I'm just  now!

 Mark, Denmark

> Tried some variations of what you suggested, and it seems smart in
> theory, but first of all I can't use COMP-4 fields (probably due to my
> COBOL-environment)

WHY ARE YOU USING COMP FIELDS AT ALL ????

> Anyways, I try with these:
> 01 copy-of-field        PIC S9(7) COMP-3.

> 01 WAMPUM               PIC s9(7) cOMP-3.
> 01 WAHOO-X REDIFINES WAMPUM.
>        02 WAHOO        PIC S9(7) COMP.

You obviously have no idea what COMP-3 is, nor what COMP is. The
redefine does you no good at all and will simply give you complete
junk.

> Sorry, I'm just  now!

Use your text editor to replace all instances of "COMP-3" and of "COMP"
with "DISPLAY".

Mark Vilstrup Svanesteen wrote: 
>
> Hi again,
>
> Tried some variations of what you suggested, and it seems smart in
> theory, but first of all I can't use COMP-4 fields (probably due to my
> COBOL-environment)

COMP-4 is implementor-defined. I meant it to be straight binary.

>
> Anyways, I try with these:
>
> 01 copy-of-field PIC S9(7) COMP-3.
> 01 WAMPUM PIC s9(7) cOMP-3.
> 01 WAHOO-X REDIFINES WAMPUM.
> 02 WAHOO PIC S9(7) COMP.
>
> But, when I multiply, I move 2 places instead of 1.
>
> ---------------------
> Ex. of my Crap data:
>
> copy gives hex-value: (20 20 20 00)

This is a bizarre result.

>
> clear first two:      (00 00 20 00)

Clear first two? I cleared the first three.

>
> multiply gives:       (00 20 00 00)
>
> clear:                (00 00 00 00)
>
> ----------------------
>
> Ex. of good data: (value decimal 60)
>
> copy                  (0C 06 00 00)

Impossible. 60 = 00 00 06 0C

>
> CLEAR                 (00 00 00 00)
>
> Well, that doesn't get me far.
>
> And why do I get the value (0c 06 00 00) instead of 3C, which gives
> the decimal 60.
>
> Sorry, I'm just  now!
>
>  Mark, Denmark

Well, work with what you've got. If YOUR comp-3 numbers look like 60 = 0C 06
00 00, do whatever's necessary to isolate the "C" nibble and test it.

You've probably got an Intel chip where [ab cd ef gh] => [dc ba hg fe] when
viewed in hex.

In article <1118440179.099130.183730@z14g2000cwz.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote: 
>
>WHY ARE YOU USING COMP FIELDS AT ALL ????

Mr Plinston, you might be sufficiently courteous to allow for a response
to an inquiry before offering further advice.

[snip]
 
>
>Use your text editor to replace all instances of "COMP-3" and of "COMP"
>with "DISPLAY".

... and do this *before* determining if these occur in a File
Description... or an area in WORKING-STORAGE that is the object of a READ
INTO... or as part of a field used to determine numeric validity, as was
shown in another posting...

... and stand back as your problems reaching deadline vanish... and I can
assure of this because I am the King of England.

DD

<docdwarf@panix.com> wrote in message news:d8endv$5v6$1@panix5.panix.com...
> In article <1118440179.099130.183730@z14g2000cwz.googlegroups.com>,
> Richard <riplin@Azonic.co.nz> wrote: 
>
> Mr Plinston, you might be sufficiently courteous to allow for a response
> to an inquiry before offering further advice.

Mr Dwarf, thirty-siz hours had passed since Mr Plinston's
earlier comment. One for which there was no response.

----begin quote
COMP-3 is packed decimal (probably). Why are you accepting data into
COMP-3.  Why would you not have your input fields as DISPLAY ?
----end quote

> [snip]
> 
>
> ... and do this *before* determining if these occur in a File
> Description... or an area in WORKING-STORAGE that is the object of a READ
> INTO... or as part of a field used to determine numeric validity, as was
> shown in another posting...

The posting to which Mr Plinston responded showed.

----begin quote
> I have a user input fields:

> 01 VFYS PIC S9(9)V99 COMP-3.
> 01 VMIN PIC S9(5) COMP-3.
> 01 VMAX PIC S9(5) COMP-3.
> 01 LTAN PIC S9(7) COMP-3.
----end quote

This seems unlikely to be any of file, read into, or partial field,
as described above.

Furthermore, I am  why others would attempt
to impose IBM knowledge (sign nibbles, COMP-4, and
byte-ordering)  on a DEC problem ... the earliest post, under
the subject "Numeric validation", stated "I use cobol v2.7 on
an alpha-system(7.3.1)", for which I take 'alpha-system' to
mean DEC.

As a "Java-programmer Learning COBOL", it is no wonder
that Mr Svanesteen is  ... but there is hope ... use
DISPLAY instead of COMP-3, as suggested by Mr Plinston.