|
View previous topic :: View next topic
|
| Author |
Message |
ram_vizag
Active User
Joined: 21 Aug 2008
Posts: 112
Location: hyd
|
|
|
|
i'm having a field ws-cust-name. i chould not allow only special characters. how to validate.is there any simple condition???or byte by byte i should validate????
please some one help.... |
|
| Back to top |
|
 |
kratos86
Active User
Joined: 17 Mar 2008
Posts: 148
Location: Anna NGR
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| ram_vizag wrote: |
i'm having a field ws-cust-name. i chould not allow only special characters. how to validate.is there any simple condition???or byte by byte i should validate????
please some one help.... |
Can you be a little clearer about "special characters" that are invalid?
For instance, hyphen, apostrophe are valid in many "European" names. I have seen ampersand ("MR & MRS KEITH JONES"), plus (the more modern "JOAN + KEVIN"), parentheses ("(NEE BRACEWELL)"), periods ("LT. COL."), slashes ("JOHN/SIMON").
Basically we didn't bother validating, but relied on the data-entry and the sight-check of the reports, and the customer pointing it out.
Bit us once, so if you are doing any address processing, that's the time to check that your addresses will work with whatever is processing them.
Of course, your local situation might preclude a number of the above, but I'd still be interested in the requirement to actually validate someone's name. After all, how are you going to do it for the letters in the name itself? How are you going to catch the typos? If you can't do that (and I really suspect you can't) why go to big bother doing only part of the job, and the part that is the easiest for data entry/clerks within your organisation to notice? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
as usual, the application analysis is pretty poor..
with what kind of customer names is the OP dealing,
I remember quite heated discussions on <name> checking,
the criteria used for <personal> names where only alphabets were/are allowed
were/are quite different from the criteria for business denominations where usually anything will go
anyway the application is poorly designed period
and also the skills to design good applications are getting scarce
I thought that more modern applications would deal with personal data in a more clever way
and... Bill I feel that the forms You are talking about should fall more probably into the category <addressed as>/<denomination> not truly names
and addressed as/denomination might constitute a category as where anything will go
and if a current account had as denomination Mr & Mrs Henry Jones
somewhere in the bank' s databases there will certainly be two entries, one for Henry Jones and the other for whatever name his wife |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
enrico,
I think yes, and no.
Some are irrevocably associated with names.
| Code: |
RONALD SMITH-TIMKINSON
BILL O'BOYLE |
(if you don't mind being an example, Bill!).
You can have a "title" (MR, MRS, MS etc) but you do then need to maintain that for "valid" situations, which at the end comes down to (in the case I'm thinking of) "whatever the client wants". Hence, our Lt. Colonel. If you stick in all the military ones, you get a lot, yet most you might not use (depending on business application).
I missed the commas earlier, for those who insist on MD, or even their university qualifications, being appended to their name.
The application I'm thinking of was Mail Order. We processed lots of addresses, came across lots of "interesting" things we'd not considered (surnames from Sri Lankan to Vietnamese).
The number of spurious characters we actually found in our analysis was very small, and we found a lot of valid "special characters". We discussed with the users, and they pointed out the obvious to us - it was a bit intrusive of the computer system to insist on how a client should present their name to us, and how we should address them.
So, we stuck with the typical, a 30-byte lump for the name. We did "edit" (in the old sense) new/changed addresses, so that what didn't fit the known patterns (comma missing before MD, that sort of thing) could be corrected. We decided that trying to be more "clever" would mean too many resources on the name processing for little, if any, payback.
When using the name for various purposes, we treated it in a relevant manner (upper-case, lower-case, last name, first name, full name for address, etc).
Biggest problem we really had was holding the name solely in upper-case on the file, not capturing what the customer had written (original data-entry on 40x12 screens with no lower-case - plus every external tape we used also only could provide upper-case). How do you then get MacDonald back, whilst not screwing up Macer? Fun.
Now, TS might want local-style names, which I know nothing about. Or, it might be "outsourced" stuff with a lot of "European" names that he knows little about.
My thought is he can't toss a blanket and exclude all "special characters" and give the client the name how the client writes it. On the other hand, the effort to do the full processing is, to me, substantial - and then what does it give to his system?
Yes, it would be nice to google and find that someone has done all the proper analysis and published a rational system for a particular cultural set-up. I haven't checked :-)
For my joint bank account, I had to fill in "how you want your account name to appear". We do also get seperate mail (like for a new card on expiry of the old). But we also filled in individual name/address details, which, due to input errors, we know are held seperately.
It is much more complex than it seems at first, name processing. The name and the address through the window of the envelope is often the first point of contact between business/client. How many times have you, personally, said "these idiots can't even get my name/address right". You try correcting it? Next time it is "these idiots can't even get my name/address right when I tell them (x) times".
My advice for a situation with data-entry clerks is not to "bounce" any name/address data errors back at them for newly captured addresses. It won't be corrected by the data-entry clerk (takes too long to look at it, they have "targets" to meet, and even then won't know what to do), so it'll go straight on the pile for manual correction before re-entry anyway. So capture it as is, do what you can, list it out for a more knowledgeable type of clerk who knows their business, not just how to key data.
I admit, I might be outdated in all of the above :-) |
|
| Back to top |
|
|
seagull
New User
Joined: 28 May 2007
Posts: 24
Location: Dublin
|
|
|
|
| Some systems are set to drop all the special characters, and even prefixes, from names - e.g. O'Brien becomes Brien, McDonald becomes Donald, Van Rensburg becomes Rensburg. We had to do a match of our name and address file to a system like that, and it took me a long time and many headaches to strip out everything to get as good a match as possible. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Wow, ugly and absurd. Did it ever produce cheques for people with the invented names?
Name/address matching across systems. You have to get fuzzy. |
|
| Back to top |
|
|
seagull
New User
Joined: 28 May 2007
Posts: 24
Location: Dublin
|
|
|
|
| It was the property registry office or some such. It's a really bizarre way of storing names, but it meant they always had a clean database. We wanted to do a comparison, so we had to get our name/address data into their format. It was fun when our name field was basically free format. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
my experience comes from banking and accounting/financial
where the <names> not the <denomination>/<addressed as> must match the public records |
|
| Back to top |
|
|
rajesh_mbt
New User
Joined: 27 Mar 2006
Posts: 97
Location: India
|
|
|
|
| ram_vizag wrote: |
i'm having a field ws-cust-name. i chould not allow only special characters. how to validate.is there any simple condition???or byte by byte i should validate????
please some one help.... |
Hope, this would help your question..
| Code: |
05 WS-CHAR-CHECK PIC X(1).
88 VALID-CHAR VALUE A' THRU 'Z'.
05 WS-ERROR-SW PIC X(1) VALUE 'N'.
88 NAME-ERROR VALUE 'Y'
PROCEDURE DIVISON.
PERFORM WS-SUB 1 BY 1 UNTIL WS-SUB > NAME-LENGTH
IF WS-NAME[WS-SUB] = VALID-CHAR
CONTINUE
ELE
SET NOT-VALID-CHAR TO TRUE
END-IF
END-PERFORM
|
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Well, it's nice to see you trying to help someone back.
However, if this was intended as a complete solution, it needs a bit of work. If a general pointer, it would be best to say so. |
|
| Back to top |
|
|
rajesh_mbt
New User
Joined: 27 Mar 2006
Posts: 97
Location: India
|
|
|
|
One small correction, the if logic should be as
| Code: |
IF WS-NAME(WS-SUB:1) = VALID-CHAR
|
Bill, I have to give it back where I got it!! am I right :-) |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
An admirable thought :-) doesn't happen enough.
You have a few errors the compiler would pick up. Space should also be valid for your 88.
You are going in the right direction for a solution which would work, but asis, there are many holes.
If you are going for a complete solution, take some more time, work it through so that what you provide works as a general piece of code. |
|
| Back to top |
|
|
ram_vizag
Active User
Joined: 21 Aug 2008
Posts: 112
Location: hyd
|
|
|
|
| Hi, thanks every one...rajesh your code is working... |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Oh well,
we have only posted on this forum about 1000 times,
VALUE A' THRU 'Z'. will not work,
you need
VALUES A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z'.
because I is hex C9 and J is hex D1 (similar for R and S).
you want to avoid hex CA CB CC CD CE and CF
which A thru Z will not do.
and the syntax is
IF 88-level(INDEX or Subscript) TRUE
the example provided will not compile,
but if RAM has a solution,
great. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Plus, if you are not worried at all about "special characters", so only letters and space, you can test the whole field at once for ALPHABETIC.
I've never thought about which is more efficient. Let us know, maybe. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Hi, thanks every one...rajesh your code is working... |
Not completely - all this means is that the testing was not thorough.
As DBZ mentioned, there are values between A and Z that are not alphabetic. The "}" (x'C0') and the "\" (x'D0) are both "printable/typeable} and are not alphabetic . . . |
|
| Back to top |
|
|
ram_vizag
Active User
Joined: 21 Aug 2008
Posts: 112
Location: hyd
|
|
|
|
Hi Dick Brenholtz,
You are correct. i agree with you. infact i only checked the logic of rajesh code, not how the declaration of the values or variables...And I have a solution. the following code worked for me for validation of a field which should not have any special variables...here it goes...
cust-name is the field which have pic x(40).Remaining are working storage variables i have not mentioned them over here...
WORKING-STORAGE SECTION.
05 WS-VALIDATION PIC X(01).
88 WS-VALIDATION-Y VALUE 'Y'.
88 WS-VALIDATION-N VALUE 'N'.
05 WS-INVALID PIC X(01).
88 WS-VALID-NAME VALUE 'Y'.
88 WS-INVALID-NAME VALUE 'N'.
05 WS-CUSTOMER-NAME.
10 WS-CUST-NAME OCCURS 40 TIMES.
15 WS-CUST-NAME-CHAR PIC X(01).
........................................................................................
MOVE SPACES TO WS-CUSTOMER-NAME
MOVE CUST-NAME TO WS-CUSTOMER-NAME
MOVE +1 TO WS-SUB1
SET WS-VALIDATION-Y TO TRUE
PERFORM UNTIL WS-SUB1 > 40
OR WS-VALIDATION-N
IF WS-CUST-NAME-CHAR(WS-SUB1) NUMERIC OR
WS-CUST-NAME-CHAR(WS-SUB1) ALPHABETIC
CONTINUE
ELSE
IF WS-CUST-NAME-CHAR(WS-SUB1) NOT = SPACES
SET WS-INVLAID-NAME TO TRUE
SET WS-VALIDATION-N TO TRUE
END-IF
END-IF
ADD +1 TO WS-SUB1
END-PERFORM
............................................................................................... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| ram_vizag wrote: |
Hi Dick Brenholtz,
You are correct. i agree with you. infact i only checked the logic of rajesh code, not how the declaration of the values or variables...And I have a solution. the following code worked for me for validation of a field which should not have any special variables...here it goes...
cust-name is the field which have pic x(40).Remaining are working storage variables i have not mentioned them over here...
WORKING-STORAGE SECTION.
05 WS-VALIDATION PIC X(01).
88 WS-VALIDATION-Y VALUE 'Y'.
88 WS-VALIDATION-N VALUE 'N'.
05 WS-INVALID PIC X(01).
88 WS-VALID-NAME VALUE 'Y'.
88 WS-INVALID-NAME VALUE 'N'.
05 WS-CUSTOMER-NAME.
10 WS-CUST-NAME OCCURS 40 TIMES.
15 WS-CUST-NAME-CHAR PIC X(01).
........................................................................................
MOVE SPACES TO WS-CUSTOMER-NAME
MOVE CUST-NAME TO WS-CUSTOMER-NAME
MOVE +1 TO WS-SUB1
SET WS-VALIDATION-Y TO TRUE
PERFORM UNTIL WS-SUB1 > 40
OR WS-VALIDATION-N
IF WS-CUST-NAME-CHAR(WS-SUB1) NUMERIC OR
WS-CUST-NAME-CHAR(WS-SUB1) ALPHABETIC
CONTINUE
ELSE
IF WS-CUST-NAME-CHAR(WS-SUB1) NOT = SPACES
SET WS-INVLAID-NAME TO TRUE
SET WS-VALIDATION-N TO TRUE
END-IF
END-IF
ADD +1 TO WS-SUB1
END-PERFORM
............................................................................................... |
Code tags, code tags, tra-la-la-la-laa.
I just wondered if singing it would make it more likely to happen. Probably not :-)
Best to use copy/paste. Avoids typos like "INVLAID".
Also, it is difficult to know if you have put everything in. In your snippet, you do not set to WS-VALID-NAME ever.
| Code: |
MOVE SPACES TO WS-CUSTOMER-NAME
MOVE CUST-NAME TO WS-CUSTOMER-NAME |
It is completely unnecessary to do the MOVE SPACES and then immediately follow with a move to the same receiving field. It serves no purpose other than to confuse (to cause the later reader of the program to wonder what has been deleted in between the two, why the MOVE SPACES is still there, and how the heck they are going to find the answer).
You never mentioned that numerics would be valid in your names?
Space is covered by the ALPHABETIC test, again your IF will make a reader wonder unnecessarily. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Code: |
WORKING-STORAGE SECTION.
05 WS-NAME-VALIDATION-SUB COMP PIC S9(4).
05 WS-NAME-VALIDATION-MAX COMP PIC S9(4) VALUE +40.
05 WS-NAME-VALIDATION-CHECK COMP PIC S9(4).
05 WS-VALIDATION PIC X(01).
88 WS-VALIDATION-Y VALUE 'Y'.
88 WS-VALIDATION-N VALUE 'N'.
05 WS-INVALID PIC X(01).
88 WS-VALID-NAME VALUE 'Y'.
88 WS-INVALID-NAME VALUE 'N'.
05 WS-CUSTOMER-NAME.
10 WS-CUST-NAME OCCURS 40 TIMES.
15 WS-CUST-NAME-CHAR PIC X(01).
........................................................................................
* somewhere where starting up your program
* divide length-of ws-customer-name by length-of ws-cust-name-char giving WS-NAME-VALIDATION-CHECK
* test that WS-NAME-VALIDATION-MAX equals WS-NAME-VALIDATION-CHECK and abend if not. Someone has changed the table without getting everything right. A little "belt-and-braces" thing. Doesn't hurt to do a little bit of self-checking.
........................................................................................
MOVE CUST-NAME TO WS-CUSTOMER-NAME
MOVE +1 TO WS-NAME-VALIDATION-SUB
SET WS-VALIDATION-Y TO TRUE
SET WS-VALID-NAME TO TRUE
PERFORM
UNTIL ( WS-NAME-VALIDATION-SUB > WS-NAME-VALIDATION-MAX )
OR ( WS-VALIDATION-N )
IF ( WS-CUST-NAME-CHAR ( WS-NAME-VALIDATION-SUB ) NUMERIC )
OR ( WS-CUST-NAME-CHAR ( WS-NAME-VALIDATION-SUB ) ALPHABETIC )
CONTINUE
ELSE
SET WS-INVALID-NAME TO TRUE
SET WS-VALIDATION-N TO TRUE
END-IF
ADD +1 TO WS-NAME-VALIDATION-SUB
END-PERFORM |
[/quote]
Note: I am not claiming that this is perfect.
- It is not my code :-)
- Looking back over the years, I know that the way I write code now can be improved on later
This is to try to show how things can be made clearer by expending little or no extra effort (when you get in the habbit, there is no extra effort if that is the way you do it).
The reason for "WS-NAME-VALIDATION-SUB" is this:
| Code: |
ADD +1 TO WS-NAME-VALIDATION-SUB
ADD +1 TO WS-SUB2 |
Then ask, which of the above is incorrect in the above PERFORM and in the original? Help yourself, help the maintenance/support. Meaningful names, for everything. |
|
| Back to top |
|
|
|
|
