× 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.


  • Subject: Re: just curious - Number of Parms(numeric zip codes and other crimes against nature)
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Fri, 28 Jul 2000 15:53:33 -0500

So, has anyone started using the EDI manuals, like ANSI X.12, 
for determining field size?  For example, zip code is in Segment 
N4.  It is Element 116.  And in X.12 it is defined as:
116 Postal Code
Type=ID Min=3 Max=15
Code defining international postal zone code excluding punctuation 
and blanks (zip code for United States).

We have manuals defining fields and who uses them?

Of course in the LIN segment, Element 234 would be the item number.
That is defined as:
Type=AN Min=1 Max=48
Identifying number for a product or service.

And who wants to code 48 character item numbers in all their files?
No one.  So what do we do when we have a customer who does?  We create
a customer/part cross reference.





ahaddison@home.com on 07/28/2000 03:16:15 PM
Please respond to RPG400-L@midrange.com@Internet
To:     RPG400-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: just curious - Number of Parms(numeric zip codes and other 
crimes against nature)

Its amazing what "holes" one discovers when one starts dealing internationally  
 :)


Jim Langston wrote:

> Yes, that actually makes very good sense.  I also got bitten by the zip code 
>character issue.
>
> I had written an application for a retail store, full inventory, invoice, 
>a/r, a/p type system.  I
> had made zip codes as 5 numeric.  Everything was fine.  Til 6 months later 
>someone calls
> up from Canada for us to ship them something.  Ooops.  They use a 9X9 X9X 
>type of
> zip code format.  Not only is their characters in there, but it's longer too. 
> We were able to
> kludge that one order, put the zipcode in the address 2 line, but then I had 
>to go through all
> my programs and change them from numeric to character and increase the 
>length..
> Luckily because I had written this thing in Clipper (compiled dBase) once I 
>changed the
> database I didn't have to recompile all the programs because it used dynamic 
>variable
> declaration (declared at run time, not compile time).  Was a pain changing 
>the screens and
> printouts where they showed up though.
>
> Regards,
>
> Jim Langston
>
> Joel Fritz wrote:
>
> > I was taught a very simple rule on when to use a numeric--"Will it be used
> > in computations; does it represent a quantity; or does it show order?  If
> > yes to any of the above, use a number, otherwise use a character variable."
> > I think we could debate the order criterion at length, although numbers are
> > pretty darned easy to increment.
> >
> > I've seen ZIP codes stored as numeric because "It takes up less space," or
> > "It's easier to format ZIP +4 with edit words."  Same thing with phone
> > numbers.  The real fun is using Query or RPG to join files by ZIP code when
> > you have character in one and numeric in the other.
> >
> > > -----Original Message-----
> > > From: Gary Guthrie [mailto:GaryGuthrie@home.com]
> > > Sent: Thursday, July 27, 2000 9:48 PM
> > > To: RPG400-L@midrange.com
> > > Subject: Re: just curious - Number of Parms
> > >
> > >
> > >>
> > > Limiting the conversation momentarily to the USA, Zip Codes often are
> > > defined as numeric. In fact, in the not so distant past, they were
> > > defined as 5 digits in length. Of course, 9 is a more
> > > appropriate length
> > > now. But, all of a sudden your company decides to do business
> > > outside of
> > > the USA -- hmm, now we need alpha characters, too! And,
> > > there's nothing
> > > that prevents USA standards to change to allow alpha characters.
> > >
> > > This having been said, I submit that it's best to leave numeric
> > > definitions to those entities that indicate quantitative data
> > > and avoid
> > > the type of problems mentioned.
> > >
> > > Thoughts?
> > >
> > > Gary Guthrie
> > > REAL Solutions Technical Support
> > > NEWS/400 Technical Editor
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.