× 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[2]: just curious - Number of Parms(numeric zip codes and
  • From: Jodi_Walker@xxxxxxxxxxxxxxxxxxx (Jodi Walker)
  • Date: Fri, 28 Jul 2000 12:29:05 -0700

     I think we all were taught a similar rule and would have to agree that 
     it makes perfect sense.  Unfortunately, as a programmer, I am at the 
     mercy of the ERP package selected by the business users.  If the ERP 
     has customer NUMBERS and document NUMBERS, I am stuck with them.  Any 
     new development that I do that interacts with the ERP 
     files/servers/etc. gets to perpetuate the problem.
     
     My last shop, at one point, has two different packages, one for order 
     entry and one for manufacturing.  We had interface programs coming out 
     of our ears to get these two packages to try to work together because 
     one package used the 'numeric rule' and the other did not.  
     
     The OE software on AS400 number 1 kept a customer id in a 7 alphanum 
     field.  The MFG software installed on AS400 number 2, had a customer 
     number defined as 8 numeric.  Eventually, we exceeded the available 
     numbers on the OE side.  So, of course, we implemented a character 
     conversion for rollover. The interface responsible for transmitting 
     the orders from OE to MFG had to convert, for example, customer id 
     A123456 to 10123456 before sending it to the MFG box.  
     
     So, do I agree with the rule?  Heck yeah.  I follow it whenever 
     possible on new development that can act independent of the existing 
     ERP.  What are my chances of convincing the business to scrap a 
     multi-million dollar package installation because of its poor design?  
     Pretty slim - on a good day.  I've got a better shot at winning the 
     lottery - twice in the same month.
     
     jw


______________________________ Reply Separator _________________________________
Subject: RE: just curious - Number of Parms(numeric zip codes and oth
Author:  Joel Fritz <JFritz@sharperimage.com> at Internet
Date:    07/28/2000 8:57 AM


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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.