Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Validate a field for not to allow special characters

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
ram_vizag

New User


Joined: 21 Aug 2008
Posts: 92
Location: hyd

PostPosted: Wed Aug 03, 2011 3:33 pm    Post subject: Validate a field for not to allow special characters
Reply with quote

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
View user's profile Send private message

kratos86

Active User


Joined: 17 Mar 2008
Posts: 148
Location: Anna NGR

PostPosted: Wed Aug 03, 2011 4:01 pm    Post subject:
Reply with quote

Check this topic on special names -

http://ibmmainframes.com/viewtopic.php?t=28691&postdays=0&postorder=asc&start=0
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Aug 03, 2011 7:53 pm    Post subject: Re: how to validate a field for not to allow only special ch
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Wed Aug 03, 2011 8:29 pm    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Thu Aug 04, 2011 6:33 am    Post subject:
Reply with quote

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
View user's profile Send private message
seagull

New User


Joined: 28 May 2007
Posts: 24
Location: Dublin

PostPosted: Thu Aug 04, 2011 3:21 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Thu Aug 04, 2011 3:41 pm    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

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
View user's profile Send private message
seagull

New User


Joined: 28 May 2007
Posts: 24
Location: Dublin

PostPosted: Thu Aug 04, 2011 3:49 pm    Post subject:
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Thu Aug 04, 2011 7:04 pm    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

my experience comes from banking and accounting/financial
where the <names> not the <denomination>/<addressed as> must match the public records
Back to top
View user's profile Send private message
rajesh_mbt

New User


Joined: 27 Mar 2006
Posts: 95
Location: India

PostPosted: Sat Aug 06, 2011 1:18 am    Post subject: Re: how to validate a field for not to allow only special ch
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Sat Aug 06, 2011 3:28 am    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

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
View user's profile Send private message
rajesh_mbt

New User


Joined: 27 Mar 2006
Posts: 95
Location: India

PostPosted: Sat Aug 06, 2011 4:24 am    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Sat Aug 06, 2011 4:51 am    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

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
View user's profile Send private message
ram_vizag

New User


Joined: 21 Aug 2008
Posts: 92
Location: hyd

PostPosted: Sat Aug 20, 2011 11:10 pm    Post subject: thanks every one...
Reply with quote

Hi, thanks every one...rajesh your code is working...
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Aug 20, 2011 11:49 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Sun Aug 21, 2011 12:42 am    Post subject: Reply to: how to validate a field for not to allow only spec
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sun Aug 21, 2011 4:04 am    Post subject:
Reply with quote

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
View user's profile Send private message
ram_vizag

New User


Joined: 21 Aug 2008
Posts: 92
Location: hyd

PostPosted: Fri Aug 26, 2011 1:27 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Fri Aug 26, 2011 1:43 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Fri Aug 26, 2011 2:11 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Performing arithmetic on input field zh_lad DFSORT/ICETOOL 3 Tue Dec 06, 2016 8:04 pm
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts How to split the records using the am... vnktrrd DFSORT/ICETOOL 24 Fri Oct 28, 2016 7:33 pm
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts Amount field is getting corrupted whe... thesumitk SYNCSORT 5 Tue Oct 18, 2016 8:20 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us