RE: Model 270 At V5R2 Is Dead Toad Slow Running JDE One World.......

["Mike Shaw" <mhshaw@xxxxxxxxxxxxxxxx>]

Vern,

The files are *MAX1TB in the JDE library.  Thanks.

Mike Shaw

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Saturday, April 12, 2003 11:56 AM
To: Midrange Systems Technical Discussion
Subject: RE: Model 270 At V5R2 Is Dead Toad Slow Running JDE One
World.......

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


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