|
On Apr 3, 2023, at 6:56 AM, Rob Berendt <robertowenberendt@xxxxxxxxx> wrote:
I remember a restore in the early to mid 90's. It was still rebuilding
access paths a week later. Some files stayed locked.
IBM changed the default on the save commands to save access paths since
then.
On Sat, Apr 1, 2023 at 9:25 AM Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>--
wrote:
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.
Now build another index B D C. Since there is no commonality between the
keys once the index is built it will also create an access path for the
index to use.
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.
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
……
On Sat, Apr 1, 2023 at 5:49 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:system
Hello Jim,
Am 31.03.2023 um 18:04 schrieb Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx>:
Part of the reason that helped, was it by definition rebuilt all theaccess paths in the library (or system). The system is smart enough to
restore access paths such that they will share each other as much as
possible, so it cuts down on the index maintenance as well as saving
space. Access paths were laid down widest to narrowest to allow the
to share them. Smart system.I've
Your comment raises more question than it answers for me. :-)
What is the difference between an access path and an index? As far as
understood, it's the same. Index is often used in an SQL context, whilelist
Access Path is more AS/400'ish.
Restoring access paths is dependent if you have set ACCPTH(*YES) on save.
If you didn't, the system creates them anew after restore. From your
description I assume you're talking about ACCPTH(*YES) on save?
You claim the system behaves differently on index sharing after a restore
vs. at index creation time. May I ask for more details?
:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
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.
--
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
--
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.
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 mailing list archive is Copyright 1997-2025 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.