Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Performance Management Process for ES Environments

IP.com Disclosure Number: IPCOM000125088D
Original Publication Date: 2005-May-18
Included in the Prior Art Database: 2005-May-18
Document File: 3 page(s) / 70K

Publishing Venue



The MVS Performance Management Process provides a repeatable methodology for managing CPU (central processing unit) costs in a complex environment.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Performance Management Process for ES Environments

Disclosed is a process that can drive cost reductions for a consumer and a higher degree of resource utilization for a service delivery center. These reduced costs lead to less infrastructure demands on the service delivery centers (SDCs) and lower operations costs for the BTE team as the customer.

The performance management process uses a formalized process to identify, at an application level, CPU cost drivers. This process represents a significant improvement in controlling life-cycle operational costs through continuing focus on CPU usage at the application level. The performance management process works effectively in an on-demand environment where system usage forms the basis of cost recovery. The performance management process follows these key steps:

1. Record application CPU usage from existing SMF (system management facility) data to identify high consumption of CPU records identify high consumption of CPU resources.
2. Summarize usage in a "top 25" format to identify the top 25 users for the period (hourly, daily, monthly etc.) being analyzed.
3. Review the usage and assesses key jobs that significantly impact the system using various performance tools (i.e., Performance Reporter and APPTUNE* and Omegamon/RMF).
4. Contact the owners of the activity with a description of the high usage and likely causes.
5. Make performance recommendations associated with SQL design / re-architecture, DB2 object alterations (indexing, buffer pools, object design etc.) and the ability to enhance performance by taking advantage of functions in new releases of DB2.
6. Track improvements to ensure they are implemented. As needed, trade operation costs for application improvements, thus "self-funding" improvements.
7. Monitor improvements and track savings.

The key process step involves identification of the top users. Using the data assembled from SMF, create a report that shows the daily usage. Back this up with periodic reports (monthly is optimal) summarizing the usage. This illustrates sample output from a typical "top 25" report for a DB2 environme...