× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



At 09:54 28/04/99 -0400, you wrote:
>Pete is correct about the sequencing.  Always build access paths with
>the most key fields first to maximize opportunities to share access
>paths.  One thing that I have not tested (but suspect to be true) is
>library restores.  If the files were saved ACCPTH(*YES) you should get
>back exactly what you saved. However if you use the default
>ACCPTH(*NO) the system will probably build 'em as it restores 'em,
>which will be in alphabetical order I believe, which means that you
>may lose sharing that you had before the save/restore.
>

You will find in the manuals (Data Management guide I think) a section on
Implicit Access Paths which will tell you what will happen when you restore.

As I remember it, the restore will build access paths in such a way that it
will implicitly share access paths *EVEN IF THEY WERE NOT SHARED BEFORE*.
(Damn I wish I could bold that)

For example where an LF is created with KEY A then another LF created with
KEY A,B then my understanding is that the access path wouldn't be shared
(hopefully I have the creation and key thing round the right way). Ignoring
the questions of why you would do this (which usually relate to historical
correction of poor design) when you restore, the path with KEY A,B would be
built first because the the system creates access paths starting at the
"longest" and working "downwards", and then the path with KEY A would
implicitly share the KEY A,B access path, even though it did not prior to
the restore.

The manuals also point out that under certain circumstances, this could
cause application logic to fail or behave differently after a restore where
assumptions about access paths are no longer correct.

Short of copying the entire section of the manual, the logic failure was to
do with key positioning on the KEY A,B logical file using a partial key
(A). Once the access paths are implicitly shared the positioning behaved
somewhat differently. I think if anyone is interested this is definitely a
*must read* rather than me attempting it to explain here, hence my garbled
paraphrasing. Maybe it will worry you enough to check the manual ;)

I have seen at least one post on a news group from someone that got caught
by this.

Hope this adds something to the discussion

Cheers

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.