I think a compromise would be to start out with all applications needing a particular key and/or set
of fields to access the same logical.

When you add fields to the physical, you create a new logical and use that instead in any program that
needs the new field.

For a new program, you pick and existing logical or if necessary, create a new logical.

Thus, you get all the benefits of one logical per program with much less work.

Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B


-----Original Message-----
bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Thursday, March 13, 2008 2:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Are we insane? Unique use of native DB2

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.

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.
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page
