Home > Archive > Cobol > March 2008 > Numeric comparison
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Numeric comparison
|
|
|
| I am having an issue comparing numeric fields and it seems it should
be easy. The field is Telephone it is deifines in input as pic x(12).
it can include dashes.
The first thing I do is check to see if there are dashes. If so I
strip out the dashes and move the phone number field to a WS-telephone
pic 9(10). then it goes thru a edit-input-field that is used in many
programs we have. The routine makes sure there isn't any alphanumeric
characters. After it goes thru that routine It moves a pic 9(12)
field to ws-input-tele-n field (pic 9(12)). So it would be something
like 007705051234. I need to make sure that it is either between
1000000 and 9999999 or 1000000000 and 9999999999. Any ideas on a
better way to accomplish this?
| |
| tlmfru 2008-03-09, 6:55 pm |
| At its most straightforward, if a bit redundant:
if ws-input-tele-n > 999999 and < 10000000
(do good stuff)
else
if ws-input-tele-n > 999999999 and < 10000000000
(do good stuff)
else
(do bad-stuff)
end-if.
Surely there must be more to it than this???
PL
jeff <jmoore207@gmail.com> wrote in message
news:93c4d8b5-f1dc-411e-96bd-9487ab83529a@8g2000hse.googlegroups.com...
> I am having an issue comparing numeric fields and it seems it should
> be easy. The field is Telephone it is deifines in input as pic x(12).
> it can include dashes.
> The first thing I do is check to see if there are dashes. If so I
> strip out the dashes and move the phone number field to a WS-telephone
> pic 9(10). then it goes thru a edit-input-field that is used in many
> programs we have. The routine makes sure there isn't any alphanumeric
> characters. After it goes thru that routine It moves a pic 9(12)
> field to ws-input-tele-n field (pic 9(12)). So it would be something
> like 007705051234. I need to make sure that it is either between
> 1000000 and 9999999 or 1000000000 and 9999999999. Any ideas on a
> better way to accomplish this?
>
| |
|
| On Mar 9, 6:41=A0pm, "tlmfru" <la...@mts.net> wrote:
> At its most straightforward, if a bit redundant:
>
> if ws-input-tele-n > 999999 and < 10000000
> =A0 =A0(do good stuff)
> else
> if ws-input-tele-n > 999999999 and < 10000000000
> =A0 =A0(do good stuff)
> else
> =A0 =A0(do bad-stuff)
> end-if.
>
> Surely there must be more to it than this???
>
> PL
>
> jeff <jmoore...@gmail.com> wrote in message
>
> news:93c4d8b5-f1dc-411e-96bd-9487ab83529a@8g2000hse.googlegroups.com...
>
>
>
>
> - Show quoted text -
That is exactly the comparison I am doing and it never go es thru the
code. Its crazy!
| |
| William M. Klein 2008-03-09, 6:55 pm |
| I haven't tried this (or worked in out in detail) but just a possible thought.
1) Use inspect TALLYING to determine if there are 7, 10, or some other number of
digits in the alphanumeric field.
2) If 7 - check for groups of 3 then 4 digits (with an optional single dash
between)
3) if 8 check for groups of 3, then 3, then 4 digits (again with optional single
dash)
4) Otherwise do error processing.
--
Bill Klein
wmklein <at> ix.netcom.com
"jeff" <jmoore207@gmail.com> wrote in message
news:93c4d8b5-f1dc-411e-96bd-9487ab83529a@8g2000hse.googlegroups.com...
>I am having an issue comparing numeric fields and it seems it should
> be easy. The field is Telephone it is deifines in input as pic x(12).
> it can include dashes.
> The first thing I do is check to see if there are dashes. If so I
> strip out the dashes and move the phone number field to a WS-telephone
> pic 9(10). then it goes thru a edit-input-field that is used in many
> programs we have. The routine makes sure there isn't any alphanumeric
> characters. After it goes thru that routine It moves a pic 9(12)
> field to ws-input-tele-n field (pic 9(12)). So it would be something
> like 007705051234. I need to make sure that it is either between
> 1000000 and 9999999 or 1000000000 and 9999999999. Any ideas on a
> better way to accomplish this?
>
| |
|
| In article <93c4d8b5-f1dc-411e-96bd-9487ab83529a@8g2000hse.googlegroups.com>,
jeff <jmoore207@gmail.com> wrote:
[snip]
>Any ideas on a
>better way to accomplish this?
I have a few... but they depend on your source data. If you can tell us
the country-of-origin of the majority of your source data it would be a
help.
(there... wasn't that nicer than 'please do your own homework'?)
DD
| |
|
| On Mar 9, 7:26=A0pm, docdw...@panix.com () wrote:
> In article <93c4d8b5-f1dc-411e-96bd-9487ab835...@8g2000hse.googlegroups.co=
m>,
>
> jeff =A0<jmoore...@gmail.com> wrote:
>
> [snip]
>
>
> I have a few... but they depend on your source data. =A0If you can tell us=
> the country-of-origin of the majority of your source data it would be a
> help.
>
> (there... wasn't that nicer than 'please do your own homework'?)
>
> DD
Thanks for everyone's help. It was a field size issue!
| |
| HeyBub 2008-03-09, 9:56 pm |
| jeff wrote:
> I am having an issue comparing numeric fields and it seems it should
> be easy. The field is Telephone it is deifines in input as pic x(12).
> it can include dashes.
> The first thing I do is check to see if there are dashes. If so I
> strip out the dashes and move the phone number field to a WS-telephone
> pic 9(10). then it goes thru a edit-input-field that is used in many
> programs we have. The routine makes sure there isn't any alphanumeric
> characters. After it goes thru that routine It moves a pic 9(12)
> field to ws-input-tele-n field (pic 9(12)). So it would be something
> like 007705051234. I need to make sure that it is either between
> 1000000 and 9999999 or 1000000000 and 9999999999. Any ideas on a
> better way to accomplish this?
Your attack to strip out all the non-essential stuff then put dashes or
whatever back where you want them is a good approach. A couple of
observations:
1. How do you handle: WAtermelon-U-8-1-2-Green or 1-800-EAT-SHIT? I'd have a
TALLY REPLACING to convert ABC = 2, DEF=3, etc. before the numeric
validation.
2. Moving the result to a numeric field is not the best practice. Numeric
fields (in my view) should be used for fields on which arithmetic can be
performed. That means that telephone numbers, social security numbers, ZIP
codes, part identifiers, and so on should be alphanumeric.
For example, suppose you have postal codes defined as numeric and your
company opens a branch office in Canada. Canada uses letters for postal
codes, some of which are in French. Big re-write.
| |
|
| In article <93673da5-5d3f-4806-bd1c-b419ccb842de@47g2000hsb.googlegroups.com>,
jeff <jmoore207@gmail.com> wrote:
>On Mar 9, 7:26_pm, docdw...@panix.com () wrote:
>
>Thanks for everyone's help. It was a field size issue!
You're quite welcome... so just for curiousity's sake, what was the
country-of-origin of the majority of your source data?
DD
| |
| Pete Dashwood 2008-03-10, 3:55 am |
|
--
"I used to write COBOL...now I can do anything."
"jeff" <jmoore207@gmail.com> wrote in message
news:93c4d8b5-f1dc-411e-96bd-9487ab83529a@8g2000hse.googlegroups.com...
>I am having an issue comparing numeric fields and it seems it should
> be easy. The field is Telephone it is deifines in input as pic x(12).
> it can include dashes.
> The first thing I do is check to see if there are dashes. If so I
> strip out the dashes and move the phone number field to a WS-telephone
> pic 9(10). then it goes thru a edit-input-field that is used in many
> programs we have. The routine makes sure there isn't any alphanumeric
> characters. After it goes thru that routine It moves a pic 9(12)
> field to ws-input-tele-n field (pic 9(12)). So it would be something
> like 007705051234. I need to make sure that it is either between
> 1000000 and 9999999 or 1000000000 and 9999999999. Any ideas on a
> better way to accomplish this?
>
Jeff, here's a thought: Why validate phone numbers at all?
They are NOT valid unless you actually dial them and get a pick up.
Phone numbers can contain all kinds of characters: +64 7 1234567,
1-800-CALLME, ... not just dashes. It is a pointless validation.
The primary use of this information is so a Human can use it to make a call.
Humans can see immediately whether what is recorded is a phone number or
not.
I get really annoyed with Web pages (for instance) that try to validate a
phone number and DON'T recognise + (the symbol for your international access
code) or ALPHANUMERIC phone strings. in fat, as a user it is so frustrating
to have a page constrain you to what some programmer considers to be the
"right" way to enter a phone number, that I have simply gone and shopped
elsewhere. I figure if their data forms are not friendly, there is no reason
to expect their company will be friendly if I need service or support.
In my systems I don't validate phone numbers and no one has ever complained.
I completely agree with HeyBub that only numbers you intend to do arithmetic
on should be stored as NUMERIC types.
That rules out phone numbers.
Pete.
--
"I used to write COBOL. Now I can do anything."
| |
|
| On Mon, 10 Mar 2008 15:56:54 +1300, Pete Dashwood wrote:
> In my systems I don't validate phone numbers and no one has ever complained.
>
> I completely agree with HeyBub that only numbers you intend to do arithmetic
> on should be stored as NUMERIC types.
>
> That rules out phone numbers.
>
> Pete.
Agree.
The main effect of telephone number validation seems be, making it hard to
enter phone numbers. I have lost count of US sites that insist all phone
numbers are 7 digits. It isn't so!
Addresses are another thing - it can be very important to have a valid
address for someone who owes you money. There is software around to
validate addresses. Some packages even include a database of all known
valid addresses. Still you get a lot of false negatives.
Tim
| |
| HeyBub 2008-03-10, 9:56 pm |
| Pete Dashwood wrote:
>
> Jeff, here's a thought: Why validate phone numbers at all?
>
> They are NOT valid unless you actually dial them and get a pick up.
>
> Phone numbers can contain all kinds of characters: +64 7 1234567,
> 1-800-CALLME, ... not just dashes. It is a pointless validation.
>
> The primary use of this information is so a Human can use it to make
> a call. Humans can see immediately whether what is recorded is a
> phone number or not.
>
> I get really annoyed with Web pages (for instance) that try to
> validate a phone number and DON'T recognise + (the symbol for your
> international access code) or ALPHANUMERIC phone strings. in fat, as
> a user it is so frustrating to have a page constrain you to what some
> programmer considers to be the "right" way to enter a phone number,
> that I have simply gone and shopped elsewhere. I figure if their data
> forms are not friendly, there is no reason to expect their company
> will be friendly if I need service or support.
> In my systems I don't validate phone numbers and no one has ever
> complained.
> I completely agree with HeyBub that only numbers you intend to do
> arithmetic on should be stored as NUMERIC types.
>
> That rules out phone numbers.
>
Your community is evidently not plagued with robo-calling machines.
In the U.S., these machines call the number and when you pick up, the call
is routed to the next available agent. If you don't pick up, the machine
goes to the next number.
There is sometimes a significant delay between when you pick up and when a
human gets on the line. Often, when you answer, you'll get the message "We
have an important call for you. Please hold the line."
After a wait, a voice comes on: "Hello, may I speak to Mr. X, please." To
which I respond: "I'm sorry, he's no longer with us. You've reached the
Suicide Prevention Hot Line. Can someone else help?"
| |
| Howard Brazee 2008-03-10, 9:56 pm |
| On Mon, 10 Mar 2008 15:56:54 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Jeff, here's a thought: Why validate phone numbers at all?
>
>They are NOT valid unless you actually dial them and get a pick up.
>
>Phone numbers can contain all kinds of characters: +64 7 1234567,
>1-800-CALLME, ... not just dashes. It is a pointless validation.
>
>The primary use of this information is so a Human can use it to make a call.
>Humans can see immediately whether what is recorded is a phone number or
>not.
I agree 100%. I get so frustrated when a web application doesn't
accept my 80226-2895 zip code, or a phone number has to be entered
with dashes but not parenthesis around the area code, etc.
The only time it needs to be validated in most applications is if the
computer is expected to make a phone call.
I did work for a company that handled subscription request cards. We
needed to do data validation of addresses from around the world. It
was more of a data cleansing thing though. We had a dirty word file
and were looking for joke entries. A harder thing to look for was
duplicate entries that weren't quite filled in the same way. Not an
easy task.
Doing that I learned that there are lots of postal code syntaxes
around the world. But unless you have data cleansing to do, just
make your field large enough to handle any of the postal codes, and
accept whatever they gave you. We're not doing arithmetic with it.
For data cleansing, the check for valid SSaN will be more complete
than the one the OP gave.
| |
| Howard Brazee 2008-03-10, 9:56 pm |
| On Mon, 10 Mar 2008 06:54:56 -0000, tim <TimJ@internet.com> wrote:
>The main effect of telephone number validation seems be, making it hard to
>enter phone numbers. I have lost count of US sites that insist all phone
>numbers are 7 digits. It isn't so!
We have 10 digit local numbers in Colorado, and some businesses
require extensions to be dialed. I remember when dialing out from
Windows wouldn't work because of the built-in editing.
|
|
|
|
|