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



Le 11/04/2022 à 18:38, Rob Berendt a écrit :
What are the recommended values on CFGPFRCOL?
I have:
Default interval . . . . . . . . INTERVAL 05.00
Collection library . . . . . . . LIB QPFRDATA
Default collection profile . . . DFTCOLPRF *STANDARDP
Cycle time . . . . . . . . . . . CYCTIME 000000
Cycle interval . . . . . . . . . CYCITV 24
*MGTCOL retention period: RETPERIOD
Number of units . . . . . . . 00120
Unit of time . . . . . . . . . *HOURS
Enable system monitoring . . . . ENBSYSMON *NO
Create historical data . . . . . CRTPFRHST *YES
Create standard database files CRTDBF *YES
Create standard summary data . . CRTPFRSUM *NONE
Historical data interval . . . . HSTITV 60.00
Historical summary retention . . HSTSUMRET 0000000012
Create historical detail data . CRTHSTDTL *YES
Historical detail retention . . HSTDTLRET 0000000007
Historical detail data filter . HSTFILTER 0000000020
Standard data retention (days) STDDTARET 0000000010
System monitor data retention . SYSMONRET 0000000002

I like to keep more than one month of performance data. In case of performance issue, it is often helpful to compare the system's behavior the day you have an issue and the same business days the previous weeks and the previous month.

I also like to reduce the impact on the system when analyzing performance data. So, it is better to avoid the need to create the performance data from the performance collections, at the time you want to use them. Therefore, I like to set 40 days for standard data retention STDDTARET.

Regarding collection retention, it depends on the backup strategy. The goal is to make sure to have all collections on a tape so that you can restore them and recreate the performance data in case of need. But there is an issue here, because the active *MGTCOL object is locked in a way it cannot be saved. So, on most of our systems, and because we have a monthly backup in restricted state, we moved QPFRDATA library backup to the BRMS control group where there is a *SAVSYS, and have excluded it from *ALLUSR BRMS item. If you cannot run a SAVSYS as often, you can set a specific control group for QPFRDATA but with the fact that it will always fail due to active *MGTCOL locked object.

Of course, if the system is short with disk space, retention could be lowered and QPFRDATA backup strategy amended accordingly.


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.