Mike, I don't know if this happened from the upgrade to V5R2 - the issue
here presented is from all the way back to V4R1. But it might help to look
at the ACCPTHSIZ attribute of your keyed files. From a Redbook:
====================================================
16.14 Considerations for 1TB Maximum Access Path Size
On V4R1 systems and later, the default value for access path size for the
Create Physical File and Create Logical File commands (CRTPF and CRTLF) is
1 terabyte (TB). On prior systems the default is 4GB. This means that
instead of a three-byte index, a four-byte index is built with the implicit
ability of granularity on the index.
The four-byte index circumvents a lot of seize conflicts. However, this
change may have an impact on the implicit access path sharing for database
files created prior to V4R1.
If you have an existing database with all three-byte indexes and you create
or recreate a file with an index, that index becomes a four-byte index by
default. It does not have the ability to implicitly share an existing
access path of a three-byte index.
From a functional point of view, you cannot see any difference since the
application runs in the same way. However, it can impact overall system
performance when more implicit shares are removed and eventually a large
number of access paths exist for both the three and four-byte versions.
Recommendation
Do not mix three- and four-byte access paths.
There are three approaches to avoid mixing three and four-byte access paths:
1. Leave the Access Path Size parameter (ACCPTHSIZ) default to *MAX1TB and
recreate the database so all access paths are in four-byte mode. The
downfall of this approach is that recreating the database can be time
consuming.
2. Change the ACCPTHSIZ default back to *MAX4GB. This does not avoid
potential seize conflicts, however.
3. Use DSPFD and DSPDBR commands for the critical files (those with large
access paths and/or heavily used) to keep the files in synch with access
paths. Migrate to four-byte indexes in a phased manner.
Use the CHGPF command to change the access path size of a physical file and
the CHGLF command to change the access path size of a logical file
====================================================
The locking is reduce because, as I understand it, locking is more granular
in the 4-byte version - fewer contiguous records are tied up.
Fixing shared access paths can be done by saving the physical and all
dependent logicals with a single save command, including access paths, then
restoring them with a single restore command. If the system will determine
that an access path can be shared, then it will create a new shared path,
instead of restoring the multiple access paths that were saved.
HTH
Vern
At 10:22 AM 4/12/2003 -0700, you wrote:
Mark,
I did that when I went to V5R1 over all the JDE libraries. As I recall,
it was just a V5R1 thing coming over from V4R5. I am going to do some
more poking around and see what I can come up with here.
I have a full system backup scheduled to run at 01:00 AM tomorrow
morning along with an IPL. If it is still DEAD TOAD slow, I will in
fact run object conversion over the libs.
Thanks!
Mike Shaw
As an Amazon Associate we earn from qualifying purchases.
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.