× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Bob is right about CHECKR and the Canadian codes. Any time data is stored in
a free form field, identifying data elements gets complicated fast. If
allowed, some users might even enter entire state/province names instead of
abbreviations, especially if they have 36 bytes ;). As others have noted,
multiple passes will probably be necessary using SCAN/%SCAN and/or
CHECKR/%CHECKR. Martin's pattern matching suggestion will probably help you
determine whether the results of any given pass contains a valid postal code
pattern or not. No doubt your solution will require extensive testing and
revision before becoming robust enough for production use.

This could be a starting place for you if zip code is the last element of
the field and there is at least one blank at the right side of the field:

D Blank           C                   ' '

D NonBlank        C                   'ABCDEFGHIJKLMNOPQRSTUVWXYZ-
D                                     abcdefghijklmnopqrstuvwxyz-
D                                     1234567890`~!@#$%^&*()''"/+_-'
D StateZip        S             36A
D PostalCode      S             11A
D Pos1            S              5U 0
D Pos2            S              5U 0
D Len             S              5U 0
...
C     Blank         CHECKR    StateZip      Pos1
C     NonBlank      CHECKR    StateZip:Pos1 Pos2
C                   EVAL      Len = Pos1 - Pos2
C                   EVAL      PostalCode = %SUBST(StateZip:Pos2+1:Len)

NonBlank needs to include every character besides a *BLANK that could be in
the field. Also make sure your NonBlank definition doesn't have any blanks
in it.

As noted above, this is not a definitive solution. You might prefer to start
from the left like Bob and work across until you find a valid pattern. You
might test the whole field against every possible postal code pattern, then
figure out what to do if you don't get a match or if you get more than one.
Even if we would sometimes like more, isn't it wonderful RPG gives us so
many options?

Speaking of options, if someone knows a better way to find embedded blanks
starting from the right side of a field than to define all the other
characters in a constant for a CHECKR, I'd like to know about it (unless we
get %SCANR sometime soon, but I won't hold my breath).

Roger Mackie

-----Original Message-----
From: Bob Cozzi (RPGIV) [mailto:cozzi@rpgiv.com]
Sent: Thursday, August 30, 2001 8:04 AM
To: rpg400-l@midrange.com
Subject: RE: Data manipulation

...I'm not sure if CHECKR is what you'd want either, since it would
eliminate Canadian postal codes which include alpha characters as well
as numbers, and usually a space.

-----Original Message-----
From: Martin Rowe [mailto:martin@dbg400.net]
Sent: Thursday, August 30, 2001 8:02 AM
To: rpg400-l@midrange.com
Subject: Re: Data manipulation


> > > Does anyone have a slick way of extracting the postal code?
> > >
> > > The postal code could be US or Canadian.....
... The technique was to XLATE the line
converting all alphas to 'A' ans all numerics to '1', then scan the result
for known postcode patterns. ...

Regards, Martin
...


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.