Yes, to you question on the key. Back a few years if you had two logical files with the exact same key ( the "K" lines in the DDS for the LF) the system created two access paths and both needed to be maintained. If you didn't want that to happen there was a keyword (I think it was ACCPTH()) that you can tell Logical File A to share the access path in Logical File B and only one access path would be maintained. Now there is not choice, if a new LF is created that has the same key list as an existing access path it will automatically share that access path.
There really is not that much extra overhead. There is the space needed for the extra source for the DDS and the objects but most of the objects are small. If 50 LFs all have the same key list then there is only one access path being maintained. One LF shows as being large but the rest are small. (one real example is 21MB on the LF with the access path but the rest are around 28K)
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Thursday, March 13, 2008 3:43 AM
To: Midrange Systems Technical Discussion
Subject: RE: Are we insane? Unique use of native DB2
I love hearing about the world outside our company, as I have only ever worked here as a developer.
When you say, " Now we just specify the key needed for the application", you mean the key on the LF?
Would this kind of system be possible for us? We have a lot of users with a lot of interactive applications using the same big PFs. Wouldn't that cost a lot in ressources? I mean, each application would be continually updating all the LF dependant on the physical file?
Thanks a lot for this great practical example, even if it's not a solution for us. I hope other members on the list will follow.
-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Mike Cunningham
Envoyé : jeudi 13 mars 2008 03:09
À : 'Midrange Systems Technical Discussion'
Objet : Are we insane? Unique use of native DB2
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.
So, are we insane or was the analyst that worked here back in 1979 a man far ahead of his time (It was not me - I did work here at the time but as a lowly entry level coder who no one listed to)
--
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 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
