× 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: Why define files internally (was: What bugs you about KL
  • From: "Joep Beckeringh" <joepb@xxxxxx>
  • Date: Fri, 18 Jun 1999 23:35:47 +0200

Scott,

The advantages of external definitions you name, are mainly advantages 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, we use
our own dictionary tool, that generates copy members with RPG-specifications
and will adapt IO-specs in RPG programs when needed.

>1) You can use tools like ODBC, SQL, etc.


We do.

>2) You don't have to search through every single program to find
>      out what data is in what position of a file.


We don't

>3) Once you become familiar with the fields in a file, you'll
>      recognize them in every program, because the name is
>      always the same.


Yes.

>4) Our company uses a 2-character prefix on each field, and that
>      prefix is unique to each file.   This means that anywhere
>      I see a field in any program, I instantly know what file
>      its from, and what field it is.


Hm.  So if you have a link between, say customer file (or should I say
'table'?) and order file on customer number you have to use different names
for customer number?  In RPG III that doesn't leave much room for meaningful
field names.

>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:-)

>6) You can use field references to force different things like
>      product codes, customer numbers, etc, to always be consistent
>      in size and type.


In general we use the same field definition in different files, so they are
conistent anyway.

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

>8) You don't have to worry about some goofy programmer who specifies
>      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.


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


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.