RE: Are we insane? Unique use of native DB2

<snip>
Alan, doesn't a logical file do exactly this? It gives the application a
layer to go through that masks it from the underlying database. It
sounds more like you would like to see the RPG compiler handle this
rather than keep another object around that does it (the LF). While I do
think that would make reading the source easier and you could see
exactly what data was being accesses and how without opening another
source file it does go against the concept of reuse of objects that IBM
had designed into this system. We chose to not use the reusability of
LFs but may other people did. The same argument could be made for
external screen and printer specs. At some times it would be much nicer
to have all that visible in the RPG code but would make for one giant
source object and prevents reuse.
</snip>

Yes, the logical does exactly that but, like I said, creating all the
logicals is a lot of work.

My own opinion is this is how all applications should be designed but
getting others to do it really hard.

If you need 10 tables in your program, you ended up creating 10 logicals
for the program and that takes some time.

You could create a program that allows you to pick one or more physical
files, select a key to join if multiples and then select an index and
then select the fields and it would generate the logicals for you.

What I wanted to do was to take this concept to the next level.
Externalize the I/O into a service program like Dave(?) Morris did and
have the application generate a data structure, a long name and a table
or user space to hold the format along with the logical view.

You compile the program using the data structure and issue an open to
the long name. The service program looks up the format and maps between
the logical and the data structure automatically.

You get all the advantages of field select logicals (performance) with
externalizing the I/O.

But like I said, SQL does all of this plus a ton more so no sure why I
would need to do this anymore.