"My irritation with IBM was always that they didn't do this for us. Every
other system out there provides database independence. Why couldn't the
AS/400? Why couldn't I just specify a field list in the program or
create a format object and have it bring in only data I need?"
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.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Thursday, March 13, 2008 12:54 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Are we insane? Unique use of native DB2
<snip>
We started with DB2 back in 1979 when the System/38 was first released
and from just about the very beginning we have been using DB2/400 in
what I think is a very unique way. At least I have never heard of anyone
else who is doing this. Since there has been a lot of discussion on this
list about DB2 and SQL vs. native recently I thought I would share what
we do with the native database access methods.
We assign a unique logical file to each and every application that we
write. To say this another way, every F Spec in every RPG program has a
file that is only used in that one RPG application. When we create that
LF it only includes the fields from the physical file(s) (some are joins
but not many) that the RPG application needs and specifies each field
as either input or both as the application needs it. It also includes
any select/omit criteria to keep the application from reading data it
does not need to deal with. We use to explicitly share an access path
until DB2/400 was able to do that automatically. Now we just specify the
key needed for the application. What this does for us is that we can
add a field to a physical file in production and not need to re-compile
any programs. After the new field is there we change the logical files
used by the application(s) that need the new field and compile the LFs
and RPGs that need changed. If the project allows it we can even
implement each application change as it is tested and not need to wait
for a mass implementation.
<snip>
Database independence. What a concept!
Started using what I called Field Select Logicals probably going back
that far. Built some applications that way. Problem always was the
amount of work it took to make it work.
It made it so easy to do maintenance and provided big increases in
performance for input processing.
Figured out a way to build automatic tools to handle it all but by that
point I was beginning to use SQL and SQL does everything without having
to create all the logicals.
My irritation with IBM was always that they didn't do this for us. Every
other system out there provides database independence. Why couldn't the
AS/400? Why couldn't I just specify a field list in the program or
create a format object and have it bring in only data I need?
Oh, well. I guess the solution to that is SQL.
--
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.
midrange.com
