Re: Why define files internally (was: What bugs you about KLISTs inRPG IV?)

[DAsmussen@xxxxxxx]

ALL RIGHT!

Being a big LVLCHK(*NO) opponent, I cannot let this slide.  No offense, BUT...

In a message dated 6/16/99 12:04:55 AM Eastern Daylight Time, 
cabastien@home.com writes:

> > >Why do define all your files internally?
>  >
>  > Because:
>  >
>  > a) We like to see in our sources what fields are used in the program;

Last time I checked, DSPFFD and compiled listings worked well, without a 
chance of introducing errors into the database.  In case you hadn't noticed, 
database integrity is the _STRONG_ point of the AS/400.

>  > b) We don't like to get all the fields when often we only need a few;

Use the IGNORE keyword.

>  > c) We hate to have level checks when fields are added to a file.

Oh, so sorry you're averse to spending the extra hour or so that it would 
take to ensure that your application actually has some _INTEGRITY_.  
DSPPGMREF, look into it.

>  > Ad a) and b):  We would be much happier if we could specify the fields 
we 
> DO
>  > want (as is possible in the output specifications), instead of kludgily
>  > renaming the fields we DON'T want.

Valid point, but a utility to do this for you should take less than a day to 
write.

>  > Ad c):  We build and maintain a number of software packages and most of 
our
>  > customers have some custom built modifications and extensions.  Often 
these
>  > extensions need added data base fields.  When using externally defined
>  > fields, this would lead to extra logicals, excluding the additions, to
>  > satisfy the standard programs.  (The first new package we built after
>  > migrating from the S/36 to the AS/400 was externally defined first, but
>  > after a few years we decided to revert to internal definitions).

Oooooh, extra logicals!  This might actually cause a performance problem on 
your _SYSTEM 38_.  How do they handle the extra fields _NOW_ if logicals 
aren't used?  Any customer with brains generally creates their own "extension 
files" in a separate library from vendor files (usually at the vendor's 
suggestion) if they need additional fields for a package, with file names 
similar to the vendor's version.

Again no offense, but these arguments are weak at best and ludicrous at 
worst.  Got another set?

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"While an original is hard to find, he's always easy to recognize." -- John 
L. Mason
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *