|
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 mailing list archive is Copyright 1997-2025 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.