Re: Why define files internally (was: What bugs you about KL

"Joep Beckeringh" <joepb@tip.nl> wrote:
> Scott,
>
> The advantages of external definitions you name, are mainly advantag
>  of
> externally described files.  Like I explained before in another
>  message, we
> DO define our files externally.  It is just that we don't use the
>  compiler
> feature that generates the IO-specs from a *FILE object.  Instead, w
>  use
> our own dictionary tool, that generates copy members with
>  RPG-specifications
> and will adapt IO-specs in RPG programs when needed.
>
[snip]
>
> Hm.  So if you have a link between, say customer file (or should I s
> 'table'?) and order file on customer number you have to use differen
>  names
> for customer number?  In RPG III that doesn't leave much room for
>  meaningful
> field names.
>

Okay, CUCUST & ODCUST
(one is Customer Master, CU, the other is Order Detail, OD.)
I think they're both meaningful.   Particularly so if you're
customer master record isn't loaded to the same number as your
order file is...

Actually, in a way it makes it easier to make meaningful field
names...   When everyone knows what the first two positions
signify, that helps add meaning to the variable name...

For example, the description for your items...    We have a field
thats IMDESC.   IM being the unique prefix for our item master file.
Just calling it "DESC" would not be very meaningful, since lots of
things have descriptions, but IMDESC tells us immediately what it is,
because all of our programmers know what IM is.
Otherwise we'd have to make it something like "ITMDSC" which I think
is harder to read...

We even use the prefixes "wk" (work), ds (data structure) and
pe (parameter) for our internal, program-defined variables/fields.
Since we found that this method works so well!   Whenever I see a
variable called "WKCUST" I know its a work field, and not part of
a file.  I don't have to search my program to determine where it
came from, or what populates it.. a field called CUSTNO wouldn't
do that for me.

Of course, in RPG IV its even nicer.  I can do things like
wkCustBal or peOrdDate.


> >5) Tools like UPDDTA can edit any external file automatically.
> >      without having to provide awkward source for a DFU.
>
>
> I'm afraid we do that as well (although I prefer using SQL).  UPDDTA
>  is like
> a chainsaw: very powerful, if you know what you're doing:-)

Yes, Joep.  My argument was for external definitions, which you ARE
using, and thats WHY you can do this as well!  As for UPDDTA we use
it as a programmer's tool, and do not allow normal users to have
access to it.

>
> >7) You don't have to waste valuable programming time coding and
> >      debugging input/output specs in every program
>
>
> Like I explained, we don't code the specs; we generate them.

Again, I was arguing the merits of external defintions, in general,
and was not referring to your shop specifically.  Your shop really
DOES use external definitions, you just use them a bit differently
than IBM designed, thats WHY you get most of the benefits of them.

>
> >8) You don't have to worry about some goofy programmer who specifie
> >      the output specs improperly, causing incorrect data to be
> >      written to a file, and go unnoticed...
>
>
> Now that's easy: we don't hire goofy programmers:-)
>
> Joep Beckeringh
> Pantheon Automatisering B.V.
>

I'm sorry, Joep, I wasn't intending to come across as criticizing
you directly.   I find external definitions to be very useful,
and was giving my opinions on them.

It sounds like you've got a whole system in place thats very well
designed, and therefore gives you a lot of benefit.  However, please
bear in mind that for the rest of us, 99% of the benefits you're
describing can be implemented with external definions, if we dont
mind a few 7031's at the bottom of our compile listings...

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *