RE: Are we insane? Unique use of native DB2 -- MIDRANGE-L

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
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
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

<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.
--
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.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.