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



If the system sees an index being built, and sees an access path that it can use, it will use it, regardless of restore vs. create. (A restore is really a create anyway when you think about it) Then again, with the more modern SQL engine if this is the case, is the index really needed? That requires a bit of detective work, and most likely not. That rule is different for the V4 days vs. the V7R3+ days too.

Remember a logical file is a hybrid object; an index and view put together. That complicates things a bit, since selection is now built in but in the end from the perspective we are taking there’s not that much difference. The computer scientist that deals with data bases, may not have quite such a simplistic view of it, but for what we need, it works.

Jim Oberholtzer
Agile Technology Architects



On Apr 1, 2023, at 9:05 AM, Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Jim,

Am 01.04.2023 um 15:25 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:

An index uses an access path built by the system to actually get to the data.

Build an index with keys A B C. It will create an access path for that index.

Now build an index with keys B C

Since the system already has an access path for B C (it will ignore the A in this case) the system will build the index but share the access path already built earlier.

Thanks for this very comprehensive explanation!

When you restore a library the system will do its best to share access paths and build them widest to narrowest attempting to reuse as much as possible. You will see messages in the job log about sharing access paths on restoring the tables/indexes.

I wonder if this is — according to you — happening only on restore and not when creating yet another index.

As to your question about saving access paths, you are correct, 90+% of the time we save access paths during a save now. Back in time when backups took longer and we did not have save while active we traded backup time (not saving access paths) for the unlikely event of recovery (not really so unlikely in the S/38 days with the disk units of the time) where it would take potentially very significant time to rebuild access paths on restore. It was a calculated risk that paid off more that it cost, usually

Understood. Thanks again!

Behind the scenes, when restoring a save with access paths, the system seems to merge those to a "wider" when restoring additional LFs, yes? Thus I'm wondering even more if the system doesn't do this when also creating additional LFs.

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.


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.