UIE workloads, SUITES, and applications versus Performance Predictor workloads
These views are created using different information provided by RMF, SMF, and various transactional subsystem monitors.
- UIE workloads are created primarily by using the information from RMF type 72 records and represent collections of Service Classes.
- UIE SUITES are created primarily by using the information from SMF type 30 and type 42 records and represent collections of jobs and address spaces.
- UIE applications, which represent collections of transactions or jobs, are created primarily from various monitor data:
- For CICS - SMF 110, BMC AMI Ops Monitor for CICS or TMON for CICS records
- For Db2 - SMF 100 and 101 or BMC AMI Ops Monitor for Db2 records
- For IMS - BMC AMI Ops Monitor for IMS Offline records
- For MQ - SMF 115 and 116 records
- For WAS - SMF 120 records
- For Batch - SMF 30 records
These three views of the total activity in the data center are maintained by UIE internally and used to create workloads, SUITES, and applications data, which are written to the Visualizer database and can be viewed in Visualizer graphs. For more information on Visualizer graphs, see the Visualizer documentation.
Performance Predictor workloads, however, represent different objects, that is, Performance Predictor modeling objects. In performance modeling and capacity planning, these objects are commonly referred to as workloads.
UIE can create these modeling objects in the following ways:
From UIE SUITES, which enable you to model a group of jobs or even individual jobs and address spaces. This method is important when you want to model your CICS, IMS, Db2, or MQ transactions, as this is the UIE default. This assignment rule is equivalent to the command:
XMLMODEL TYPE=SUITE
From UIE workloads, containing Services Classes (although some information from other sources is also used). This assignment rule is equivalent to the command:
XMLMODEL TYPE=PGSCL
From Report Classes by using the following command:
XMLMODEL TYPE=REPORT
If you provide additional transactional or jobs data as an input to UIE, UIE can process this data and combine the data into applications. UIE can determine what resources these applications used in the different subsystems that executed in the enterprise environment.
It is important that you understand the difference between applications and modeled workloads.
Workloads consist of actual units of execution in the z/OS environment, such as jobs, started tasks, and subsystem address spaces. The units of execution are managed by the operating system (although sometimes using transaction response time as criteria) and consume resources, such as CPU seconds and I/O operations. As such, you can model these workloads and predict the effects of hardware upgrades or workload moves from one system to another.
Applications consist of transactions, that is, units of work performed by one or several workloads (CICS or IMS regions, Db2 subsystems, and so on). These applications perform internal resource management, sharing, and pooling. Even if it is possible to determine actual resources used by a particular transaction, these measurements can be misleading. For example, a particular transaction can require reading multiple data blocks from DASD, and several subsequent transactions can reuse the data from buffers without performing any I/O operations.
Creating applications in the Performance Predictor model is closely connected with processing of SUITES. The transactional subsystem SUITES automatically created by UIE provides more accurate and homogeneous information. Therefore, for application modeling, you must create Performance Predictor workloads from SUITES. To see your applications in the Performance Predictor model, use the following command:
XMLMODEL TYPE=SUITE
Otherwise, application data is written only to a Visualizer file, but does not appear in the XML model.
Applications are not represented as workloads, but as resource consumption profiles, which exist in parallel with actual workloads. These profiles are applied to the modeling results to calculate application resource consumption and predict the effects of hardware changes and workload or subsystem moves. You can also be use these profiles to predict the effects of application growth. However,you cannot use them to model application moves in real life. Such moves are implemented as the movement of jobs, regions, and subsystems.
When transactional data is provided to UIE as input, UIE creates some applications by default. (For more information, see Default-subsystem-applications for more information.) You can change default rules by using the APPL and APPLGROUPING commands. (For more information, see APPL and APPLGROUPING.) For an example that demonstrates using the APPL command, see Example 6—Using the APPL command to create applications.