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

oludare <oludare@ix.netcom.com> wrote:
> 1.    Save some DASD space.
> 2.    Efficient. Objects are together (pgm & file).
> 3.    All resources belong to pgm. No external lock, No external
>  shared
> resouces.
> 4.    File easily manipulated during maintenance without compiling
>  gazilion
> other pgms.
> 5.    There's more if you want more. J
>

1) Disk space is cheap, and I don't think the savings amounts to
      much!  After all, having 50 programs with the input specs
      defined will take up extra space in your SOURCE file :)

2) Not sure what you mean by "objects are put together".  You've
      still got a seperate file, in a seperate place on disk...

3) Again, not sure what you mean.  There's still locking in place,
      on a program-described file.   The file itself is still
      a shared resource...

4) Take a look at the LVLCHK(*NO) parameter on the CRTPF/CRTLF
      commands.  Granted there is some risk to using this option,
      but the same risks are ALWAYS taken when using a program
      described file!


Now, lets turn it around and look at the advantages of external
definitions, shall we?

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

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

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.

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.

5) Tools like UPDDTA can edit any external file automatically.
      without having to provide awkward source for a DFU.

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

7) You don't have to waste valuable programming time coding and
      debugging input/output specs in every program

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

9) Ummm... "theres more if you want more"




> michael.franchino@cussys.com wrote:
>
> > What reason would you have for internally defining a file in RPG
>  instead of
> > using the external definition?
> >
> > Michael
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *