|
Thanks for the great help. I knew I could count on you guys! ************************************************************************ Eva SooHoo Management Information Systems, Circa Corporation Internet: EvaS@CircaCorp.com Phone 415/822-1600 ext. 208, Fax: 415/822-1700 -----Original Message----- From: Jeff_Klipa/Harvard@harvardind.com [mailto:Jeff_Klipa/Harvard@harvardind.com] Sent: Monday, January 13, 2003 10:52 AM To: CN=GEAC/O=JBA System 21 Users Subject: Re: [SYS21] Access path problems... It might be a good time to figure out what physical file is involved... If possible I would consider seeing if there were any records I could eliminate from the subject file... Run a reorg on that file after to get rid of the deleted records and rebuild the indexes. Depending on what file is involved... If it's a transaction and/or audit file that can be purged on a regular basis I would add that to the houskeeping... As Paul suggests you could increase the ACCPTHSIZ size again but you might want to see if you could decrease the size of the files involved... This will do more improve your system performance, In the long run... Also read the help text behind this keyword in the CHGLF command: Access path size (ACCPTHSIZ) - Help Specifies the maximum size of auxiliary storage that can be occupied by the following kinds of access paths: o The access paths that are associated with a database file that has a keyed sequence access path. o The access paths that are created for referential or unique constraints, and that can be added to this file with the Add Physical File Constraint (ADDPFCST) command. Changing the value for this file causes the access paths that are owned by the file to be rebuilt. Note: This parameter does not apply to access paths that are created for queries that refer to the data in the file. ----- Performance Tip ------------------------------- - - - For optimum performance, consider whether - - there is high contention for keys within - - the access path when selecting the value on - - this parameter: - - - - o When there is little or no contention for keys,- - specifying the *MAX4GB value generally - - provides better performance. - - o When there is high contention for keys, - - specifying the *MAX1TB value generally - - provides better performance. - - - --------------------------------------------------- - The possible values are: *SAME This value does not change. *MAX4GB The access paths associated with this file can occupy a maximum of four gigabytes (4,294,966,272 bytes) of auxiliary storage. This value provides compatibility with releases of the operating system earlier than Version 3 Release 6 Modification 0. *MAX1TB The access paths associated with this file can occupy a maximum of one terabyte (1,099,511,627,776 bytes) of auxiliary storage. Note: This value is not supported on releases of the system earlier than Version 3 Release 6 Modification 0 (V3R6M0). Therefore, if an attempt is made to save a database file that has this attribute, and the save operation specifies a target release earlier than V3R6M0, the save operation might be unsuccessful, or if successful, the access paths are not saved. If the save operation is successful, the saved version of the file is then used to restore the file, and the system rebuilds all of the access paths. Eva SooHoo <EvaS@circacorp.com> on 01/13/2003 12:44:06 PM Please respond to "GEAC/JBA System 21 Users" <jbausers-l@midrange.com> To: JBAUSERS-L@midrange.com cc: (bcc: Jeff Klipa/Harvard) Subject [SYS21] Access path problems... : Checked the archives and found this discussion on Access Paths rebuilding everytime a program option is run. We are having this same problem with Routes/Structures maintenance. Please excuse my ignorance, but what is the remedy if to the situation if the 'ACCPTHSIZ parameter is *MAX4GBand it is full." In other words, how do I fix this problem? Thanks for any help that you can provide. Previous thread: RE: Access Path rebuilding even though *IMMED ? ---------------------------------------------------------------------------- ---- Subject: RE: Access Path rebuilding even though *IMMED ? From: "Heffner, Art" <AHeffne@xxxxxxxxxxxxx> Date: Thu, 1 Mar 2001 09:23:28 -0500 ---------------------------------------------------------------------------- ---- I would bet the rebuild is done because the ACCPTHSIZ parameter is *MAX4GB and it is full. Art Heffner - Production Tool Supply -----Original Message----- From: andy.jeffery [mailto:andy.jeffery@ntlworld.com] Sent: Wednesday, February 28, 2001 7:05 PM To: JBAUSERS-L@midrange.com Subject: Access Path rebuilding even though *IMMED ? Our G/L LF GLBLTRAN keeps attempting to rebuild the access path everytime we use Reversing Journals, just what we needed at Period End. I've checked the LF Definition and it's *IMMED so why is it being rebuilt? The file has not been restored in anyway. Unfortunately the LF has 21 Million Indexes. Any help would be much appreciated! Thanks in advance. Andy +--- | This is the JBA Software Users Mailing List! | To submit a new message send your mail to JBAUSERS-L@midrange.com. | To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. | To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: doug333@aol.com. +--- ************************************************************************ Eva SooHoo Management Information Systems, Circa Corporation Internet: EvaS@CircaCorp.com Phone 415/822-1600 ext. 208, Fax: 415/822-1700
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.
midrange.com
