Testing for NUMERIC values in an EVALUATE statement.
Ubiquitous
it is numeric.
Since I can't use "IS NUMERIC", I am using "'000' THRU '999'" in the WHEN
clause but I
wonder if there is a better way, since values like '0A1' will evalaute as
TRUE in that WHEN
clause?
docd...@panix.com
Ubiquitous <web...@polaris.net> wrote:
>I am testing an alpha-numeric field with an EVALUATE statement to make sure
>it is numeric.
Please do your own homework.
DD
Pete Dashwood
What makes you think you can't use IF NUMERIC?
Try coding...
IF alphanumericField IS NUMERIC AND POSITIVE ...
and see how you go.
Of course if it is longer than 18 bytes, or it can legitimately contain +
or -, or DR or CR, or a currency sign or... but that's enough... this could
be problematic...
You might find some useful code at:
http://primacomputing.co.nz/cobol21/S2NTestServer.aspx
You can experiment with different strings and see what happens...
Pete
--
"I used to write COBOL...now I can do anything."
Ubiquitous
>Ubiquitous wrote:
>> I am testing an alpha-numeric field with an EVALUATE statement to
>> make sure it is numeric.
>> Since I can't use "IS NUMERIC", I am using "'000' THRU '999'" in the
>> WHEN clause but I wonder if there is a better way, since values like
>> '0A1' will evalaute as TRUE in that WHEN
>> clause?
>
>What makes you think you can't use IF NUMERIC?
>
>Try coding...
>
>IF alphanumericField IS NUMERIC AND POSITIVE ...
But using that in my WHEN clause kinda defeats the purpose of using
EVALUATE in the first place, does it not?
Ubiquitous
>Ubiquitous wrote:
>> I am testing an alpha-numeric field with an EVALUATE statement to
>> make sure it is numeric.
>> Since I can't use "IS NUMERIC", I am using "'000' THRU '999'" in the
>> WHEN clause but I wonder if there is a better way, since values like
>> '0A1' will evalaute as TRUE in that WHEN clause?
>
>What makes you think you can't use IF NUMERIC?
>
>Try coding...
>
>IF alphanumericField IS NUMERIC AND POSITIVE ...
>
>You might find some useful code at:
>http://primacomputing.co.nz/cobol21/S2NTestServer.aspx
Hmm, that web page reminds me of a function I once used to determine if
a string was a valid dollar amount. Hmmm...
Arnold Trembley
Have you tried:
EVALUATE TRUE
WHEN alphanumeric field IS NUMERIC AND POSITIVE
do something
WHEN ...
END-EVALUATE.
Ubiquitous
>Ubiquitous wrote:
>> But using that in my WHEN clause kinda defeats the purpose of using
>> EVALUATE in the first place, does it not?
>
>Have you tried:
>
>EVALUATE TRUE
>WHEN alphanumeric field IS NUMERIC AND POSITIVE
> do something
>WHEN ...
>END-EVALUATE.
Dooh! I totally forgot about that version of the EVAULATE statement!
docd...@panix.com
Ubiquitous <web...@polaris.net> wrote:
[snip]
>>Try coding...
>>
>>IF alphanumericField IS NUMERIC AND POSITIVE ...
>
>But using that in my WHEN clause kinda defeats the purpose of using
>EVALUATE in the first place, does it not?
The purpose of EVALUATE is to provide a case-structure in COBOL as an
alternative to cascading IF statements. If you have a need to test a
field for a range or boundary then the most important things are, in the
following order:
1) Adhere to Production standards so your code gets implemented and will
do its job.
2) Write the standards-adhering code so that it does what it is supposed
to do.
3) Make sure that you write it - if at all possible - so that a
stereotypical 2-year programmer can debug it when it blows up at 2:am.
These three criteria can be met in a variety of ways. Is there a
particular reason for your wanting to use a particular construct?
(oh... and please do your own homework)
DD
HeyBub
Best to convert the input string to a real number first. Here's some code
posted some time back that does it
000001 IDENTIFICATION DIVISION.
000002 PROGRAM-ID. A2N.
000003*=================================================================
000004* NAME: ATON - Alpha to Number
000005*
000006* PURPOSE: To convert alphabetic string to a s9(9)v9(9) number
000007*
000008*
000009* USAGE: CALL 'ATON' USING LINK-STRING LINK-RESULT
000010* LINK-STRING X(20)
000011* LINK-RESULT S9(9)V9(9)
000012*
000013* RETURN-CODE 0 = OK, 1 = Result too big, 2 = Too many digits, 3 =
More than one decimal
* 4 = More than one "-", 5 = Invalid character found
000014*
000015*
000027*=================================================================
000030 DATA DIVISION.
000031 FILE SECTION.
000032
000033
000034 WORKING-STORAGE SECTION.
000035
000038 01 unqualified-variables.
000039 05 n binary pic s9(04).
000040 05 lr binary pic s9(04).
000041 05 filler1 pic x.
000042 88 minus-seen value 'y'.
000043
000044 LINKAGE SECTION.
000045 01 input-area .
000046 05 input-byte occurs 20.
000047 10 input-byte-n pic 9.
000048 01 output-number pic s9(09)v9(09).
000049 01 redefines output-number.
000050 05 output-left pic 9(09).
000051 05 output-right.
000052 10 output-byte occurs 9 pic x.
000053
000054
000055
000056 PROCEDURE DIVISION USING input-area, output-number.
000057 initialize unqualified-variables, output-number
000058 perform varying n from 1 by 1 until n > length of input-area
000059 evaluate input-byte (n)
000060 when space
000061 continue
000062 when '0' thru '9'
000063 if lr equal to zero
000064 multiply 10 by output-left
000065 on size error move 1 to return-code
000066 goback
000067 end-multiply
000068 add input-byte-n (n) to output-left
000069 else
000070 if lr greater than length of output-right
000071 move 2 to return-code
000072 goback
000073 end-if
000074 move input-byte (n) to output-byte (lr)
000075 add 1 to lr
000076 end-if
000077 when '.'
000078 if lr equal to zero
000079 move 1 to lr
000080 else
000081 move 3 to return-code
000082 goback
000083 end-if
000084 when '-'
000085 if not minus-seen
000086 set minus-seen to true
000087 else
000088 move 4 to return-code
000089 goback
000090 end-if
000091 when ','
000092 when "'"
000093 when '"'
000094 when x'00'
000095 when '/'
000096 when '+'
000097 continue
000098 when other
000099 move 5 to return-code
000100 goback
000101 end-evaluate
000102 end-perform
000103 if minus-seen
000104 compute output-number = 0 - output-number
000105 end-if
000106 move zero to return-code
000107 goback.
William M. Klein
I don't understand why this thread has continued. The solution of
Evaluate True
When AlhpNum Numeric
Perform OK-stuff
When Other
Perform Not-Numeric
really does EXACTLY what the OP wanted.
Many of the recent posts have given solutions that will ONLY work if the
AlaphNum field *is* numeric which wasn't what the OP wanted. (E.g. use of
NUMVAL)
--
Bill Klein
wmklein <at> ix.netcom.com
Pete Dashwood
> <previous notes snipped>
>
> I don't understand why this thread has continued. The solution of
>
> Evaluate True
> When AlhpNum Numeric
> Perform OK-stuff
> When Other
> Perform Not-Numeric
>
> really does EXACTLY what the OP wanted.
>
> Many of the recent posts have given solutions that will ONLY work if
> the AlaphNum field *is* numeric which wasn't what the OP wanted. (E.g. use
> of NUMVAL)
Yes, that was my thought on it too. Some of these solutions simply aren't
solutions.
I think you need "Numeric AND Positive" in the above, Bill.
Pete.
Doug Miller
>it is numeric.
Why?
I mean, why are you doing this with EVALUATE, instead of IF? EVALUATE is a
clumsy, boneheaded way to test for numeric contents in a field. IF is simple
and straightforward.
>Since I can't use "IS NUMERIC", I am using "'000' THRU '999'" in the WHEN
>clause but I
>wonder if there is a better way, since values like '0A1' will evalaute as
>TRUE in that WHEN
>clause?
IF fieldname IS NUMERIC THEN
<do whatever you need to when it's numeric>
ELSE
<do whatever you need to when it's non-numeric>
END-IF
docd...@panix.com
William M. Klein <wmk...@nospam.ix.netcom.com> wrote:
><previous notes snipped>
>
>I don't understand why this thread has continued.
A reason might be, Mr Klein, is that it was seen rather early on that the
Original Poster was, without posting any code or showing any effort
besides asking 'how do I...?' giving the Typical Appearance of someone who
was trying to get other folks to Do Homework/A Job for them.
(a suggestion I made, long ago, was that folks come up with intricate,
convoluted, subtle solutions which would make almost *any* instructor call
a student over and say 'This is not your work, where did you get this
from?'... seems like some folks recalled this suggestion)
DD
docd...@panix.com
Doug Miller <spam...@milmac.com> wrote:
>In article <xLydnQmJ_ryxOjbX...@giganews.com>, "Ubiquitous"
><web...@polaris.net> wrote:
>>I am testing an alpha-numeric field with an EVALUATE statement to make sure
>>it is numeric.
>
>Why?
Leaving aside my own preference for leaving an unadorned interrogative
particle ('why?') out and replacing it with 'For what reason?' in hope of
introducing reasoning into the discussion... because that's what the
instructor seems to have asked for as homework, it seems.
DD
Howard Brazee
>A reason might be, Mr Klein, is that it was seen rather early on that the
>Original Poster was, without posting any code or showing any effort
>besides asking 'how do I...?' giving the Typical Appearance of someone who
>was trying to get other folks to Do Homework/A Job for them.
Requiring that the answer use an EVALUATE command supported this.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison