RE: Why define files internally (was: What bugs you about KLISTsi n RPG IV?) -- RPG400-L

For Reason 4 below as explained by Buck, I would like to have my PFs externally
defined.
This way it's easy to maintain  and keep integrity and all those database
stuffs.

Thanks,
Rajeev.





Buck Calabro <mcalabro@commsoft.net> on 06/17/99 11:54:53 AM

Please respond to RPG400-L@midrange.com












Subject:  RE: Why define files internally (was: What bugs you about KLISTsi n
      RPG  IV?)




     >>What reason would you have for internally defining a file in RPG
instead of
     >>using the external definition?
>
>1.    Save some DASD space.

By increasing the size of every source member in QRPGSRC?  (all the I specs)
This can be avoided by making /COPY members for all the database files, but
then you basically have external file descriptions again...

>2.    Efficient. Objects are together (pgm & file).

I almost agree with this, but modern applications rarely consist of a single
RPG program and a single database file.  What about the CL program
(overrides) and the menu system (library list) and security and upstream and
downstream database files?  There are many elements to consider when
programming, and very few of them are visible within the source code of any
one RPG program.

>3.    All resources belong to pgm. No external lock, No external shared
resouces.

When the RPG program runs, it will lock a program described file exactly the
same way as an externally described one.

>4.    File easily manipulated during maintenance without compiling gazilion
other pgms.

This is true as long as you are willing to ignore the problems of having
mis-matched I specs with the database files.  If you change a field like ZIP
CODE from 5 digits to 5 characters and don't change all the gazillion
programs that refer to 125 1290ZIP, they will all break.  They will do so in
secret, by producing incorrect output with no error messages.  At least the
externally described file will cause a level check and you know something
has fallen over!

>5.    There's more if you want more. :-)

I went through much of this many years ago, when the System/38 came out.  We
questioned the value of converting all our batch programs from program
described to externally described.  The day we had to add a new field to the
customer master file was the day we regretted not switching.  Instead of
visiting the 10 programs we needed to change, adding the new field name and
recompiling, we had to check for duplicate names (there were several
spellings of field names in the hand-coded I specs, external specs are
standard by definition), type in the start/end positions for the I specs and
the end positions for the O specs (double check them!) before we could use
the new field.  For those programs where our new field name was a duplicate,
we couldn't simply copy the lines in, we needed to make changes to the field
names before we could begin the testing.  We always had Hawkeye's Pathfinder
(which was a Godsend!) but even still, making a simple change was a lot more
work than it needed to be.

Would you use program described WORKSTN specs, too?

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






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