Re: Implicit Access Path Sharing -- MIDRANGE-L

Mark, all,

Our shop standard is as follows:
1) all PF's are nonkeyed
2) there is one unique LF per PF (i.e. xxxxKEY) that is a shared ODP
3) there is a LF (i.e. xxxxKEYQ) that is not shared ODP but shares path
with xxxxKEY

This is not Synon based but it has some valid reasons, not within this
thread, but we have found that the second logical only points to the
first path data space.  It's size is measured is K bytes.

If the first path (xxxxKEY) is deleted, the second LF (xxxxKEYQ) takes
over ownership of the data space.  Rochester Magic ;)

In checking files sizes, we also found that subsets seem to share data
paths.
We have a transaction file that has a LF by year/month (only) with no
select/omit.  If we create a new LF keyed by year/month (only) with a
particular year/month selection, the build seems to run swift and takes
very little data space.

I believe that this behavior has to do with the systems ability to
report back the number of unique combinations of a particular key field
set.

We program for file xxxxYRMO, but the CL driver does an override to
xxxxYYMM for the year and month requested in case you're curious.

Oh, the question was raised as to why would one create two logicals with
the same key or a second with fewer key fields but the same order and
same select/omit.

Simple.  You want the process the file sequentially by key for update
but don't want to lock every record and lose blocking.  You use one
logical for IP and the second for UF and CHAIN/UPDAT only when
necessary.

Let's say you do a "soft" delete to a record by changing a status to "D"
instead of using the DELET opcode.  This way you can "undelete".  It's
the poor man's COMIT/ROLLBK.  It has a long shelf life. Years even.

So every so often you want to blast through the file and perform a hard
DELET for every "D" status record.  To avoid locking every record in the
file you front end the program with an OPNQRYF and select only those
records with a "D" status.

That's cool, so far.  Now we have to deal with the orphans.

So you grab your RPG cycle template and decide that if the parent unique
logical is IP, and a child logical is IS, you can CHAIN/DELET the
child's shared key logical UF on a NMR indicator and block to the
maximum ability of OS/400 and not run into locked record conflicts.

Did you like how I got that RPG cycle/MR logic into a thread on shared
logicals ? %-p

>From all that has been on this thread, it does appear that there's a
definite advantage to creating logicals in a particular order, the most
keys first, the rest after.  Multiple logicals with the same key are of
little cost, but can come in handy.

HTH,

James W. Kilgore
email@James-W-Kilgore.com



Mark Lazarus wrote:
> 
> 
>  This is in a shop that has a fair amount of Synon generated code.  Synon
> automatically creates two "primary key" logicals, one for retrieval and one
> for update.
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---