Workflow templates list

This topic describes the workflow templates shipped with the product.

Product-provided workflow templates list

Getting Started workflow templates	Description	Cost¹	SLA²	Tune³
Getting Started - IMS Subsystem Overview	Analyzes subsystem performance statistics for the most active IMS subsystems		X	X
Getting Started - MQ Subsystem Overview	Detects anomalies in MIPs consumed for the most active MQ subsystems.	X	X
Getting Started - CICS Region Statistics	Analyzes CICS region performance metrics emphasizing the Quasi-Reentrant (QR) TCB		X	X
Getting Started - WebSphere Applications	Detects anomalies in transaction rates for the most active WebSphere applications		X	X
Getting Started - Db2 Transaction Applications	Detects anomalies in transaction rates for the most active Db2 applications		X	X
Getting Started - CICS Transactional Applications	Detects anomalies in transaction rates and response time for the most active CICS applications and regions It also evaluates response time components.		X	X
Getting Started - MSU by WLM Importance	Detects anomalies in MSU consumption by each WLM Goal Importance level for the two most active Sysplexes	X	X	X
Getting Started - Coupling Facility Performance	Detects anomalies in CF KPIs, such as CPU utilization, free storage, and path contention		X	X
Getting Started - XCF Performance	Detects anomalies in XCF KPIs for the most active z/OS image, such as total traffic, path contention, and buffer allocation issues		X	X
Getting Started - Enterprise Overview	Detects anomalies in CPC GCP, LPAR GCP & zIIP, and UoWQ	X	X	X
Getting Started - Application SLA impact	Detects anomalies in application CPU (Total/Avg) and volume, which can drive increased response time and SLA issues	X	X	X
Getting Started - DASD Space Usage	Detects anomalies in storage group free space in GB and %	X
Getting Started - CPU Consumers	Detects CPU consumption anomalies at LPAR level and in their service/report class, suites, and applications	X	X
Getting Started - Subsystems Address Spaces MSU Consumption	Detects anomalies in MSU consumed by a subsystem (Db2, CICS, IMS, MQ, or USS)	X
Getting Started - Coupling Facility Overhead	Detects anomalies in Coupling facility, including the impact on GCP Spin loop, and Usage by type (lock, cache, and list)	X	X	X
Advanced workflow templates	Description	Cost¹	SLA²	Tune³
MQ Message Manager Statistics	Analyzes MQ Message Manager statistics for the most active MQ subsystems.			X
CPU Capacity Planning	Detects anomalies in top MSU consumers by service/report class, applications, subsystems	X
CPC Hardware Performance using SMF 113-1	Detects anomalies in CPC hardware performance KPIs—RNI, CPI, and different levels of cache performance	X	X	X
CPC Efficiency using SMF 113-1	Detects anomalies in LPAR GCP CPU usage, and usage > entitlement. Any over-entitlement is an SLA and efficiency risk.	X	X	X
Coupling Facility Overhead	Detects anomalies in the Coupling facility, impact on GCP Spin loop, and Usage by type (lock, cache, list) Provides a deep dive into contribution, volume, and response by CF structure.	X	X	X
Subsystem Overview	Detects anomalies in MIPS consumed by a subsystem (Db2, CICS, IMS, MQ, WAS)	X	X
IO Subsystem Performance	Detects anomalies in Channel Path Utilization and Storage Pool Response time		X	X
Large Db2 Application Review	Detects anomalies in Db2 Resource consumption (CPU, I/O, and Get pages), volume and response	X	X
Online Application MSUs	Detects anomalies in MSU consumed by a subsystem (Db2, CICS<)	X	X
Subsystems MIPS	Detects anomalies in MIPS consumed by a subsystem (Db2, CICS, IMS, MQ, or USS)	X
WLM Over and Under Achieve	Detects anomalies in service class CPU (Usage/Delays) and WLM goal achievement		X	X
zIIP Overflow	Detects anomalies in zIIP Usage, overflow, and usage > entitlement Any over entitlement is an SLA and efficiency risk.	X	X	X
Disk Space by Storage Group and Controller	Detects anomalies in DASD space utilization aggregated by Storage Controller or Storage group.			X
Db2 Subsystem Overview	Detect Top five Db2 Subsystems by different metrics (CPU, I/O, and Memory Pages).	X		X

Cost: The anomaly might impact SWLC.
SLA: The anomaly might impact response or elapsed time and cause Service Level Agreement (SLA) violation.
Tune information: An anomaly or new overhead issue that you can tune to help lower the cost or SLAs.

Use case example: Getting Started - Application SLA Impact workflow template

The primary purpose of this workflow is to detect anomalies in the highest MSU-consuming applications and monitor their sources to prevent service level agreement (SLA) or software cost impact. It monitors the deviation in total MSU, CPU, transactions, volume, or response time in the top ten applications. However, you can clone the workflow and modify it to use it for other purposes.

Customizing Application SLA Impact workflow template

Before customizing the Getting started - Application SLA Impact workflow template, refer to the following points:

For critical applications: It is possible that your revenue producing transactions might not be the highest volume or the top ten MSU consuming applications. They are typically the highest response, but you cannot detect them by using this workflow. For that, we recommend that you create your personal workflow using this template and then add application name filters to each view in the workflow to override the default of top 10 CPU consuming applications.

For production and test: We recommend that you monitor the test environment as this is often the best place to detect bad changes. For more accurate results, you should create separate workflows from the template for production and test for the following causes:
- Top <N> MSU Applications might be different
- Reduced number of objects for alert window
- Severity of alert in a dashboard
  - Test can be stopped and easily backed out
  - Production action is required before the SLA or MLC impact

Fewer Objects: If you include all the applications on all the LPARs for anomaly detection, you might get lot of deviations in an alert window.
To avoid this, you should:
- Filter LPARs to production or test in a workflow
- Either increase the number of events to be triggered or shrink the alert window size
- Reduce the number of objects in a view

Views in Application SLA Impact workflow template

The following table describes the purpose of report views in this product-provided template:

View	Description
Top N MSU Application	To detect deviations in applications for Total Application Software MSU of top ten MSU consumers Analyzes online applications to determine if the increase in later views of the source is due to increased volume, CPU usage, or transactions. Analyzes Batch or TSO applications (which is rare) when the user includes UIE SUITES built from SMF 30s into an application definition. In this case, you need to diagnose the increase in UIE SUITES, which are not evaluated in this workflow. This view includes all the application types, whereas, the other views exclude Batch and TSO applications.
Application Volume	To detect deviations in the volume of the top MSU-consuming online applications Analyzes increase in applications volume because application volume increases are often the root cause of the total application CPU increase. Any increase in CPU per transaction causes longer response time. When analyzing the report, you can consider the following points: Increased volume: Could it be due to a sales promotion? Could it be due to distributed application modernization? Could it be a Denial-of-Service attack? Stable volume: If the total CPU or CPU per transaction has increased, then probably there is an application change that is less efficient. Lower volume: There could be a delay or limitation in the application request. For example, a distributed web requestor. An increase in the CPU per transaction or response time can also cause lower volume.
Application CPU per tran	To detect deviations in the CPU per transaction for the top MSU-consuming online applications Analyzes increase in the application CPU per transaction because it may increase the total application CPU. However, if the volume is constrained by associated increase in response or capacity restrictions then it may not increase the total application CPU. When analyzing the report, you can consider the following points: Increased volume: It is possible that the volume is causing resource contention and leading to increase in cycles per instruction of the application. You can see the Volume view for potential sources of volume increases. Stable volume: If the total CPU or CPU per transaction has increased then probably there is an application change that is less efficient. Lower volume: This could be due to an application change that was less efficient. The higher CPU per transaction increases the response time or residency time and often impact the ability to process high volumes of transactions.
OLTP Response	To detect deviations in the response time of the top MSU-consuming online applications Analyzes the increase in response time. This might be because of one of the following reasons: CPU per transaction has increased because most applications are CPU bound and there might be many I/O avoidance techniques in play in the modern applications. Volume has increased and is creating resource bottlenecks. If the increase is due to increased revenue generating transactions and cannot be reduced or removed, investigate the application bottlenecks. You can investigate the bottlenecks with service classes, application UoW tables, or application statistics record tables.