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 email@example.com.
Le 11/04/2022 à 18:38, Rob Berendt a écrit :
What are the recommended values on CFGPFRCOL?
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
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 mailing list archive is Copyright 1997-2023 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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.