× 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: File field names
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 26 Oct 2000 09:11:05 -0700
  • Organization: Pacer International

In our system, which is a S/36 legacy system, every field in a file starts
with the same 2 initial characters.  CMFile fields all start with CM, EqpMst
fields all start with EQ, etc...

This was the way it was in the S/36 program, so was extended to the DDS for
the then flat files.  This is something I had done in one of my own systems
in another language (dBase & Clipper) to distinguish fields.

I had gotten into trouble in dBase from naming my fields the same name, which
I had thought would be a good thing.  Fields such as TaxPct, which was not a
normalized field because of tax rate changes, were the same in all files.  Then
one day there was a very strange bug in my program and I traced it down that 
I was doing something like InvAmt = TaxPct * Total.  Tracking further I found
that it was using the wrong TaxPct value, that it should of been using it from
the Invoice Header, but instead it was pulling it from the Customer Header
(default tax rate) and they were different for some reason.

I then started doing something like InvAmt = InvHead->TaxPct * Total and found
I was missing it in a lot of places and it made my code very unreadable.
Then I went through every single one of my files and every single program
and put in 3 characters in front of each field, IH_TAXPCT for invoice header,
CS_TAXPCT for Customer, etc..  Then I didn't have any more problems.  This is,
I think, the best way to go, as it prevents accidental misuses of variables.

Yes, you can use Prefix in your files, until the one time you only have one file
in your program so don't need it.  Then later someone goes back and needs to add
another file (user wants us to validate tax rate now so we chain to tax file) 
and
they don't realize, or remember, or think about using the prefix, since the 
other
file doesn't have it, now suddenly we are back using the wrong field.

Even worst, I think they might be both the same field.  If we have the same 
field
name in 2 different files of the same type wouldn't RPG just store them in the 
same
memory location?  Ouch.

Regards,

Jim Langston

Just my $0.04 worth (inflation and all)



rob@dekko.com wrote:
> 
> That's your problem, right there.  You're adding a prefix when you code a
> PF.  For example, if you called the item number ITEMNUM in both ITEMMAST
> and ORDDET then a simple query against the file QSYS/QADBIFLD would show
> you everywhere the field is used.  If you want to use the two files in the
> same program then you simply do a PREFIX on the F spec in RPGIV.  There are
> commercial canned software applications out there which do this.  They
> actually work and make sense.  People can adapt.
> 
> Adopting this technique makes referencing obsolete.  Except maybe in screen
> or printer files.
> 
> Rob Berendt
+---
| 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 ...

Replies:

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.