Right and how many shops do that. Over the years I have seen the most good
awful messes because nobody wants to recompile the whole system so they
reuse field, create extensions and then extensions for extensions.

It's called Database Independence. The logical view of the data is
different than the physical view which is exactly what a relational
database does.

The weird thing to me is that Dbase did exactly that for years and IBM
couldn't do it. The one issue that I can see is that RPG maintains a single
copy of a variable and moves the database fields from the buffer to single
variable so if you added a new field and you had two tables with the same
name how would RPG know which table changed.

One way to deal with the issue is to externalize the I/O. Put your database
I/O in an external service program
but know days why bother. SQL does everything plus a thousand times more.


On Fri, Apr 25, 2014 at 1:56 PM, John Yeung <gallium.arsenide@xxxxxxxxx>wrote:

On Fri, Apr 25, 2014 at 3:20 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:
If RPG database RLA was more like SQL in that data from a file was
retrieved based on field *name* at run time and not on field *position*
at
compile time.

I totally understand the thinking behind this, and sympathize to an
extent, but it really goes against the design and philosophy of the
compiler.

What do you propose for the case where the file is missing fields that
were present at compile time and used by the program? Or fields that
have changed type or size?

The fact is that if you are truly doing a "benign" file change (for
example, just adding a completely new field), then the "fix" is, in my
opinion, equally benign: Just recompile the program as-is. Don't
complain about thousands of programs that need to be recompiled: You
can write (or buy) a program to find and recompile the affected
programs.

John
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.