|
APRM® Technical Alert |
|---|
| Product: | APRM - V5R1M0 through V5R3M1 | |
| OS Level: | OS/400 - V5R1M0 and later | |
| Date: | November 21st, 2003, Modified April 15, 2005 |
OS/400 (i5/OS) V5R3M0
Collection Services has been modified to be able to smoothly handle
a dynamic change to processing resources; this is no longer
an issue nor a problem.
Before V5R1 of OS/400, the only way the processing configuration could change required an IPL to occur. Either hardware service was required to add new processing capacity, (upgrading the processor, memory or interactive capacity), or, if the system was partitioned, changes to the LPAR configuration that resulted in different processor or memory assignments in a partition required an IPL to become effective.
With V5R1, the processor and/or memory assignment in a partition can change dynamically. When this occurs, Collection Services sees a new system configuration and cycles to start collecting data on the new configuration. Regardless of how the LPAR configuration is changed, whether it is via APRM, System Service Tools, iSeries Navigator or other third party products, the result is that because the processor and memory resources have changed, Collection Services will cycle. Furthermore, when a request to move memory between partitions occurs, the actual movement typically occurs in relatively small blocks until the complete amount of memory requested has been moved. This is because the pages of memory need to be moved through the machine pool of the partition to clear them before they can be removed from the partition. The memory is added to the receiving partition as and when the memory becomes available. As an example, if a single request is made to move 100MB between partitions, the actual move may be performed with five actual moves of 20MB each, over a period of several minutes. Because of this, collection services may cycle several times in both the giving and receiving partitions during the course of a single request to change the memory configuration.
APRM is constantly looking at the performance of the various partitions within the iSeries system as a whole and adjusting processor, interactive and memory resources to where they are needed. As a result, whenever APRM adjusts the LPAR configuration of the system, collection services cycles in the partitions affected. This typically results in numerous cycles of collection services, (maybe several hundred on a particularly dynamic system), and the resulting generation of management collection objects.
If Collection Services were defined to generate database files from the management collection objects, an additional job would be submitted to perform this task for each management collection object created.
Steps can be taken to stop Collection Services from running thus preventing the generation of management collection objects. Steps also may need to be taken to prevent other jobs and tasks from restarting Collection Services. For example, PM400 has a job that will verify that Collection Services is running and start it if it finds that it is not. PM400 is a component of OS400 that takes the data from the database files generated from management collection objects, summarizes it and then transmits the information to IBM for producing performance reports. The customer can then view these reports over the web. There may be other jobs from third-party vendors that will also verify and/or start Collection Services.
There is also an issue of Collection Services cycling unexpectedly when no configuration change has occurred. PTF's have been issued to correct this particular problem, as follows:
| V5R1 | SI08234, MF31476 | |
| V5R2 | SI08927, MF31447 |
Note: APRM does not use Collection Services, management collection objects or database files generated from these objects. APRM determines the workload on individual partitions using IBM supported MI instructions and analyzes the information using a patent-pending algorithm. This is because APRM needs to react to the workloads occurring on the system at the current moment in time, rather than the workload that was occurring on the system when collection services recorded the information. Stopping collection services will not affect the execution or functionality of APRM.
Green Screen:
Enter GO PERFORM, followed by Option 2 - Collect Performance Data, followed by Option 2 - Stop collection.
ISeries Navigator:
Within iSeries Navigator, navigate to Collection Services under Configuration and Services. Right click on Collection Services and select Stop Collecting.
API:
CALL QYPSENDC PARM( '*PFR ' ' ' )Note: Each parameter is 10 characters long.
Enter WRKACTJOB and page down to find the QYPSPFRCOL job in the QSYSWRK subsystem. Enter a 5 to work with the job and then option 2 from the WRKJOB menu.
On the display job details screen, page down one screen. The name of the job that submitted the Collection Services will be displayed.
Enter GO PM400
Take option 2 - Work with automatically scheduled jobs.
Put option 2 = Change next to BOTH the Q1PPMSUB and Q1PPMCHK entries.
Change the status to I for Inactive for both of these jobs.
Enter GO PERFORM, then option 2 - Collect Performance data. If Collection Services is active, the current details of the collection will be shown at the top of the screen, including whether database files are to be generated. If Generate database files is *YES, then stop Collection Services and start it again specifying *NO for generate database files. The database files can always be generated at a later time for a particular management collection object if required.
© Copyright 2003-2005 Barsa Consulting Group, LLC. All rights reserved.