I am no so concerned about the performance hit as I am wasting the disk
space to collect data after 18:00.  The system we are using this on is
development system and the only thing running after 18:00 is a backup job.
I guess I am just spoiled by the STRPFRMON launching from the job scheduler.
It was so effortless once it was set up and working!  And all the data was
in one place when done!  :-)  The other thing that bugs me is why the went
to the trouble in setting up a parameter to specify how long it runs, when
it in fact has no bearing.......

I did in fact tell it to create the database files.  The only advantage I
see so far is that even though the description of the member says In Use,
you can actually display the data and look at it.  STRPFRMON locked the
member and did not release it until the monitor ended.

I am trying to stay away from PM/400 but will consider its use if it behaves
more to the STRPFRMON standard we have grown accustomed to over the years.
We are a very small shop and I do not have the luxury of folks sitting
around monitoring systems all day and night.  I just need to collect data to
present some very simple monthly reports and capacity planning.  So far on
V5R1 it looks like we lost that capability/consistency just so a very simple
task can run from Windoze.

Thanks for your quick response!


Mike Shaw
----- Original Message -----
From: "Alexei Pytel" <>
To: <>
Sent: Wednesday, January 30, 2002 8:50 AM
Subject: Re: Performance Data Collection Via Management Central on V5R1

> Collection Services collector was designed to run forever.
> You are not supposed to configure it to run for so many hours and then
> down. You configure it to cycle every so many hours - which means closing
> current *MGTCOL object and creating a new one. If you chose "Create
> database files during collection" it will submit a background job
> (CRTPFRDTA), which will create performance database members.
> Collector takes care of old *MGTCOL objects (you can confgire expiration
> time and they will be purged when expired).
> It will not cleanup performance database members automatically. PM/400
> do it for you if you choose to use it.
> Suggested use (I think it is a default when shipped) is to run collector
> round o'clock with 15 min interval, cycle at midnight and do not create
> database files automatically.
> Do not be afraid that it will be a performance hog - collector overhead in
> default configuration is fraction of a single percent even on very large
> and heavily loaded systems.
> If you think you've had a performance problems, you can always create
> database members for analysis (using CRTPFRDTA command) for a time you are
> interested in. Provided, of course, you have reasonable expiration
> and *MGTCOL is still there.
> Another suggested use is to configure PM/400. It will take care of
> everything - collector, database files and will give you some reports in
> addition.
>     Alexei Pytel

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by 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.