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



Jerry,
Way I understand this attribute is that it is only applicable in abnormal
situation, i.e. when system failure occurs.  Thus I believe this is not a
likely candidate contributing to post-IPL slowdown you've observed.
If you're encountering the 'abnormal' scenario often, you're better off
devoting your analysis to eliminating the cause rather than the recovery
process.

But let's say you're encountering this, what is the better option?
If the file is truly used by applications and users, then it doesn't matter
what setting is used since keyed access path will be rebuilt with either
setting.
If some of those indexes are not being used (likely case) then I'd say
you're better off with setting it to *NO.

You can see the help for this setting by doing CHGPF and hitting F1 on the
RECOVERY parm.

BTW, my guess is that if these indexes are truly being rebuilt you should
see QDBSRV* jobs being very busy.  Are you?

Elvis

-----Original Message-----
 Subject: Access Path Maint and Access Path Recovery attributes question

I have two object, both are *FILE and attribute of LF.

One is created using DDS to create the LF and one is created in SQL using 
CREATE INDEX.

I found that there is a difference in the attributes of the objects 
depending on what method was used to create the object.

The DDS compiler default sets the Access Path Maintenance to *IMMED and 
Access Path Recovery to *NO.

CREATE INDEX also sets the Access Path Maintenance to *IMMED --- but 
Access Path Recovery to *AFTIPL. 

I found this during a cpyf, where I tried to change the access path maint 
to *DLY (on the index) and found that if access path recovery is *AFTIPL, 
you cannot change access path maint to *DLY.

So I changed *AFTIPL to *NO. Should I expect there be a problem with 
changing *AFTIPL to *NO on the indexes? 

Since they are both *FILE/LF's is there any reason why the default is 
different for this attribute?

And as an aside, we always noticed significant performance degradation 
(user response time complaints) the day after an IPL - and I'm thinking 
this attribute may have been somewhat responsible.

(And the only other difference I can see via DSPFD is that there is no 
file level id with the object created via create index.)

Comments welcome.

Regards, Jerry



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.