× 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 KLISTs in RPG IV?)
  • From: Carol Bastien <cabastien@xxxxxxxx>
  • Date: Tue, 15 Jun 1999 20:19:20 -0700
  • Organization: @Home Network

Joep - I shudder at the thought of internally defined fields.  I can't even
begin to list all the functionality you lose by doing that.  Don't you use Query
or SQL?  It must be just awful for you to look at the data when you are trying
to test your programs. Are you aware that a prefix can be added to all the
fields in a file with just one file specification keyword?   If you used a file
ID standard then you wouldn't need to rename the fields anyway . . . and source
listings with a X-Ref do show all fields used in a program and how they are
used.

Joep Beckeringh wrote:

> >Why do define all your files internally?
>
> Because:
>
> a) We like to see in our sources what fields are used in the program;
>
> b) We don't like to get all the fields when often we only need a few;
>
> c) We hate to have level checks when fields are added to a file.
>
> 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.
>
> 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).
>
> 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          *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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-Ups:
Replies:

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.