OMEGAMON II for IMS Bottleneck Analysis Reference Manual...

IBMTivoli®

Version 5.5.0

Bottleneck Analysis Reference Manual

SC32-9359-00

OMEGAMON II for IMS

12

1

2

IBMTivoli®

Version 5.5.0

OMEGAMON II for IMS

Bottleneck Analysis Reference Manual

SC32-9359-00

12

1

Second Edition (December 2005)

This edition applies to version 3, release 1, modification 0 of IBM Tivoli OMEGAMON XE for IMS on z/OS (product number 5698-A39) and to all subsequent releases and modifications until otherwise indicated in new editions.

This edition replaces GC32-9265-00.

© Copyright Sun Microsystems, Inc. 1999

© Copyright International Business Machines Corporation 1996, 2005. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

2

Before using this information and the product it supports, read the information in "Notices" on page 95.

Note

Contents 5

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Documentation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Chapter 1. Bottleneck Analysis Menu Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Accessing the Bottleneck Analysis Menu Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Accessing the Bottleneck Analysis Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Accessing the Factors Affecting Executing Transactions Screen . . . . . . . . . . . . . . . . . . .20

Chapter 2. Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23About the Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Attaching the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Controlling the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Invoking Bottleneck Analysis (IDEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Specifying Collector Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Chapter 3. Bottleneck Analysis Displays (MDEX/PDEX). . . . . . . . . . . . . . . . . . . . . . . . . . . 43Displaying Bottleneck Analysis Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Examples of MDEX and PDEX Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Factors That Influence the Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48Average Transaction Counts Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Chapter 4. Bottleneck Analysis Execution States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51About Execution States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56IMS Scheduling Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Database I/O Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63MVS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64IMS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Output Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80External Subsystem Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Appendix A. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Bottleneck Analysis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Transaction Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86DBCTL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Contents

6 IBM Tivoli OMEGAMON II for IMS Bottleneck Analysis Reference Manual, Version 5.5.0

Appendix B. Support Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Appendix C. Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Figures 7

Figure 1. Bottleneck Analysis Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Figure 2. Executing Transactions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Figure 3. Attaching the Bottleneck Analysis Collector Using IDEG . . . . . . . . . . . . . . . . . . . . . . . .26Figure 4. IDEG and BEGN Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Figure 5. IDEG and END Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Figure 6. DTCH Command Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Figure 7. Using DTCH from the Menu Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Figure 8. BMPXOFF and BMPXON Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Figure 9. Using BMPX from the Menu Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Figure 10. NMSXOFF and NMSXON Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Figure 11. NMSX On and Off Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Figure 12. CLRLnn and CLRL Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Figure 13. CLRSnn and CLRS Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Figure 14. Changing the Database Sampling Option (DBSW) . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Figure 15. DOPT Command Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Figure 16. SUSP Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Figure 17. RESM Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Figure 18. STIM Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Figure 19. MTHR Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Figure 20. MTHR and SCAL Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Figure 21. THRS Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Figure 22. ABCD Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Figure 23. MDEX/PDEX Commands Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Figure 24. MDEX Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Figure 25. PDEX Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

Figures


Preface 9

Preface

This manual contains reference information about the Bottleneck Analysis component of IBM® Tivoli® OMEGAMON II® for IMS.

In this manual you will find information on the following topics:

� how to invoke Bottleneck Analysis through the OMEGAMON II menu interface and command interface.

� how to control the Bottleneck Analysis collector, the component that samples the degradation in your IMS system.

� how to display bottleneck analysis information in the menu and command interfaces.

� an explanation of how Bottleneck Analysis groups transactions that are waiting for processing, and a description of each reason bottleneck analysis displays when a transaction is waiting to be processed.

This manual does not include information about bottleneck analysis data displayed in the CUA� interface. For information about all the data displayed in the CUA interface, see the IBM Tivoli OMEGAMON II for IMS User�s Guide.

For information about time- and event-driven features (automatic screen facility, timed screen facility, and exception logging facility), see the IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual. For information about bottleneck analysis parameters and startup options, refer to Installing Candle Products on MVS.

P

About This Guide


About This Guide

Who should read this guideThis manual is for users who are familiar with performance monitoring software. It assumes that you are familiar with OMEGAMON II, and know how to use its menu and command interfaces.

The Bottleneck Analysis component of OMEGAMON II makes the diagnostic power of bottleneck analysis available to those responsible for the performance of complex IMS environments. Bottleneck Analysis is a analysis technique that focuses on workloads rather than resources. It breaks the execution time of workloads into its component parts, allowing performance analysts and systems programmers to focus on the areas most significant to IMS system performance.

Document set informationThis section lists publications in the IBM Tivoli OMEGAMON XE for IMS on z/OS library and related documents. It also describes how to access Tivoli publications online and how to order Tivoli publications.

IBM Tivoli OMEGAMON XE for IMS on z/OS library

The following documents are available in the library:

� Getting Started with IBM Tivoli OMEGAMON XE for IMS on z/OS, SC32-9469

Provides planning information for installing IBM Tivoli OMEGAMON XE for IMS on z/OS and information about the OMEGAMON XE zSeries® products.

� Configuring IBM Tivoli OMEGAMON XE for IMS on z/OS, SC32-9354

Explains how to configure and customize IBM Tivoli OMEGAMON XE for IMS on z/OS and its user interfaces and components.

� Using IBM Tivoli OMEGAMON XE for IMS on z/OS, GC32-9351

Describes the basics of using IBM Tivoli OMEGAMON XE for IMS on z/OS to manage real-time IMS environments.

� IBM Tivoli OMEGAMON XE for IMS on z/OS Release Notes, GI11-4037

Contains information about what is new in this release, including new or revised OMEGAMON II® panels. Also contains information about problems discovered late in the testing cycle that are not included in the other publications and work-around procedures for those problems.

IBM Tivoli OMEGAMON II for IMS library

The following documents are available in the library:

� IBM Tivoli OMEGAMON II for IMS User�s Guide, GC32-9355

Describes the basics of using IBM Tivoli OMEGAMON II for IMS to manage realtime IMS environments.

Preface 11

About This Guide

� IBM Tivoli OMEGAMON II for IMS Configuration and Customization Guide, SC32-9356

Explains how to configure and customize OMEGAMON II and its user interfaces and components.

� IBM Tivoli OMEGAMON II for IMS IMS Console Facility, SC32-9357

Provides a comprehensive description of the features of the IMS Console Facility (ICF) component.

� IBM Tivoli OMEGAMON II for IMS Transaction Reporting Facility, SC32-9358

Provides user and reference information about the features of the Transaction Reporting Facility (TRF) component.

� IBM Tivoli OMEGAMON II for IMS Bottleneck Analysis Reference Manual, SC32-9359

Provides reference information and descriptions of the features of the bottleneck analysis component.

� IBM Tivoli OMEGAMON II for IMS Historical Component (EPILOG) Reference Manual, SC32-9360

Provides a comprehensive description of the features of the historical component (EPILOG®).

� IBM Tivoli OMEGAMON II for IMS Historical Component (EPILOG) User�s Guide, GC32-9361

Teaches you, step-by-step, how to operate the historical component (EPILOG) reporter after installation.

� IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual, SC32-9362

Describes in detail all of the features of the OMEGAMON II command interface.

� IBM Tivoli OMEGAMON II for IMS Response Time Analysis (RTA) Reference Manual, SC32-9363

Provides reference information and descriptions of the features of the response time analysis (RTA) component.

� IBM Tivoli OMEGAMON II for IMS Application Trace Facility, SC32-9470

Explains how the Application Trace Facility (ATF) monitors and collects detailed information on IMS and Data base Control (DBCTL) transactions to help you analyze and improve performance.

� IBM Tivoli End-to-End Response Time Feature Reference Manual, SC32-9376

Provides a description of the ETE Response Time feature and explains how to start ETE after installation and customization have been completed. Also includes a description of each ETE command argument and descriptions of the ETE error messages, return codes, and sense codes.

About This Guide


IBM Tivoli OMEGAMON Platform Messages

The following books document the messages issued by the OMEGAMON Platform components and products that run on it.

� IBM Tivoli Candle Products Messages Volume 1 (AOP�ETX), SC32-9416

� IBM Tivoli Candle Products Messages Volume 2 (EU�KLVGM), SC32-9417

� IBM Tivoli Candle Products Messages Volume 3 (KLVHS-KONCT), SC32-9418

� IBM Tivoli Candle Products Messages Volume 4 (KONCV-OC), SC32-9419

� IBM Tivoli Candle Products Messages Volume 5 (ODC�VEB and Appendixes), SC32-9420

Related publications

To use the information in this guide effectively, you must have some prerequisite knowledge, which you can obtain from the following guides:

� Installing and Setting up OMEGAMON Platform and CandleNet Portal on Windows and UNIX, SC32-1768

Provides information on installing and setting up the component products of the OMEGAMON Platform: Candle Management Server®, CandleNet Portal, Candle Management Workstation®, Warehouse Proxy, Alert Adapter for AF/REMOTE®, Alert Adapter for Tivoli Enterprise Console®, and Alert Emitter for Tivoli Enterprise Console on Windows® and UNIX®.

� Administering OMEGAMON Products: CandleNet Portal, GC32-9180

This document describes the support tasks and functions required for the OMEGAMON platform, including CandleNet Portal user administration.

� Using OMEGAMON Products: CandleNet Portal, GC32-9182

This guide describes the features of CandleNet Portal and how best to use them with your OMEGAMON products.

� Historical Data Collection Guide for IBM Tivoli OMEGAMON XE Products, GC32-9429

Describes the process of collecting historical data and either warehousing it or converting it to delimited flat files for reporting purposes. Also describes how to configure historical data collection and warehousing intervals using the CandleNet Portal describes how to maintain the Persistent Data Store used to collect and store historical data on z/OS.

� Configuring IBM Tivoli Candle Management Server on z/OS, GC32-9414

Provides instructions for configuring and customizing the Candle Management Server on z/OS.

The online glossary for the CandleNet Portal includes definitions for many of the technical terms related to OMEGAMON XE software.

Accessing publications online

Preface 13

About This Guide

The documentation CD contains the publications that are in the product library. The format of the publications is PDF. Refer to the readme file on the CD for instructions on how to access the documentation.

IBM posts publications for this and all other Tivoli products, as they become available and whenever they are updated, to the Tivoli software information center Web site. Access the Tivoli software information center by first going to the Tivoli software library at the following Web address:

http://www.ibm.com/software/tivoli/library

Scroll down and click the Product manuals link. In the Tivoli Technical Product Documents Alphabetical Listing window, click the Tivoli OMEGAMON XE for IMS link to access the product library at the Tivoli software information center.

If you print PDF documents on other than letter-sized paper, set the option in the File -> Print window that allows Adobe Reader to print letter-sized pages on your local paper.

Ordering publications

You can order many Tivoli publications online at the following Web site:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

You can also order by telephone by calling one of these numbers:

� In the United States: 800-879-2755

� In Canada: 800-426-4968

In other countries, contact your software account representative to order Tivoli publications.

Tivoli technical trainingFor Tivoli technical training information, refer to the following IBM Tivoli Education Web site:

http://www.ibm.com/software/tivoli/education

Support informationIf you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following ways for you to obtain the support you need:

� Searching knowledge bases: You can search across a large collection of known problems and workarounds, Technotes, and other information.

� Obtaining fixes: You can locate the latest fixes that are already available for your product.

� Contacting IBM Software Support: If you still cannot solve your problem, and you need to work with someone from IBM, you can use a variety of ways to contact IBM Software Support.

For more information about these three ways of resolving problems, see �Support Information� on page 89.

http://publib.boulder.ibm.com/tividd/td/tdprodlist.html

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

http://www.ibm.com/software/tivoli/education

About This Guide


Participating in newsgroupsUser groups provide software professionals with a forum for communicating ideas, technical expertise, and experiences related to the product. They are located on the Internet and are available using standard news reader programs. These groups are primarily intended for user-to-user communication and are not a replacement for formal support.

To access a newsgroup, use the instructions appropriate for your browser.

Preface 15

Documentation Conventions


OverviewThis guide uses several conventions for special terms and actions, and operating system-dependent commands and paths.

Panels and figuresThe panels and figures in this document are representations. Actual product panels may differ.

Required blanksThe slashed-b (!) character in examples represents a required blank. The following example illustrates the location of two required blanks.

!!!!eBA*ServiceMonitor!!!!0990221161551000

Revision barsRevision bars (|) may appear in the left margin to identify new or updated material.

Variables and literalsIn examples of z/OS® command syntax, uppercase letters are actual values (literals) that the user should type; lowercase letters are used for variables that represent data supplied by the user. Default values are underscored.

LOGON APPLID (cccccccc)

In the above example, you type LOGON APPLID followed by an application identifier (represented by cccccccc) within parentheses.

SymbolsThe following symbols may appear in command syntax:

Table 1. Symbols in Command Syntax

Symbol Usage

| The �or� symbol is used to denote a choice. Either the argument on the left or the argument on the right may be used. Example:

YES | NOIn this example, YES or NO may be specified.

[ ] Denotes optional arguments. Those arguments not enclosed in square brackets are required. Example:

APPLDEST DEST [ALTDEST]In this example, DEST is a required argument and ALTDEST is optional.



{ } Some documents use braces to denote required arguments, or to group arguments for clarity. Example:

COMPARE {workload} -REPORT={SUMMARY | HISTOGRAM}

The workload variable is required. The REPORT keyword must be specified with a value of SUMMARY or HISTOGRAM.

_ Default values are underscored. Example:

COPY infile outfile - [COMPRESS={YES | NO}]In this example, the COMPRESS keyword is optional. If specified, the only valid values are YES or NO. If omitted, the default is YES.

Table 1. Symbols in Command Syntax

Symbol Usage

Bottleneck Analysis Menu Screens 17

Bottleneck Analysis Menu Screens

Chapter overviewThis chapter describes the Bottleneck Analysis menu screens.

Chapter contentsAccessing the Bottleneck Analysis Menu Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Accessing the Bottleneck Analysis Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Accessing the Factors Affecting Executing Transactions Screen . . . . . . . . . . . . . . . . . . 20

1

Accessing the Bottleneck Analysis Menu Screens


Accessing the Bottleneck Analysis Menu Screens

IntroductionThe Bottleneck Analysis menu screens available through the OMEGAMON II Menu interface provide an easy-to-use format for working with the Bottleneck Analysis component of OMEGAMON II. The chapters that follow explain how Bottleneck Analysis works and how you can customize the displays to obtain data more specific to your IMS environment to help you monitor and tune your system.

To start Bottleneck Analysis automatically when you start OMEGAMON II, follow the CICAT installation procedures in the OMEGAMON II Configuration and Customization Guide. In the section on �Preparing the Startup Files�, specify �Autostart RTM Components� on the �Specify RTM Configuration Values� panel.


Accessing the Bottleneck Analysis Menu

Accessing the Bottleneck Analysis Menu

IntroductionThis section provides detail steps on how to access the Bottleneck Analysis menu.

ProcedureYou can access the Bottleneck Analysis menu from the OMEGAMON II Menu interface by following these steps:

1. From the OMEGAMON II CUA interface System Overview panel, select CMD/Menu Interface (OMEGAMON®) from the GoTo pull-down.OMEGAMON II displays the Zoom to OMEGAMON pop-up so that you can zoom to the Menu Interface screen space.

2. Press Enter to zoom to the default screen space.

OMEGAMON II displays the Main Menu.

3. Select BOTTLENECKS from the Main Menu and press Enter.

If you are running IBM Tivoli OMEGAMON II for IMS, the Bottleneck Analysis menu displays as shown in the following figure.

Figure 1. Bottleneck Analysis Menu

________________ ZBTL VTM OIDIRIEI /C IMSA 01/02/01 12:33:31 B > Help PF1 Exit PF3 > Enter a selection letter on the top line. ================================================================================ > Bottleneck Analysis _ A EXECUTING....... Factors affecting executing transactions _ B COMPETING...... Wait breakdown of transactions competing for resources _ C CONTROL......... Start/stop the DEXAN collector and control data collection _ D DEXAN OPTIONS ...Select eligible performance groups and other options ================================================================================

Accessing the Factors Affecting Executing Transactions Screen



IntroductionThis section provides detail steps on how to access the Factors Affecting Executing Transactions screen.

ProcedureFrom the Bottleneck Analysis menu, select option A, EXECUTING and press Enter.

A screen similar to the one in the following figure displays. This screen displays a graph that represents the percentage of time an average transaction spent in each of the execution states that the Bottleneck Analysis data collector monitors.

Figure 2. Executing Transactions Screen

Note: See �Bottleneck Analysis Displays (MDEX/PDEX)� on page 43 for more information on Bottleneck Analysis displays.

________________ ZEXEC VTM OIDIRIEI /C IMSA 01/02/01 12:24:18 B > Help PF1 Back PF3 Up PF7 Down PF8 ================================================================================ > Factors Affecting Executing Transactions > To display information about a specific group, enter the group number > directly after PDEX below. > Enter D, I, M, or S directly to the left of PDEX to display database I/O, > IMS internal, MVS, or scheduling waits only. IDEG >> Elapsed time=19:13 MN, #samples(short)=489, #samples(long)=2214 << >dopt EXEC >> Only Executing Transactions Will Be Analyzed << pdex ------Short Term %---- ------ Long Term %----- + (Elapsed time= 1:41 MN) % 0_______ 50_______100 % 0________ 50_______100 + Using CPU: 56.0|-----====> . .| 54.0|------====> . .| + Using CPU In APPL (20.0)|--->. . . .|(12.0)|-> . . . .| + Using CPU In IMS (36.0)|------> . . .|(42.0)|------=> . . .| + Database I/O Wait 36.0|------> . . .| 38.0|------> . . .| + DI21PART (20.0)|--->. . . .|(24.0)|----> . . .| + BE3PART (16.0)|--> . . . .|(14.0)|--> . . . .| + IMS Activity 8.0|-> . . . .| 8.0|-> . . . .| + ISWITCHED to CTL (4.0)|> . . . .| (2.0)|> . . . .| + IRLM Conflict Wait (4.0)|> . . . .| (6.0)|> . . . .| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Avg. Trans Executing: 5.4 3.2 ================================================================================



If you are using Bottleneck Analysis through the OMEGAMON II Menu system, the collector is attached and sampling begins at startup. If your installation has altered the startup parameters for Bottleneck Analysis, and the Bottleneck Analysis collector has not been attached, type a hyphen (-) in column 1 to the left of IDEG to attach the collector. See �Attaching the Collector� on page 26 for an explanation of how to attach the Bottleneck Analysis collector and begin collecting data.

Note: If you are using Bottleneck Analysis in a Database Control (DBCTL) environment, your screens may look different from the ones in Figure 1 on page 19 and Figure 2 on page 20. (Since transactions do not exist in a DBCTL environment, fields relating to transactions will not appear.) See �DBCTL Environment� on page 87 for a list of commands that are not applicable in a DBCTL environment.



Bottleneck Analysis Collector 23

Bottleneck Analysis Collector

Chapter overviewThis chapter provides information about the Bottleneck Analysis collector.

Chapter contentsAbout the Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Attaching the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Controlling the Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Invoking Bottleneck Analysis (IDEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Specifying Collector Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2

About the Bottleneck Analysis Collector



IntroductionThe Bottleneck Analysis collector gathers bottleneck analysis information.

The OMEGAMON II interface invokes the collector. At a user-defined interval, the collector samples the processing states of all transactions flowing through IMS and records the data it gathers in virtual storage. A processing state (also called an execution state) is either what a transaction is doing or why it is waiting. �Waiting for a Message Processing Region�, �Waiting for CPU�, and �Waiting for the Block Mover� are typical execution states. �Bottleneck Analysis Execution States� on page 51 describes execution states in more detail.

The collector runs as a subtask of Bottleneck Analysis. You only need one collector (and Bottleneck Analysis only permits one), no matter how many users log onto Bottleneck Analysis. This means that all users can access the same data.

Note: Since Bottleneck Analysis is a sample-driven collector and RTA is an event-driven collector, the degradation data values should not be directly compared to the response time data values.

Collector operationOnce the collector has been attached by the OMEGAMON II interface and begins to sample, it allocates virtual storage to hold the data it gathers. This area, often referred to as the counters or buckets, is divided into two parts: the short-term area and the long-term area. The default parameters include an option to allocate space to hold database I/O wait information by individual database name. If you invoke this option, the collector allocates an additional area, which it also divides into short-term and long-term sections.

The data areas contain counters for overall transaction activity, and also for activity broken down by transaction group. Bottleneck Analysis supports up to 30 groups. You specify to which groups a given transaction type belongs. You can use the transaction groups to target analysis to specific workloads, such as transactions which came from a specific terminal or which used a certain PSB. IBM ships Bottleneck Analysis with 10 groups which correspond to transaction (scheduling) classes 1�10.

Once the collector allocates the data areas, it begins observing transactions flowing through your IMS system and recording their execution states in its counters. The default is to sample every half-second. You can reduce this setting to as little as every tenth of a second. Very few users run the collector slower than one sample per second. The purpose of sampling rapidly is to gather a statistically significant number of samples in a short period of time.

At user-specified intervals, the collector �throws away� the data it collected and starts fresh by zeroing its counters. It does this to prevent the data from being averaged out over such a long period of time that it ceases to be of interest to the user of a realtime monitor. The collector supports two clear intervals, corresponding to its short-term and long-term data areas:



� The short-term interval is intended to be set so the data you see from the short-term counters is from the very recent past. Typically, the short-term interval is five minutes or less. IBM ships Bottleneck Analysis with a default short-term interval of 5 minutes.

� The long-term interval is intended to be set so the data you see from the long-term counters gives you a longer perspective on the performance of the system you are studying. IBM ships Bottleneck Analysis with a default long-term interval of 30 minutes.

When the long-term interval expires, Bottleneck Analysis clears both the long-term and short-term buckets. The collector continues to gather data until it is told to stop. If more than one display controller is running under the OMEGAMON II interface, the collector responds to commands from them in the order they are issued. The collector stops gathering data and frees its bucket areas when it receives an END command.

Attaching the Collector



IntroductionBy default, the Bottleneck Analysis collector attaches and data collection begins when you start up the OMEGAMON II interface. If your site has modified the startup parameters for Bottleneck Analysis and the collector is not attached, you can attach the collector in one of these ways:

� from OMEGAMON II with the -IDEG command

� when OMEGAMON II initializes with the START DEXAN command

� from the MVS console

(For more information on beginning data collection when you attach the collector, see �Starting data collection when OMEGAMON II initializes� on page 27.)

Note: You can also start the collector from the OMEGAMON II System Overview panel in the CUA interface. For more information, see the IBM Tivoli OMEGAMON II for IMS User�s Guide.

Attaching the collector from OMEGAMON IITo use the IDEG command to attach the collector from OMEGAMON II:

1. Select option C, CONTROL, from the Bottleneck Analysis menu.OMEGAMON II displays a panel where you start and stop the Bottleneck Analysis collector.

Figure 3. Attaching the Bottleneck Analysis Collector Using IDEG

2. Attach the collector by placing a hyphen (-) in column 1 next to the IDEG command and press Enter, as shown in the previous figure.

________________ KDIBEGN OI-II SW 151A 01/02/01 9:20:19 0B> Help PF1 Back PF3 Up PF7 Down PF8===========================================================================> Start/Stop the Bottleneck Analysis Collector and Control Data Collection > To start the collector, enter a hyphen (-) preceding IDEG.-IDEG >> Elapsed time= 1:55 MN, #samples(short)=218, #samples(long)=21 > To begin data collection, remove the > preceding BEGN.>begn > To suspend data collection, remove the > preceding END.>end > To stop the collector, remove the > preceding DTCH.>dtch ===========================================================================



Instead of using the menus to start the collector, you can type the -IDEG command in command mode.

The -IDEG command attaches the Bottleneck Analysis collector using an internally generated START DEXAN OMEGAMON II interface command. This command does not begin sampling, however. To begin sampling, see �Beginning data collection (BEGN)� on page 30.

Attaching the collector when OMEGAMON II initializesTo attach the Bottleneck Analysis collector when OMEGAMON II initializes, issue the following OMEGAMON II interface command in the RKANPAR member, KOIDEXmp (by default this member is executed by KOImpP00.)

START DEXAN GLOBAL=mp

The GLOBAL= parameter specifies which RKANPAR(KOIGBL) load module MVS is to load to supply Bottleneck Analysis parameter defaults. This load module also supplies the default transaction groups. If you do not specify the GLOBAL= parameter, it defaults to M0 and MVS loads and uses the IBM-supplied TKANPAR(KOIGBLmp) load module during initialization. It is recommended that you create your own RKANPAR(KOIGBLmp) load module according to the directions in the Configuration and Customization Guide, in order to collect information on your site�s workload groups.

Starting data collection when OMEGAMON II initializesIf you add the EXEC KOIDEXmp OMEGAMON II interface command to the RKANPAR(KOImpP00) member, you can use the IDEG=BEGN keyword to set the collector to begin sampling immediately after the Bottleneck Analysis collector is attached.

By default, the collector attaches and begins to collect data at OMEGAMON II interface startup when the IDEG=BEGN keyword is included with the START DEXAN command in the RKANPAR(KOIDEXmp) member. If your site has commented out the EXEC KOIDEXmp command, you can issue the START DEXAN or EXEC KOIDEXmp command to the OMEGAMON II interface from the MVS operator�s console.

To begin data collection immediately after attaching the collector, issue the following command to the OMEGAMON II interface:

MODIFY <MPREFIX><IMSID>,START DEXAN,IDEG=BEGN,GLOBAL=mp

or modify the EXEC KOIDEXmp statement.

The GLOBAL= parameter specifies which RKANPAR(KOIGBLmp) OMEGAMON II load module MVS should load to supply Bottleneck Analysis parameter defaults. This load module also supplies the default transaction groups. If you do not specify the GLOBAL= parameter, it defaults to M0 and MVS loads and uses TKANPAR(KOIGBLmp) during initialization. It is recommended that you follow the customization process described in the Configuration and Customization Guide, which instructs you not to load the TKANPAR(KOIGBLmp) module.



Attaching the collector at an MVS consoleYou can also enter the START DEXAN command at an MVS console, as in the following example:

MODIFY <MPREFIX><IMSID>,START DEXAN GLOBAL=mp

MPREFIX is the two-character modify prefix specified in your startup PROC during installation. The default is M0. IMSID is the four-character subsystem name defined in the IMS SYSGEN. See the Configuration and Customization Guide for information. Again, you can use the GLOBAL= parameter to specify the RKANPAR(KOIGBLmp) OMEGAMON II load module for MVS to load.


Controlling the Collector

Controlling the Collector

IntroductionWhen you attach the collector, it initializes itself so it can receive control commands. The collector does not begin sampling at this time; it waits for further instructions from Bottleneck Analysis.

You can issue instructions to the collector by typing commands in command mode or by using the Menu interface panels.

Before you can tell the collector what to do in command mode, you must first issue the IDEG major command. You can type the IDEG major command in command mode as follows:

IDEG

Then, you can issue minor commands of IDEG to control the collector as described in the following sections.

Alternatively, you can use the Menu interface to issue IDEG minor commands. When you use the Menu interface, the IDEG major command automatically precedes any minor command you select.

The following sections describe the IDEG minor commands that you can use to control the collector.

Invoking Bottleneck Analysis (IDEG)



IntroductionAny Bottleneck Analysis minor command must be preceded by the IDEG major command. You can then issue the following minor commands of IDEG.

Beginning data collection (BEGN)The BEGN minor command tells the collector to finish initialization and begin sampling. You can type the BEGN command in command mode as shown in the following figure.

Figure 4. IDEG and BEGN Commands Output

This figure shows that the collector started 33 seconds ago.

Note: Some of the collector control commands this manual documents can only be issued when the collector is not sampling (either the collector has not received a BEGN command or it has received an END command to halt sampling). An active collector cannot accept these commands because they affect the way the collector allocates the data areas it creates at BEGN time. You can issue any control commands which Bottleneck Analysis must receive before beginning collection between IDEG and BEGN in command mode or before issuing the BEGN command from the Menu interface.

Ending data collection (END)The END minor command signals the Bottleneck Analysis collector to stop sampling. The collector remains attached, but dormant, waiting for a BEGN command to tell it to start collecting information again. The following figure illustrates using the END command in command mode.

Figure 5. IDEG and END Commands Output

Use the END command to stop the collector when you want to change some of the options, such as the database I/O reporting option. (�Database sampling (DBSW)� on page 35 describes how this is done with the DBSW command.)

IDEG >> Elapsed time= 33 SEC #samples(short)=7, #samples(long)=71 <<>begn >> Collector now active <<

IDEG >> Elapsed time= 6:37 MN, #samples(short)=185, #samples(long)=7 36 <<>end >> Collector now dormant <<



Detaching the collector from OMEGAMON II (DTCH)The DTCH minor command detaches the Bottleneck Analysis collector from the interface. If the collector is active at the time you enter the DTCH command, Bottleneck Analysis stops it and then detaches it. This command has the same effect as the interface modify command STOP ID=DX, entered at an MVS console.

To detach the collector, you can issue the DTCH minor command of the IDEG major command, as illustrated in the following figure.

Figure 6. DTCH Command Output.

In the Menu Interface:

1. Detach the collector by selecting option C, CONTROL, from the Bottleneck Analysis menu.

2. Remove the > character from before the DTCH command and press Enter to detach the collector.

The panel updates as shown in the following figure.

Figure 7. Using DTCH from the Menu Interface

After it executes, the DTCH command comments itself out by setting its label field to >.

If the collector is active at the time you enter the DTCH command, Bottleneck Analysis stops it, and then detaches it.

To attach the collector again, enter the IDEG command with a hyphen in column 1, as described in �Attaching the Collector� on page 26.

IDEG >> Collector not active <<>dtch >> Collector Detached <<

________________ KDIBEGN OI-II SW 151A 01/02/01 9:20:19 0B> Help PF1 Back PF3 Up PF7 Down PF8===============================================================================> Start/Stop the DEXAN Collector and Control Data Collection > To start the collector, enter a hyphen (-) preceding IDEG.-IDEG >> Collector not active << > To begin data collection, remove the > preceding BEGN.>begn > To suspend data collection, remove the > preceding END.>end > To stop the collector, remove the > preceding DTCH.>dtch >> Collector Detached << ===============================================================================



Other methods for detaching the collectorYou can also detach the collector using one of the following methods:

� Issue the STOP ID=DX interface command to the OMEGAMON II interface.

� Issue the STOP ID=DX OMEGAMON II interface command at the MVS console, as in the following example:

MODIFY <MPREFIX><IMSID>,STOP ID=DX

MPREFIX is the two-character modify prefix specified in your startup PROC during installation. The default is M0. IMSID is the four-character subsystem name defined in the IMS SYSGEN. See the Configuration and Customization Guide for information.

� Shut down IMS (this terminates the entire OMEGAMON II address space).

BMP Transaction Sampling (BMPX)You may want to exclude transactions that are being processed in batch message processing regions (BMPs) from analysis, since a terminal user is not waiting for a response from this type of transaction. The BMPXON command tells the collector to ignore transactions being processed in BMPs. BMPXOFF tells the collector to gather data about transactions being processed in message-driven BMP regions. Either command forces the collector to clear both the long-term and short-term data gathered so far, and then places the comment character (>) in its label field so Bottleneck Analysis does not re-execute it.

The following figure shows output from BMPXOFF and BMPXON commands.

Figure 8. BMPXOFF and BMPXON Commands Output

Specify BMPX (without ON or OFF) to display the current setting. BMPX followed by a question mark (BMPX?) also displays the current setting. If you do not set this option using the BMPX command, Bottleneck Analysis uses the default in the RKANPAR(KOIGBLmp) module you use (BMPXOFF in the TKANPAR(KOIGBLmp) module that IBM supplies.)

In the Menu Interface:

1. Specify BMP thread sampling by selecting option D, OPTIONS, from the Bottleneck Analysis menu.

2. Remove the > character from before the BMPX command.

3. Add OFF or ON to the BMPX command and press Enter.

The panel updates as shown in Figure 9 on page 33.

-IDEG >> Elapsed time= 16 SEC, #samples(short)=35, #samples(long)=35 <<>BMPXOFF >> BMP ACTIVITY IS BEING RECORDED BY Bottleneck Analysis <<>BMPXON >> BMP ACTIVITY IS BEING IGNORED BY Bottleneck Analysis <<



Figure 9. Using BMPX from the Menu Interface

You cannot change the BMPX option while the EPILOG historical component of OMEGAMON II is active. See the IBM Tivoli OMEGAMON II for IMS Historical Component (EPILOG) Reference Manual for information on stopping EPILOG.

Non-message-driven BMP transaction sampling (NMSX)You may want to exclude non-message-driven (BMPs) from analysis, since they are not associated with transactions and a terminal user is not waiting for a response from this type of region. The NMSXON command tells the collector to ignore non-message-driven BMPs. NMSXOFF tells the collector to gather data about non-message-driven BMP regions. Either command forces the collector to clear both the long-term and short-term data gathered so far, and then places the comment character (>) in its label field so Bottleneck Analysis does not re-execute it.

The following figure shows output from NMSXOFF and NMSXON commands.

Figure 10. NMSXOFF and NMSXON Commands Output

Specify NMSX (without ON or OFF) to display the current setting. NMSX followed by a question mark (NMSX?) also displays the current setting. If you do not set this option via the NMSX command, Bottleneck Analysis uses the default in the KOIGBL module you use. (The default setting is NMSXON in the KOIGBLmp module that IBM supplies.)

The NMSX command is a functional subset of BMPX. If BMPXON is in effect, then all BMP activity is ignored regardless of the NMSX switch, as shown in Figure 11 on page 34.

________________ KDIOPT OI-II SW 151A 01/02/01 9:20:19 0B > Help PF1 Back PF3 Up PF7 Down PF8==========================================================================> Eligible Performance Groups and Other Options > To change the value of an option, enter the new value directly after the> option. For the THRS option, enter a space followed by the new value. IDEG >> Elapsed time= 43 SEC, #samples(short)=61, #samples(long)=61>bmpxOFF >> BMP ACTIVITY IS BEING RECORDED BY Bottleneck Analysis <<>clrl 30 >> long-interval counters will be reset every 30 minutes <<>clrs 5 >> short-interval counters will be reset every 5 minutes << dbsw >> I/O Analysis will be done by individual database << stim >> Sample Time Interval= .5 Seconds << thrs >> 0 is PDEX wait percent threshold <<==========================================================================

>NMSXOFF >> Non-message-driven BMP ACTIVITY IS BEING RECORDED BY Bottleneck Analysis <<>NMSXON >> Non-message-driven BMP ACTIVITY IS BEING IGNORED BY Bottleneck Analysis <<



Figure 11. NMSX On and Off Conditions

You cannot change the NMSX option while the EPILOG historical component of OMEGAMON II is active. See the IBM Tivoli OMEGAMON II for IMS Historical Component (EPILOG) Reference Manual for information on stopping EPILOG.

Long-term clear interval (CLRL)The CLRL command sets the interval for clearing the long-term data counters to nn minutes. Bottleneck Analysis accepts a value within the range of 1 and 480 minutes (8 hours). A reasonable value for the long-term clear interval is 30 minutes (CLRL30). The value you enter for CLRL must be longer than the short-term clear interval set by CLRS. When you change the value of CLRL, the collector clears both the short-term and long-term counters, and CLRL places the comment character (>) in its label field so Bottleneck Analysis does not re-execute it.

Enter CLRL (without a numerical argument) to clear both the short-term and long-term counters without changing the clear interval.

The following figure shows two CLRL commands, one with an argument and the other without.

Figure 12. CLRLnn and CLRL Commands Output

The CLRL? command displays the existing long-term clear interval. If you do not set this option via the CLRL command, Bottleneck Analysis uses the default in the RKANPAR(KOIGBL) OMEGAMON II load module you use. (This is CLRL30 in the TKANPAR(KOIGBLmp) module IBM supplies.)

NMSXON NMSXOFF

BMPX ON

Non-message BMP activity ignored


BMPX OFF


Non-message BMP activity is recorded

-IDEG >> Elapsed time= 16 SEC, #samples(short)=35, #samples(long)=35 <<>CLRL30 >> LONG-INTERVAL COUNTERS WILL BE RESET EVERY 30 MINUTES <<>CLRL >> BOTH SHORT AND LONG COUNTERS HAVE BEEN RESET <<



Short-term clear interval (CLRS)The CLRS command sets the interval for clearing the short-term data counters to nn minutes. Bottleneck Analysis accepts a value within the range 01 to 99. The value you enter for CLRS must be shorter than the long-term clear interval set with CLRL. A reasonable value for the short-term clear interval is five minutes (CLRS05). Use at least 30 samples for statistical significance; how long it takes to get them depends on the setting of the cycle time.

When you change the value of CLRS, Bottleneck Analysis clears both the short-term and long-term counters, and CLRS places the comment character (>) in its label field so Bottleneck Analysis does not re-execute it.

Specify CLRS (without a numerical argument) to clear both the short-term and long-term counters without changing the clear interval.

The following figure shows two CLRS commands, one with an argument and the other without.

Figure 13. CLRSnn and CLRS Commands Output

The CLRS? command displays the existing short-term clear interval. If you do not set this option via the CLRS command, Bottleneck Analysis uses the default in the RKANPAR(KOIGBL) OMEGAMON II load module you use. (This is CLRS05 in the TKANPAR(KOIGBLmp) module IBM supplies.)

Database sampling (DBSW)The DBSW minor command controls whether the Bottleneck Analysis collector accumulates bottleneck analysis information by individual database name (DBSWON), or not (DBSWOFF).

IBM provides this option because Bottleneck Analysis must allocate counters for each database for each transaction group you define. The amount of virtual storage Bottleneck Analysis requires can therefore be sizable when the product of the number of transaction groups and databases is large.

The number of bytes Bottleneck Analysis requires is:

8 * (<number of databases> * (<MAXG>+1))

MAXG is the maximum number of transaction groups for which Bottleneck Analysis allocated space. For more information about the MAXG command, see the IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual.

You cannot change the database sampling option while the Bottleneck Analysis collector is active. If you attempt to do so, Bottleneck Analysis displays an error message. To change the database sampling option, issue the IDEG and END commands to stop the

-IDEG >> Elapsed time= 32 SEC, #samples(short)=63, #samples(long)=63 <<>CLRS05 >> SHORT-INTERVAL COUNTERS WILL BE RESET EVERY 5 MINUTES <<>CLRS >> BOTH SHORT AND LONG COUNTERS HAVE BEEN RESET <<



collector, change the DBSW setting, and then issue the IDEG and BEGN commands to restart the collector. Figure 14 on page 36 shows this series of commands.

Figure 14. Changing the Database Sampling Option (DBSW)

To display the current database selection option, enter either DBSW? or DBSW (without operands). If you enter ON or OFF, the DBSW command comments itself out after execution by setting its label field to >.

If you do not set this option using the DBSW command, Bottleneck Analysis uses the default in the RKANPAR(KOIGBL) OMEGAMON II load module you use. (This default is DBSWON in the TKANPAR(KOIGBLmp) module IBM supplies.)

Transaction sampling (DOPT) The DOPT minor command controls whether the MDEX and PDEX commands display information about executing, competing, or all (including non-competing) transactions. �Bottleneck Analysis Execution States� on page 51 describes the concepts of executing and competing transactions. Executing transactions are those actually associated with an IMS dependent region.

The DOPT command lets you select which type of transaction you are interested in analyzing. This prevents Bottleneck Analysis from washing out the degradation data when there are many different types of transactions in the message queue. The DOPT command affects the displays only; the Bottleneck Analysis collector continues to gather data on both competing and non-competing transactions. The following figure shows the format of the DOPT command.

Figure 15. DOPT Command Format

IDEG >> Collector not active <<>END >> Collector now dormant <<>DBSWOF >> I/O Analysis will not be done by individual database <<>DBSWON >> I/O Analysis will be done by individual database << IDEG >> Collector not active <<>BEGN >> Collector now active <<

DOPT ccccc

where ccccc is one of the following:

COMP Display information about competing transactions only

EXEC Display information about executing transactions only

TOTAL Display information about all transactions

ALL Alias of TOTAL

? Display current setting of DOPT



The default setting of the DOPT option in the KOIGBLmp module is COMP. If you enter the DOPT command without an operand, Bottleneck Analysis displays the current setting.

Specifying Collector Options



IntroductionThis section describes how to specify options for the collector using IDEG minor commands or the Menu interface. It describes how to perform the following tasks:

� exclude PSBs based on whether they are being processed in batch message processing regions

� set the long-term clear interval� set the short-term clear interval� control whether the collector collects data by individual database name� suspend the collector� resume collector sampling� set the sampling interval� display the threshold for the MDEX command� display the scaling factor for the MDEX command� display the threshold for the PDEX command� display information on collector abends

Suspending the collector (SUSP)The SUSP command tells the Bottleneck Analysis collector to stop sampling temporarily, but not to clear its short- and long-term buckets. You can use this command to freeze the collector data long enough for you to analyze the information using the MDEX or PDEX command.

Figure 16. SUSP Command Output

Once you finish examining the data, you can start the collector again using the RESM command.

Resuming collector sampling (RESM)The RESM command tells the Bottleneck Analysis collector to resume its sampling. Use the RESM command only after you use the SUSP command to suspend the collector. RESM does not clear any counters, and the data displayed should not be taken as representative of the interval during which collection was suspended.

-IDEG >> Elapsed time= 3:15 MN, #samples(short)=352, #samples(long)=352 <<>susp >> Collector now suspended <<



Figure 17. RESM Command Output

Sampling interval control (STIM)The Bottleneck Analysis collector analyzes the IMS environment at a fixed sample rate. The STIM command controls the sample time interval that the Bottleneck Analysis collector uses. If you do not supply a STIM value, Bottleneck Analysis uses the default value in the KANPAR(KOIGBL) OMEGAMON II load module. As IBM ships Bottleneck Analysis, this default is 0.5 seconds. You can use the STIM command to vary this rate from a low of 0.1 seconds to a high of 9.9 seconds. STIM interprets the value you enter in tenths of a second (for example, STIM15 indicates a sample time of 1.5 seconds). You should use a STIM value which is small enough to collect at least 30 samples during the short-term interval so your data will be statistically significant.

If you enter the STIM command without a numeric argument, it displays the current sample time. When you enter the STIM command with a valid numeric argument, Bottleneck Analysis clears both the short- and long-term data areas before the collector begins to sample at the new rate. If you change the sample interval, the STIM command comments itself out (by placing a > in its label field) after it executes.

Figure 18. STIM Command Output

Displaying threshold for MDEX command (MTHR)Bottleneck Analysis recognizes more IMS transaction execution states than the MDEX command can display on any model 3270 screen. (For more information about the MDEX command, see �Bottleneck Analysis Displays (MDEX/PDEX)� on page 43.) In order to reduce the size of the display, the MTHR command lets you specify a threshold value. MDEX does not display any state whose short- and long-term average counts are both less than the value specified using MTHR.

The format of this command is MTHR nnnn where nnnn is a value between 0-9999. (9999 actually represents a threshold value of 999.9 transactions.) If you omit nnnn, MTHR displays the current threshold value.

Figure 19. MTHR Command Output

IDEG >> Elapsed time= 3:15 MN, #samples(short)=352, #samples(long)=352 <<>resm >> Collector has been resumed <<

-IDEG >> Elapsed time= 32 SEC, #samples(short)=63, #samples(long)=63 <<>STIM 5 >> Sample Time Interval= .5 Seconds <<

IDEG >> Elapsed time= 3:15 MN, #samples(short)=352, #samples(long)=352 << mthr 3 >> .3 is MDEX display threshold <<



The default for MDEX is 0. It displays all non-zero transaction states. There is no way to force MDEX to display all possible transaction states. You can change the default permanently on the $OIDEXAN macro in the RKANPAR(KOIGBL) OMEGAMON II load module. Refer to the Configuration and Customization Guide for details.

Scaling factor for MDEX command (SCAL)The MDEX command calculates average transaction counts for each of the various execution states to only one decimal place (0.1 transactions), so low-volume systems could experience many counts which round down to zero. The SCAL command lets you specify a scaling factor (multiplier), which is multiplied against the value prior to computing the transaction average. Thus you can see where transactions are spending time in finer detail. The format of this command is SCAL nnn where nnn is a value between 1-100. If you do not supply a value, Bottleneck Analysis uses the default in the RKANPAR(KOIGBL) OMEGAMON II load module. The default is 1 in the TKANPAR(KOIGBLmp) module IBM supplies.

For example, if you specify a scaling factor of 10, an average count of .03 displays as .3 instead of being rounded down to .0. The following figure shows the SCAL command in combination with the MTHR command.

Figure 20. MTHR and SCAL Commands Output

Displaying threshold for PDEX command (THRS)Bottleneck Analysis can detect and display a large number of execution states, so the PDEX display can become quite large. It is very possible, in fact, for PDEX to fill even a 43-line screen with reasons that account for only a tiny percentage of the transaction wait time. (For more information about the PDEX command, see �Bottleneck Analysis Displays (MDEX/PDEX)� on page 43.)

The THRS minor command sets a threshold which suppresses insignificant states on the PDEX display. If the percentage of total transaction time of a particular state (in both the short- and long-term interval) is less than the THRS threshold, PDEX does not include it in the display. This will probably cause the percentages that do display to total less than 100%. The following figure shows a typical THRS command.

Figure 21. THRS Command Output

The THRS command accepts values between 0 and 99 percent. If you specify 0 (the default), PDEX does not display transaction states which were never seen, since this

IDEG >> Elapsed time= 2:49 MN, #samples(short)=372, #samples(long)=372 <<MTHR >> .0 is MDEX display threshold <<SCAL >> 10 is MDEX display scale value <<

IDEG >> Elapsed time= 4:19 MN, #samples(short)=458, #samples(long)=458 << THRS >> 0 is PDEX wait percent threshold <<



would generate a large, useless display. Yet, some statistics may still display as zero, because they were rounded down to zero. PDEX only displays true zero statistics if they are for the short interval and the transaction state in the long interval is non-zero.

Collector abend display (ABCD)If the Bottleneck Analysis collector abends, Bottleneck Analysis saves PSW and register information. The ABCD command displays this information so you can provide it to IBM Software Support.

Figure 22. ABCD Command Output

A warning message appears if the Bottleneck Analysis collector abends when you issue the IDEG major command. The design of the collector allows it to recover from the kinds of errors a monitor like Bottleneck Analysis normally encounters (for example, 0C4 or loops because a chain moved), so you should definitely report any abends.

IDEG >> Elapsed time= 4:19 MN, #samples(short)=458, #samples(long)=458 << ABCD >> OI206: Collector has not ABENDed <<



Bottleneck Analysis Displays (MDEX/PDEX) 43

Bottleneck Analysis Displays(MDEX/PDEX)

Chapter overviewThis chapter provides information about the MDEX and PDEX display commands.

Chapter contentsDisplaying Bottleneck Analysis Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Examples of MDEX and PDEX Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Factors That Influence the Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Average Transaction Counts Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3

Displaying Bottleneck Analysis Data



IntroductionOnce the Bottleneck Analysis collector starts and is gathering samples of the activity of transactions going through your IMS system, you can display the data it gathers with one or both of the following IDEG minor commands:

Both MDEX and PDEX accept arguments which allow you to include all transactions in the display or restrict the display to a single transaction group. The IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual discusses the concept of transaction groups and how you define them.

Whether you display all transactions or just a single group, you can restrict the Bottleneck Analysis display to executing transactions, competing transactions (includes, but not limited to, executing transactions), or include all transactions, both competing and non-competing.

Note: It is extremely important that you understand the concepts of executing, competing, and non-competing transactions. �Bottleneck Analysis Execution States� on page 51 covers these topics.

Of the two forms of displays, users tend to favor PDEX because they find it presents the data in a form which is usually easier to use. You should realize, however, that the data MDEX and PDEX present is really the same. Given either display and a calculator, you can produce the other within a few minutes.

Bottleneck Analysis Display Commands FormatThe following figure shows the format of the Bottleneck Analysis display commands MDEX and PDEX.

Figure 23. MDEX/PDEX Commands Format

MDEX Displays average counts of transactions in each of the execution states the Bottleneck Analysis collector monitors.

PDEX Displays the percent of time an average transaction spent in each of the execution states the Bottleneck Analysis collector monitors.

IDEG------> major command for MDEX and PDEXaMDEXnn GRP=cccccccc - or -aPDEXnn GRP=cccccccc

group name or number command argument field (DEXAN group number) command command label field



The command label field lets you limit the scope of the Bottleneck Analysis display to specific execution state groups. Here are the valid command label specifications:

See �Execution state groups� on page 55 for an explanation of these groups.

Use the command argument field or the GRP= keyword to limit the scope of the Bottleneck Analysis display. To see only certain transactions, enter a Bottleneck Analysis group number from 1 to 30 (or the current MAXG value) with the MDEX or PDEX command. For more information on transaction groups or the MAXG command, refer to the IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual.

If you leave both the command argument field and the GRP= keyword blank, Bottleneck Analysis displays the execution states of all IMS transactions not excluded by the BMPX or DOPT minor commands of IDEG.

blank Displays all execution state analyses.

D Displays database I/O waits only.

I Displays IMS internal waits only.

M Displays MVS waits only.

S Displays scheduling waits only.

O Displays output waits.

E Displays external subsystem waits.

Examples of MDEX and PDEX Output



IntroductionAt first glance, the displays MDEX and PDEX produce look very much alike. Both displays show activity for the execution states listed down the left-hand side over both a short-term interval and a long-term interval. The short-term interval is simply the most recent portion of the long-term interval.

Example of MDEX outputThe following figure shows a typical MDEX display.

Figure 24. MDEX Command Output

The figure above shows the following information:

� The command specified is MDEX, which displays the average count of transactions in each execution state.

� The label field does not contain a selection character, so all types of execution states are eligible for display.

� The argument field does not contain a transaction group number and the GRP= keyword is not specified, so MDEX displays data about all transactions.

� Bottleneck Analysis last cleared the long-term counters 1 minute and 41 seconds before MDEX generated this display (Elapsed time= 1:41 MN).

MDEX ------Short Term ----- ------Long Term ------ + (Elapsed time= 1:41 MN) 0_______ 10_______ 20 0_______ 10_______ 20 + Using CPU: 3.0|--> . . . .| 1.7|> . . . .| + Using CPU In APPL (1.1)|> . . . .| (.4)|> . . . .| + Using CPU In IMS (1.9)|> . . . .| (1.3)|> . . . .| + Scheduling Waits: 0| . . . .| .3|> . . . .| + Wait For GU (0)|> . . . .| (.1)|> . . . .| + Wait For MPP (0)|> . . . .| (.1)|> . . . .| + Wait For Resched (0)|> . . . .| (.1)|> . . . .| + Database I/O Waits 1.9|> . . . .| 1.2|> . . . .| + DI21PART (1.1)|> . . . .| (.7)|> . . . .| + BE3PART (.8)|> . . . .| (.5)|> . . . .| + MVS Waits: .2|> . . . .| .1|> . . . .| + CPU Wait (MPP/BMP) (.2)|> . . . .| (.1)|> . . . .| + IMS Activity: .2|> . . . .| .0|> . . . .| + ISWITCHED to CTL (.2)|> . . . .| (.0)|> . . . .| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Avg Trans Executing (5.4)|----> . . .| (3.2)|--> . . . .| + Avg Trans Competing (5.4)|----> . . .| (3.2)|--> . . . .| + Avg Trans Not Comp (0)| . . . .| (0)| . . . .| + Avg Total Trans: (5.4)|----> . . .| (3.2)|--> . . . .| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Display threshold (MTHR) is .0 / Scaling factor (SCAL) is 1



� The MDEX display includes information about all transactions. The last line of the display indicates this with Avg. Total Trans:, rather than just Avg. Trans Executing: or Avg. Trans Competing:.

Whether the DOPT option is COMP or EXEC, it is important to look at the Avg. Total Trans: line to get an indication of the load on the system.

� The display threshold set by MTHR is .0, so all non-zero execution states display.

� The scaling factor set by SCAL is 1, so MDEX multiples all values that appear by 1, and they are thus true values.

Example of PDEX outputThe following figure shows a typical PDEX display.

Figure 25. PDEX Command Output

The figure above shows the following information.

� The command specified is PDEX, which displays the percentage of time an average transaction was in each execution state.

� The label field does not contain a selection character, so all types of execution states are eligible for display.

� The argument field does not contain a transaction group number and the GRP= keyword is not specified, so data about all transactions displays.

� Bottleneck Analysis last cleared the long counters 1 minute and 41 seconds before PDEX generated this display (Elapsed time= 1:41 MN).

� The PDEX display is limited to executing transactions, indicating that the DOPT option was set to EXEC. (�Transaction sampling (DOPT)� on page 36 describes the DOPT command.) The last line of the display indicates this with Avg. Trans Executing:, rather than Avg. Trans Competing: or Avg. Total Trans:.

Whether the DOPT option is COMP or EXEC, it is important to look at the last line to get an indication of the load on the system.

PDEX ------Short Term %---- ------ Long Term %----- + (Elapsed time= 1:41 MN) % 0_______ 50_______100 % 0________ 50_______100 + Using CPU: 46.0|-----====> . .| 44.0|------====> . .| + Using CPU In APPL (20.0)|--->. . . .|(12.0)|-> . . . .| + Using CPU In IMS (26.0)|------> . . .|(32.0)|------=> . . .| + Scheduling Waits: 3.0|> . . . .| 3.0|> . . . .| + Wait for GU (1.0)|> . . . .| (1.0)|> . . . .| + Wait for MPP (1.0)|> . . . .| (1.0)|> . . . .| + Wait for Resched (1.0)|> . . . .| (1.0)|> . . . .| + Database I/O Wait 36.0|------> . . .| 38.0|------> . . .| + DI21PART (20.0)|--->. . . .|(24.0)|----> . . .| + BE3PART (16.0)|--> . . . .|(14.0)|--> . . . .| + IMS Activity 15.0|-> . . . .| 8.0|> . . . .| + ISWITCHED to CTL (7.0)|> . . . .| (2.0)|> . . . .| + IRLM Conflict Wait (8.0)|> . . . .| (6.0)|> . . . .| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Avg. Trans Executing: 5.4 3.2

Factors That Influence the Displays



IntroductionA number of factors determine what data the MDEX and PDEX commands display. These factors include:

� Whether or not the collector gathered data about message-driven BMPs. The BMPX command controls the collection of this data. �BMP Transaction Sampling (BMPX)� on page 32 describes the BMPX command.

� Whether or not the collector gathered data about transaction DL/I I/O for each individual database, or just for database I/O as a whole. The DBSW command controls the collection of this data. �Database sampling (DBSW)� on page 35describes the DBSW command.

� Whether the MDEX or PDEX command restricts its display to a certain class of execution states. To indicate the class of execution states, put one of a set of characters in the label field (column 1) of the command as �Bottleneck Analysis Display Commands Format� on page 44 describes.

� Whether the MDEX or PDEX command restricts its display to a single transaction group. A numeric argument from 01 to 30 following the command indicates that MDEX or PDEX should only display data for transactions in a certain (user defined) group. For example, PDEX02 causes bottleneck analysis to only display data for transactions which the collector determined to fall in Group 2. The IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual, explains how to define groups. The display can also be limited to a single group by using the GRP= keyword to specify the transaction group�s number or name.

� Whether you specified that the display be restricted to only executing transactions, only competing transactions, or that the display not be restricted. The purpose of these restrictions is to prevent unimportant execution states from �washing out� the important ones on a PDEX display, or misleading you on an MDEX display. You specify the restrictions using the DOPT minor command as explained in �Transaction sampling (DOPT)� on page 36.

� For MDEX, the current display threshold and scaling factor. Only execution states whose short- and long-term average counts are less than the value specified via the MTHR command display. �Displaying threshold for MDEX command (MTHR)� on page 39 explains how to vary the display threshold. The SCAL command lets you further control the display by letting you set a scaling factor. With it, you can display execution states whose short- and long-term average counts might ordinarily be too small to see. How you specify the scaling factor is explained in �Scaling factor for MDEX command (SCAL)� on page 40.

� For PDEX, the current display threshold. PDEX only displays execution states which account for more than the percentage of an average transaction�s execution time specified using the THRS minor command. If you specified a percentage greater than 0 using THRS, then the execution state numbers may not add up to 100%. On the



other hand, setting the percentage greater than zero reduces the size of the display. �Displaying threshold for PDEX command (THRS)� on page 40 describes the THRS command.

� The actual activity on your system has the greatest effect on the MDEX and PDEX displays. MDEX and PDEX will not display an execution state if there were no transactions seen in it. It would be impractical to do otherwise since there are so many possible execution states in IMS.

� Whether or not you are using Bottleneck Analysis in a DBCTL environment. Since transactions do not exist in a DBCTL environment, fields on MDEX and PDEX displays relating to transactions will not appear. Also, on MDEX displays, only a subset of MVS and IMS wait reasons are displayed.

Average Transaction Counts Statistics


Average Transaction Counts Statistics

IntroductionBottleneck Analysis displays the average number of either total, executing, or competing transactions (depending on the setting of the DOPT command) for both the short-term and the long-term interval. At the bottom of the MDEX display, Bottleneck Analysis displays the average number of total, executing, competing, and non-competing transactions for both the short-term and the long-term interval. While they are not statistics about execution states, these numbers can be very valuable.

The PDEX profile of an IMS system can remain the same or even improve over normal (good) operation, and yet the users might all suddenly start complaining about response time. Bottleneck Analysis does not see all stages in the life of an IMS transaction. Specifically, it does not see transit time in the TP network.

If network delays become a problem (perhaps a link failed and its traffic has been re-routed over a much slower backup link) the load on the central IMS system will decrease. This will probably mean that the PDEX profile will improve (shift towards using CPU) due to the decreased contention for system resources. What will change, however, are the average transaction counts. The total transaction count may not change very much (because of the large number of transactions that may be in the queue for BMPs or MPPs which have not reached their threshold), but the average competing transaction count should plummet, reflecting the reduced workload reaching the machine. When this happens, suspect network problems.

Bottleneck Analysis Execution States 51

Bottleneck Analysis Execution States

Chapter overviewThis chapter provides information about the Bottleneck Analysis execution states.

Chapter contentsAbout Execution States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56IMS Scheduling Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Database I/O Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63MVS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64IMS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Output Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80External Subsystem Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4

About Execution States



IntroductionThis section discusses the Bottleneck Analysis execution states and the execution state groups.

Execution statesThe Bottleneck Analysis collector considers each transaction to be in one of the three following execution states.

The collector considers all executing transactions as competing also, although not all competing transactions are executing (those in the message queue are not).

Non-competing The collector considers a transaction to be non-competing when it is in a state where IMS could not process it even if it were the only IMS transaction in an IMS system running on a totally dedicated MVS processor. For example, the collector considers a transaction to be non-competing when it is queued for a program that is stopped.

Competing The collector considers a transaction to be competing when it is in a state where it is eligible to be processed. At any instant, a single transaction is either in a competing or non-competing execution state; there is no overlap.

Competing transactions are either using CPU, doing I/O, or waiting in line behind other transactions for their turn to use CPU and do I/O. They may wait in the message queue, as a transaction does when the only MPP servicing its class is busy, or they may wait in a dependent region, as a transaction does queued for an IMS latch. Wherever the wait actually occurs, however, there is the concept that a competing transaction would always be either using CPU or doing I/O if it were the only transaction in an IMS system on a dedicated CPU. (MVS might be using CPU or doing I/O on behalf of the transaction. An example of this is the resolution of a page fault, which is as much work done on behalf of the transaction as the loading of a load module overlay segment.)

Executing The collector considers a transaction to be executing when an IMS ITASK processes it. A dependent region may have acquired it for processing, in which case another way of saying this is that the transaction is �on a PST� (Partition Specification Table�the control block which represents a dependent region to IMS). Transactions which are being actively processed by the teleprocessing logic of IMS are also considered to be executing. Such transactions are executing under a CLB (communications line block�which represents a BTAM line or a VTAM® node to IMS) instead of a PST.



Transactions that are executing in Bottleneck Analysis terms are not necessarily executing in MVS terms. For example, everyone would consider a transaction whose application program is actually using the CPU to be executing. Bottleneck Analysis also considers a transaction that is hanging in the scheduling process waiting for another transaction to let go of the block mover also to be executing from the time a PST acquired it.

Note: The terms non-competing, competing, and executing are as readily applied to the execution states measured by Bottleneck Analysis as to the transactions found by the collector in those states. In this manual, you will see both usages of this terminology.

These concepts are carefully defined in Bottleneck Analysis because the implementation of IMS as a queueing system makes it easy for information about what is really degrading an IMS system to be lost in the data about how many messages are in the message queue.

To understand the importance of being able to exclude non-competing transactions from a display, consider a typical IMS system that queues transactions for BMPs. All day long MPPs issue transactions which request a BMP to update a database. IMS does not actually run the BMP until 3:00 AM when its use of the database will not interfere with the performance of the online inquiry transactions. By 3:00 AM there are thousands of transactions in the queue for the BMP. What would a PDEX display of this system look like?

If Bottleneck Analysis did not exclude such transactions, Wait For BMP could be 100% for the system as a whole. Bottleneck Analysis will observe other execution states, of course, but it will round them down to zero in the face of the thousands of BMP transactions. There are a number of ways to remedy this problem:

� You could set the BMPX option to ON, which causes the collector to ignore all transactions destined for BMPs. The problem with this is that you could not track the performance of scheduled BMP regions with Bottleneck Analysis.

�BMP Transaction Sampling (BMPX)� on page 32 discusses the BMPX option.

� You could use the transaction group facility to put all the BMP transactions into group 01 and all others into group 02. Then you could use PDEX02 to see just MPP traffic. The disadvantage of doing this is that you would have to update the Bottleneck Analysis group tables each time you a new transaction. Also, you could not use this mechanism to separate transactions destined for scheduled BMPs (which are worth watching) from transactions destined for unscheduled ones (which are not).

For more information about the transaction group facility, see the IBM Tivoli OMEGAMON II for IMS Realtime Commands Reference Manual.

� You could set the DOPT option to COMP, excluding non-competing execution states (and the transactions found in them) from the displays MDEX and PDEX generate. Since Wait For BMP is non-competing, this solves the problem. This solution has many advantages. The collector still gathers data about BMPs and you can look at it any time. You need not define any transaction groups. When a BMP is started, its transaction processing automatically becomes visible. (A very similar process goes on as messages accumulate for a transaction code with a normal priority of zero and a



non-zero limit priority. Until the threshold is reached, the transactions are non-competing, but as soon as enough messages have accumulated to increase the priority, all the messages start competing.)

�Transaction sampling (DOPT)� on page 36 describes the DOPT command and its options.

It is also important for you to limit the displays produced by MDEX and PDEX to executing execution states. What happens to an IMS system when the performance (throughput) of its MPPs degrades, perhaps due to excessive paging? If the arrival rate does not go down (as it would in a purely conversational environment), the message queues would start to build. When there are a large number of messages in the queue, all PDEX visibility into the real problem would be rounded down to zero. Wait For MPP would be 100%; all other states (including Wait For Page) would disappear. What can be done in this situation?

If you set the DOPT option to EXEC, MDEX and PDEX will ignore Wait For MPP (as well as all other message queue related execution states). The real problem, Wait For Page, is then obvious.

The concepts of competing and executing transaction execution states are significant, but it is a mistake to think that one can always ignore transactions that are not executing, or at least those that are non-competing. For example, if an MPP abends, it goes out of service and all the transactions queued for it become non-competing because they cannot be processed.

Should such transactions be excluded from the displays produced by Bottleneck Analysis? If the analyst knows about the abend, the answer is probably yes. There is no need to see those transactions; they might wash out performance problems with other transaction types. On the other hand, if the analyst does not know that the application has abended and is trying to use PDEX to find out why the users of the transactions are not being serviced, then the answer is certainly no.

If Bottleneck Analysis exception analysis is available, there is no problem. An exception message will inform the analyst of the application program going out of service, so the DOPT option can be set to COMP without fear of missing important information.

The concepts of competing, executing, and non-competing transactions are just as applicable to output messages on the queue as they are to transactions in the input queue. In the complex IMS, MVS, VTAM environment it is not always possible for Bottleneck Analysis to know which state is applicable, but the concepts always are.

A simple example is an IMS system which supports multiple terminals on a BSC line under BTAM. Output messages in the queue for an LTERM which is stopped are non-competing because IMS would not be able to send them even if they were the only work in the system.

Messages in the output queue which IMS cannot send now, because the line is busy with the output of another message, are competing but not executing. An output message which is actually undergoing output processing by the CLB which owns the line (its bytes might actually be going down the line, or perhaps the message is being prepared for transmission by MFS) is both competing and executing.



Execution state groupsThe MDEX and PDEX displays group the execution states. The first line of the display is a subtotal covering the entire group. The individual execution states comprising that subtotal follow, subject to the threshold specified via the MTHR minor for MDEX, or the threshold percentage via the THRS minor command for PDEX.

The subtotals by group are not enclosed in parentheses, while the numbers for the individual execution states are, to visually distinguish them. The execution state groups are as follows:

1. CPU Usage2. IMS Scheduling Waits3. Database I/O Waits4. MVS Waits5. IMS Waits6. Output Waits7. External Subsystem Waits

The following sections discuss these groups and the individual execution states which comprise them. To the right of each execution state name, there is a notation in parentheses which indicates whether this is an executing, a competing, or a non-competing execution state. Competing and non-competing states are mutually exclusive, while executing states are a proper subset of competing ones. For more information on these important concepts, see the discussion of these terms in �Bottleneck Analysis Execution States� on page 51.

CPU Usage


CPU Usage

IntroductionBottleneck analysis as a methodology focuses on CPU usage. Removing bottlenecks enables transactions to use more CPU per unit of time and, therefore, complete faster. The individual execution states in the CPU usage group describe how much CPU the transactions use and where (for example, in DL/I versus CPU used in the application program itself). All of these states are executing states�they are only experienced by transactions actually running in a dependent region.

Note: Because of their importance, Bottleneck Analysis always displays these execution states, even when you use a label field character to restrict the display to a certain class of execution groups as described in �Bottleneck Analysis Display Commands Format� on page 44.

You can use the Using CPU states to infer activity which Bottleneck Analysis cannot measure directly. For example, a shift away from Using CPU towards Database I/O, in the absence of increased I/O contention, indicates that the databases being accessed may require reorganization. An abrupt, massive increase in Using CPU across all transaction types is indicative of hardware CPU degradation. For example, the cache buffer or the TLB may have gone out of service and the message issued by the machine check handler may have gone unnoticed or may have been misunderstood.

Using CPU in APPL (Executing)The collector includes a transaction in the Using CPU in APPL state when it finds the application program processing the transaction is actually executing instructions on a CPU. The program had no DL/I function in progress, so the collector ascribes its use of the CPU to application processing. Note, however, that the collector counts CPU used by MVS components such as program fetch in this category.

In a normal IMS system, this number will be small, even tiny, compared to the other execution states. However, this is one of the most important statistics you can watch because:

� Almost every tuning trick increases this number (and decreases the total of the other execution states by the same amount). Indeed, a transaction executing 100% in this state is not degraded at all in the Bottleneck Analysis sense of the term unless it is looping.

� Almost every performance problem decreases this number (and increases the total of the other execution states by the same amount). For example, if I/O contention slows down an application�s access to a database, its execution profile will shift towards Database I/O and away from this execution state.

Using CPU in IMS (Executing)The collector found the application program processing the transaction actually executing instructions on a CPU. The program had a DL/I call in progress, so the collector ascribed


CPU Usage

its use of the CPU to IMS processing. An example of such processing is the CPU used by DL/I action modules to search a buffer pool for a record before issuing an I/O to retrieve it.

IMS Scheduling Waits



IntroductionWhen IMS schedules transactions, appropriate resources must be available, otherwise the transaction must wait. There are multiple points within scheduling where waiting can occur. Bottleneck Analysis shows the dynamic characteristics of transactions waiting during the scheduling process.

IMS transactions are serviced by application programs executing within message processing regions (MPPs) or message-driven batch-message processing regions (BMPs). Each region can service one transaction at a time. When more transactions arrive than the active regions can service, IMS holds them in the message queues until the regions complete current work, or until IMS activates additional regions.

IMS incurs overhead when it activates an application program within a message region. IMS applications can process multiple transactions each time they are scheduled. The PROCLIM parameter of the TRANSACT macro limits the number of transactions IMS services each time the application is activated.

You can customize IMS applications so that transactions are serviced by only one region, or by multiple regions in parallel. The MAXRGN parameter of the TRANSACT macro controls the number of parallel regions. If the number of transactions queued exceeds the PARLIM, IMS will allow another region to service them.

When a transaction is waiting for IMS to schedule it into a region, Bottleneck Analysis distinguishes between various states:

� Block loader� Block mover wait� DDIR Block Latch� PDIR Pool Latch� DMB pool� DMB Block Latch� Intent conflict� PDIR Block Latch� PDIR Pool Latch� PSB Block Latch� PSB pool� PSBW pool� Scheduling blocked� TM Allocate PSB Latch� TM Scheduling Latch� Unselectable� Wait for BMP� Wait for IFP� Wait for GU� Wait for MPP� Wait for reschedule

The following sections describe these states.



Block Loader (Executing)IMS cannot schedule a transaction into a dependent region until its PSB and all the DMBs it requires are loaded from ACBLIB. When the collector sees IMS routines working on scheduling a transaction in the process of loading the blocks from ACBLIB, it counts that transaction in this category.

For more information about this execution state, see the sections about the block mover, PSB pool, and DMB pool execution states.

Block Mover Wait (Executing)IMS cannot schedule a transaction into a dependent region until IMS loads its PSB and all the DMBs it requires from ACBLIB. IMS only allows one PST to load blocks at a time; any others which wish to load blocks are put on a queue. (This is reasonable because ACBLIB is on a single volume which can only have one I/O on it at a time. Serialization is also a result of the SMGT latch.) The transaction counted here had a PST attempting to schedule it which the collector found on that queue.

DDIR Block Latch (Executing)The collector found the transaction waiting for the DDIR block latch.

DDIR Pool Latch (Executing)The collector found the transaction waiting for the DDIR Pool latch.

DMB Block Latch (Executing)The collector found the transaction waiting for the DMB block latch.

DMB Pool (Competing)A transaction cannot be run in a dependent region until the DMBs for all of the databases it uses are in the DMB pool. For those DMBs which are not RESIDENT, IMS must find room for a copy in the pool before scheduling can complete. If space cannot be found, the PST trying to schedule the transaction IWAITs for it. The transaction counted here was found waiting for space in the DMB pool when a PST attempted to schedule it. As a result, the PST is not available for use by other transactions.

Note: Space is freed up in the DMB pool by deleting DMB blocks not currently in use. Before a DMB block can be deleted, all of the datasets it uses must be CLOSEd. The next time that DMB is needed it will have to be reloaded and its datasets re-OPENed. OPEN and CLOSE halt IMS processing and invoke MVS services, and are therefore considered highly undesirable.

Intent Conflict (Competing)The collector found the transaction waiting in the message queue. An MPP attempted to schedule it, but was unable to because the PSB associated with the transaction indicated an intent towards one of the databases it accesses which the PSB could not honor at the



moment (for example, PROCOPT=E when other scheduled PSBs are using the database). Intent conflicts also result from applications requesting parallel scheduling when load balancing is disabled at the transaction level.

PDIR Block Latch (Executing)The collector found the transaction waiting for the PDIR block latch.

PDIR Pool Latch (Executing)The collector found the transaction waiting for the PDIR Pool latch.

PSB Block Latch (Executing)The collector found the transaction waiting for the PSB block latch.

PSB Pool (Competing)The collector found the transaction waiting in the message queue. IMS cannot schedule a transaction into a dependent region until its PSB is in the PSB pool. If the PSB is not a RESIDENT one (or even if it is, if it is parallel-schedulable), IMS must find room for a copy of the PSB in the pool before scheduling can proceed. If IMS cannot find space, the scheduling attempt fails and the PST remains idle until an application terminates. Scheduling then proceeds according to the scheduled option for the failing transaction.

The transaction counted here was found waiting for space in the PSB pool when a PST attempted to schedule it. As a result, the PST is not available for use by other transactions.

PSBW Pool (Competing)The collector found the transaction waiting in the message queue. There was at least one message processing region available to service this transaction, but scheduling failed because there was not enough available space in the PSB work pool for this transaction to run.

The transaction needs space in the PSB work pool for such things as an I/O area, an area for segment search arguments (SSA), and a copy of the user parameter list.



Scheduling Blocked (Competing)The collector found the transaction waiting in the message queue. There was no reason (for example, PSB stopped) why IMS could not schedule the transaction. At least one MPP sensitive to the class of the transaction type attempted to schedule another transaction type but was halted for some reason (for example, intent conflict) and the scheduling options specified for that other transaction prevented IMS from giving up on it and possibly attempting to schedule this one. When a scheduling fails for intent, IMS does not attempt to schedule it again until another MPP stops. When IMS does attempt it again, the scheduling rules specified in the failing transaction apply.

TM Allocate PSB Latch (Executing)The collector found the transaction waiting for the TM allocate PSB latch.

TM Scheduling Latch (Executing)The collector found the transaction waiting for the TM scheduling latch.

Unschedulable (Non-Competing)The collector found the transaction in the message queue and determined that it could not currently be scheduled, even if there were no other transactions blocking it. IMS could not schedule the transaction for one of the following reasons:

� The transaction type was STOPped.

� The transaction type was USTOPped.

� The class of the transaction type was STOPped.

� The program (PSB) which processes the transaction type was STOPped.

� The program (PSB) which processes the transaction type was not found on ACBLIB.

� One or more databases required by the PSB which processes the transaction type were unavailable (STOPped, DMB not found, etc.).

� For transactions destined for an MPP, there were no MPPs running which were sensitive to the class of the transaction.

� For transactions destined for an MPP, the current scheduling priority was zero.

The collector may count both MPP and BMP transaction types in this state.



Wait for BMP (Non-Competing)The collector found the transaction waiting in the message queue and it was a transaction destined for a message-driven BMP region. There was no reason (for example, an unavailable database) why the BMP could not run at the moment, but it is not running. (The user submits a job to start BMPs; IMS does not automatically schedule BMP transactions like it schedules MPPs.)

Note that this is a non-competing state. It is a situation similar to a batch job that is TYPRUN=HOLD. There is nothing IMS or those trying to tune it can do to make such transactions run faster. They cannot run at all until the user chooses to submit the BMP job.

Wait for IFP (Competing)This is the number of transactions queued waiting to be serviced by a Fast Path application program which is executing in a Fast Path Message region. The application is currently servicing other transactions.

Wait for GU (Competing)This is the number of transactions queued, which will be serviced by the application executing in one or more regions. The Wait for GU value is the sum of the remaining PROCLIM counts of active regions which have currently scheduled that transaction, but does not exceed the number of queued transactions.

Wait for MPP (Competing)This is the number of transactions queued that will not be serviced by an active application for one of the following reasons:

� The application may not be active because message processing regions (MPPs) are currently servicing other transactions.

� The number of transactions queued exceeds the cumulative remaining PROCLIM values of the regions currently processing this transaction. The value of PARLIM does allow the application to be scheduled in another message processing region, if one is available.

If you start another MPP with the appropriate class, these transactions would be processed.

Wait for Reschedule (Competing)This is the number of transactions queued that will not be serviced by an active application for the following reason:

The number of transactions queued exceeds the cumulative remaining PROCLIM values of the regions currently processing this transaction. The value of PARLIM does not allow the application to be scheduled in another message processing region, even if one is available.

You must reschedule the application program before these transactions are processed.


Database I/O Waits

Database I/O Waits

IntroductionMany database DL/I requests can be satisfied from records already in a buffer pool. Others, however, require that IMS perform physical I/O. MDEX and PDEX show a subtotal for database I/O, and then if you specified that such statistics be kept by the collector, it shows the breakdown of the I/O by database. No further breakdown, such as by dataset group or individual dataset is available from Bottleneck Analysis.

The individual execution states within this category are the DMB names of each database to which a transaction did I/O.

A wait reason of INDEXPCB indicates I/O activity caused by secondary index maintenance. When maintenance is performed on a secondary index, IMS constructs a PCB to that index. Although you may not be processing in secondary sequence, I/Os to a secondary index may be caused by:

� designing your database such that the segment or fields used as the key in secondary sequence are updated heavily by other applications.

� changes to the primary database. Even if the application program is not using the secondary index, maintenance must be performed on the index, and a PCB constructed for it, when the primary database is changed.

Also, there is no way to tell from just this statistic which stages of I/O processing (for example, active on the UCB or waiting in the logical channel queue) the I/O operations for the databases were in. A tool such as Bottleneck Analysis can give you some view of this.

In addition to IMS/VS full function databases, physical I/O operations performed to data entry databases (DEDBs) will also be reported. If the statistics by database is requested, then the area name will be shown as the execution state.

DEDB updates are performed by output threads asynchronously after the transaction completes and the changes are logged. I/O operations performed by output threads are not a source of degradation for IMS/VS transactions and therefore they will not be reflected in the database I/O waits.

MVS Waits


MVS Waits

IntroductionIn the process of executing in a message processing region or a batch message processing region, a transaction may be blocked by contention for resources managed by MVS (as opposed to resources managed by IMS). An example of such a resource is the CPU. The individual execution states in this group show you when and where transactions get slowed down by resources managed by MVS.

Application I/O (Executing)The collector found the transaction scheduled into an MPP and saw that this MPP issued an I/O request which did not go through DL/I. The collector also noticed that the I/O was not of the type used by program fetch.

Usually, installation standards do not allow applications to do I/O of the type this section discusses. One reason to violate the standard is a debugging feature which uses an output file being left on when the program is put into production.

BLDL I/O (Executing)Once IMS schedules a transaction into a message processing region, its application program must be in virtual storage before it can begin to execute. If the application is not one which is PRELOADed, IMS must invoke MVS program fetch to bring it into virtual storage from PGMLIB.

The collector considers a transaction to be in this execution state if it observes PDS directory I/O done on behalf of a BLDL request. This occurs if IMS does not find the BLDL entry for the module to load in the MPP�s BLDL look-aside buffer, or if MVS refuses to use the one it finds because PGMLIB is authorized.

CPU Wait (CTL) (Executing)The collector found the transaction ready to run on a CPU within the IMS control region, but all online CPUs in the complex were running some other work. The CPUs might be running other IMS control region tasks, IMS dependent regions, or memories not related to IMS, such as TSO.

Note: The collector does not count itself in this analysis. If the only reason a transaction is not executing on a CPU is that the collector is executing, the collector counts the transaction as Using CPU. This is a standard sampling technique for measuring CPU usage by workload.

Also, the collector is unable to see CPU Wait that results from the execution of work with a higher dispatching priority than itself. For example, the collector cannot see CPU Waits resulting from disabled, global SRB, higher priority address spaces (such as *MASTER*), and local SRBs in the IMS CTL region. If there is much of this higher priority activity, it will skew the measurements. Some amount of CPU Wait�and perhaps even other states such as Database I/O Wait�will be seen as Using CPU.


MVS Waits

CPU Wait (DEP) (Executing)The collector found the transaction ready to run on a CPU within its dependent region, but all online CPUs in the complex were running some other MVS address space. The CPUs might be running the IMS control region, other dependent regions, or address spaces not related to IMS such as TSO.

Cross Memory Page (Executing)The collector found the transaction active inside an MPP. The IMS system was running with LSO=X. The application program processing the transaction had issued a DL/I call which was being processed by IMS modules running in the control region, but under the ASCB/TCB of the dependent region through the MVS Cross Memory Services. DL/I processing had suffered a page fault for a page in the control region�s private area.

In this situation, the dependent region�s execution is suspended while the page fault is resolved. Processing by the IMS control task is unaffected.

CSA Page (GFA) (Executing)The collector found the transaction active inside an MPP with its execution blocked for one of two reasons:

� The application program (or, more likely, some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the common service area (CSA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault it took in CSA, or waiting to use the CPU behind another ITASK which had serialized the CTL Task by taking a page fault in CSA.

In either case, the page fault occurred at a time when the available frame queue (AFQ) was empty, so the request for the resolution of the page fault had to be put on the general frame allocation (GFA) queue, and that is where the collector found it.

Refer to the discussion of GFA under �CTL Private Page (GFA) (Executing)� on page 66.

CSA Page (MSDB) (Executing)The collector found the transaction active inside an MPP or IFP region with its execution blocked. The application program was waiting for the resolution of a page fault for a page in the common service area (CSA) occupied by a pageable main storage database (MSDB).

� The application program (or, more likely, some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the common service area (CSA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault in CSA, or waiting to use the CPU behind another ITASK which had serialized the CTL task by taking a page fault in CSA.

MVS Waits


CTL EXT Priv Page (Executing)This execution state is the same as the CTL Private Page execution state, except that the private page MVS referenced is located in the control region�s extended private area, which is located above the 16 megabyte addressing line.

CTL Private Page (Executing)The collector found the transaction active inside an MPP. The application program processing the transaction was ISWITCHed to the IMS control region and was found waiting for one of the following reasons:

� Its ITASK suffered a page fault for a page in the private area of the control region�s address space.

� Its ITASK was ready to use the CPU, but it was waiting on the IMS dispatcher�s READY queue while the control task was serialized by a page fault taken in the private area by some other ITASK.

The reason why the IMS control region can stand so little paging is that when one ITASK page faults in the CTL region, all ITASKs running in the CTL region halt.

CTL Private Page (GFA) (Executing)The collector found the transaction active inside an MPP. The application program processing the transaction was ISWITCHed to the IMS control region and one of two things happened:

� Its ITASK had suffered a page fault for a page in the private area of the control region�s address space.

� Its ITASK was ready to use the CPU, but it was waiting on the IMS dispatcher�s READY queue while the control task was serialized by a page fault taken in the private area by some other ITASK.

In either case, the page fault occurred at a time when the Available Frame Queue (AFQ) was empty, so the request for the resolution of the page fault had to be put on a special Real Storage Manager (RSM) queue called the General Frame Allocation (GFA) queue while the System Resources Manager (SRM) went around stealing frames to replenish the AFQ.

GFA wait is not a major problem because SRM STEAL is not the only source of replenishment for the AFQ. Every time an address space is physically swapped out, the frames it occupied go on the AFQ. Also, when a FREEMAIN is issued, all frames backing the virtual storage released are made available.

DEP Private Page (Executing)The collector found the transaction active inside an MPP. The application program processing the transaction (or possibly some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page within its private area.


MVS Waits

DEP EXT Priv Page (Executing)This execution state is the same as the DEP Private Page execution state, except that the private page MVS referenced is located in the dependent region�s extended private area, above the 16 megabyte addressing line.

DEP Private Page (GFA) (Executing)The collector found the transaction active inside an MPP. The application program processing the transaction, or possibly some IMS module running as a subroutine of the application program, was waiting for the resolution of a page fault for a page within its private area. The request for resolution of the page fault was found on the general frame allocation (GFA) queue, indicating that it had occurred when RSM was out of frames (AFQ of 0).


ECSA Page (MSDB) (Executing)The collector found the transaction active inside an MPP or an IFP with its execution blocked. The application program was waiting for the resolution of a page fault for a page in the extended common service area (ECSA) occupied by a pageable main storage database (MSDB).

� The application program (or, more likely, some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the extended common service area (ECSA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault in extended CSA, or waiting to use the CPU behind another ITASK which had serialized the CTL task by taking a page fault in extended CSA.

ELPA Page (Executing)The collector found the transaction active inside an MPP with its execution blocked for one of two reasons:

� The application program (most likely compiler runtime routines copied to LPA or some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the extended pageable link pack area (EPLPA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault in extended LPA, or waiting to use the CPU behind another ITASK which had serialized the CTL task by taking a page fault in extended LPA.

MVS Waits


LPA Page (Executing)The collector found the transaction active inside an MPP with its execution blocked for one of two reasons:

� The application program (most likely compiler runtime routines copied to LPA or some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the pageable link pack area (PLPA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault in LPA, or waiting to use the CPU behind another ITASK which had serialized the CTL task by taking a page fault in LPA.

LPA Page (GFA) (Executing)The collector found the transaction active inside an MPP with its execution blocked for one of two reasons:

� The application program (or, more likely, some IMS module running as a subroutine of the application program) was waiting for the resolution of a page fault for a page in the pageable link pack area (PLPA).

� The application program processing the transaction had ISWITCHed to the IMS control region. While there, the collector found its ITASK waiting for the resolution of a page fault it took in LPA, or waiting to use the CPU behind another ITASK which had serialized the CTL task by taking a page fault in LPA.

In either case, the page fault occurred at a time when the available frame queue (AFQ) was empty, so the request for the resolution of the page fault had to be put on the general frame allocation (GFA) queue, and that is where the collector found it.


Program Fetch I/O (Executing)Once IMS has scheduled a transaction into a message processing region, its application program must be in virtual storage before it can begin to execute. If the application is not one which is PRELOADed, IMS must invoke MVS program fetch to bring it into virtual storage from PGMLIB.

The collector considers a transaction to be in this execution state if it observes I/O done by program control interrupt (PCI) fetch. If the module to be loaded is large, program fetch I/O can be very time-consuming.

Swapping In (Executing)The collector found the transaction active inside an MPP which was in the process of being swapped in by MVS. Normally, IMS makes all its dependent regions non-swappable, so some sort of installation modification must be suspected.


MVS Waits

X-MEM Page (GFA) (Executing)The collector found the transaction active inside an MPP. The IMS system was running with LSO=X or LSO=S. The application program processing the transaction had issued a DL/I call which was being processed by IMS modules running in the control region or DLISAS, but under the ASCB/TCB of the dependent region using MVS Cross Memory Services.

DL/I processing had suffered a page fault for a page in the control region�s private area. The collector found the request for resolution of the page fault on the GFA queue, indicating that it had occurred when the AFQ was empty. In this situation, the dependent region�s execution is suspended while the page fault is resolved. Processing by the IMS control task is unaffected.


IMS Waits


IMS Waits

IntroductionWhile executing in a message processing region or a batch message processing region, a transaction may be blocked by contention for resources managed by IMS (as opposed to resources managed by MVS). An example of such a resource is an IMS latch. The individual execution states in this group show you when and where transactions are slowed down by resources managed by IMS.

ACTL Latch (Executing)The collector found the application program running the transaction waiting for the ACTL (statistics logging) latch.

IMS uses the ACTL latch to serialize access to the DC Monitor log buffers and control blocks. When the DC Monitor is active, the control region and all parallel DL/I tasks compete for this latch.

ADSC Directory Latch (Executing)The collector found that the application program running the transaction was waiting for the ADSC directory latch.

The ADSC directory latch is used to serialize access to the ADSC directory. This is a wait built on top of the dynamic control block (CBTS) latch. The ADSC directory latch is obtained in the open and close data entry database (DEOB) modules, and Fast Path command processing modules.

AUTH Latch (Executing)The collector found the application program running the transaction waiting for the AUTH latch.

The AUTH latch is the authorized processing latch.

CBTS Latch (Executing)The collector found the application program running the transaction waiting for the CBTS latch. IMS uses the CBTS latch to serialize alterations to dynamic control block chains (IPAGES) within dynamic storage management.

Conversation Checkpoint Latch (Executing)The collector found the transaction waiting for the Conversation Checkpoint Latch.

DB System Checkpoint Latch (Executing)The collector found the transaction waiting for the DB System Checkpoint Latch.


IMS Waits

DBBP Latch (Executing)The collector found the application program running the transaction waiting for the DBBP latch. The DBBP latch serializes accesses to database buffers, and their associated control blocks.

DC System Checkpoint Latch (Executing)The collector found the transaction waiting for the DC System Checkpoint Latch.

DC Terminal Latch (Executing)The collector found the transaction waiting for the DC Terminal Latch.

DC User Latch (Executing)The collector found the transaction or thread waiting for the DC User Latch.

DEDB Area Lock (Executing)The collector found that the application program running the transaction was waiting for the DEDB area lock.

The DEDB area lock serializes updates to a DEDB area dataset. There is a different lock for each area. The DEDB area lock is obtained in sync point processing.

A DEDB area lock is always taken before the DMAC latch to avoid the possibility of a deadlock.

DEDB Segment (Executing)The collector found that the application program running the transaction was waiting to obtain control of a resource in a data entry database (DEDB). The resource under control is a unit of work (UOW), and it is represented by an XCRB control block.

DMAC Latch (Executing)The collector found that the application program running the transaction was waiting for the DMAC latch.

The DMAC latch is used to serialize updates to DEDB area datasets. Sync point processing modules require the DMAC latch. Updates are recorded in the log records. The physical update of the DEDB area does not take place until the updates are written to the IMS log.

IMS Waits


DMAC Share Latch (Executing)The collector found that the application program running the transaction was waiting for the DMAC share latch.

The DMAC share latch is used to serialize access to DMAC control blocks. Open and close area dataset processing modules require the DMAC share latch in exclusive mode.

When a Fast Path message processing region is terminating, diagnostic information is copied form the control region to the dependent region. This function requires the DMAC share latch in share mode. Waits only occur for this function because there can be only one requestor of the DMAC share latch in exclusive mode at one time, and these modules are serialized by the ADSC latch.

DMBE Latch (Executing)The collector found the application program running the transaction waiting for the DMBE latch. The DMBE latch is used to serialize the dynamic insertion and removal of control blocks associated with databases (DMBs).

Fast Path Buffer (Executing)The collector found that the application program running the transaction was waiting for a Fast Path buffer. Buffer allocation for an IMS Fast Path Region (IFP) is under the maximum number of allowable buffers specified by the normal buffer allocation (NBA) execution parameter.

Fast Path IWAIT in Term (Executing)The collector found that the Fast Path application program processing the transaction was IWAITing while the application program was terminating.

Fast Path Other Abend (Executing)The collector found that the Fast Path application program processing the transaction was IWAITing and that the application program was terminating due to an abend or cancelled dependent region.

Fast Path Overflow Buffer Allocation (Executing)The collector found the application program running the transaction waiting for a Fast Path overflow buffer. The IFP has reached the maximum number of buffers allowed (as specified by the NBA execution parameter), and overflow processing is in progress. Overflow processing increased the buffer allocation by the amount allowed for overflow (OBA).


IMS Waits

Fast Path Overflow Buffer Lock (Executing)The collector found that the application program running the transaction was waiting for the Fast Path overflow buffer lock.

If an IFP attempts to allocate buffers beyond the normal number of buffers allowed (NBA), overflow processing takes place. Overflow processing attempts to increase the buffer allocation by the amount allowed for overflow (OBA). The overflow lock is required to allocate more buffers than the number specified by normal buffer allocation. The overflow lock is enqueued by IMS Fast Path (IFP) and held until sync point processing, at which time the buffer allocation is returned to normal.

Fast Path Pseudo Abend (Executing)The collector found that the Fast Path application program processing the transaction was IWAITing while the transaction processing in the message region was pseudo abended.

Fast Path Resource Latch (Executing)The collector found that the application program running the transaction was waiting for the Fast Path resource latch.

The Fast Path Resource latch serializes access to the exclusive control resource blocks (XCRBs). XCRBs represent the status of a currently owned (possibly exclusively controlled) resource within a DEDB area.

Fast Path Syncpoint Processing (Executing)The collector found the transaction in sync point processing. During this state, the dependent region is using CPU; however, the amount of time spent in this state should be small.

Fast Path Sync Lock (Executing)The collector found the application program running the transactions waiting for the Fast Path sync lock.

The Fast Path sync lock serializes the sync point processing in IFPs with check-point processing and other activities which stop a DEDB area, such as after you issue a /STOP AREA, /STOP ADS, or /DBR AREA command, or if a physical I/O error is detected.

The sync point processing function requests the Fast Path sync lock in share mode; all other activities require the lock to be held in exclusive mode.

FNCB Latch (Executing)The collector found that the application program running the transaction was waiting for the FNCB latch.

The FNCB latch serializes access to the notify control block chain. The notify facility is used for communication by various functions like open or close a DEDB, and IMS commands.

IMS Waits


GCMD Latch (Executing)The collector found the application program running the transaction waiting for the GCMD latch.

The GCMD latch is the global command latch.

GEN1 Latch (Executing)The collector found the application program running the transaction waiting for a generic latch.

The generic latch is a class of latches which currently consists of the DMBE (data management block) and DBBP (database buffer pool) latches. The latches are generic in that there is one DMBE latch for each DMB defined to the IMS system, and one DBBP latch for each subpool used by the ISAM/OSAM buffer handler.

HDSM Latch (Executing)The collector found the application program running the transaction waiting for the HDSM latch. The HDSM latch serializes processing of DL/I HD space management operations.

IRLM Conflict Wait (Executing)The collector found the application program executing inside a dependent region. The dependent region issued a request to the IRLM address space and was waiting for a response.

This wait reason can appear when there is a database conflict or when IRLM is waiting for internal IRLM processing.

ISWITCHed to CTL (Executing)The collector found the application program running the transaction to have executed an ISWITCH macro. The PST (Partition Specification Table) is still executing, but in the control region instead of in the dependent region.

This wait reason occurs whenever a PST needs the services of the control region. When this happens, the PST gets ISWITCHed to CTL and waits to request the service it needs from the control region TCB. The wait is longer if the TCB itself is waiting for control of the CPU (for example, if the control region has a high paging rate).

There are conditions under which this occurs. These include, but are not limited to:

� I/O to ISAM files

� obtaining input messages (including IMS message queue I/O if it is required)

� ISRTing output messages (including IMS message queue I/O if it is required)

� EOV processing on all database datasets (when such is required to free up a buffer)

� users issuing large numbers of IMS commands

� servicing Fast Path Wait For Input (WFI) GU calls


IMS Waits

� completing sync-point processing

ISWITCHed to Fast Path TCB (Executing)The collector found the application program running the transaction to have executed an ISWITCH macro. The PST is still executing, but in the control region under the Fast Path TCB.

ISWITCHed to LSO (Executing)The collector found the application program running the transaction to have executed an ISWITCH macro. The PST is still executing, but in the control region instead of in the dependent region. The ISWITCH was done using the Local Storage Option (LSO). Instead of running in the control task, the PST is:

� for LSO=Y, running under a subtask in the control region that is reserved for its use only. LSO=Y costs a substantial amount of CPU, but saves virtual storage in CSA at the cost of virtual storage in the private area of the IMS control region.

� for LSO=X, running under the ASCB/TCB of the dependent region, but in the virtual storage associated with the control region. This is done for the same reason as LSO=Y, but costs less CPU because of the greater efficiency of MVS Cross Memory Services over the old WAIT/POST logic.

IWAIT in IMS Dispatcher (Executing)IWAIT in IMS dispatcher is a measure of the IMS dispatching queue for dependent region activities. The collector found the application program processing the transaction IWAITing in the IMS dispatcher and could not ascribe the condition to any of the DL/I oriented states listed above.

As the workload rises, this value also rises. This number should be small. If it is not, please inform IBM Software Support.

IWAIT in Term (Executing)The collector found the application program processing the transaction IWAITing. It also found an indication that the application program was terminating. The collector could not attribute the status of the transaction to any of the states listed above.

Note: This execution state should be small. If it is not, please inform IBM Software Support. Termination IWAITs may be attributed to sync point processing of an update transaction.

LGMSG I/O (Executing)The collector found the transaction waiting for I/O on the long message (LGMSG) dataset.

IMS Waits


LOGL Latch (Executing)The collector found the application program running the transaction waiting for the LOGL latch. A latch is the IMS version of an MVS suspend lock; it is a fast, cheap way of serializing access to some resource which cannot be used by more than one transaction at a time.

The IMS logical logger uses the LOGL latch to serialize access to the buffers which the physical logger writes out to the online log dataset (OLDS). If the physical logger gets behind, ITASKs queue on this latch.

LQB Pool Latch (Executing)The collector found the transaction waiting for the LQB Pool Latch.

LU 6.2 Manager Latch (Executing)The collector found the transaction waiting for the LU 6.2 Manager (LUM) Latch.

MFS Load (Executing)The collector found an I/O in progress against the message format services (MFS) dataset. This means an MFS format block was being loaded so that an input or output message could be formatted by MFS.

MSDB Latch (Executing)The collector found that the application program running the transaction was waiting for the main storage database (MSDB) latch.

Whenever an MSDB call or sync processing routine needs to get or release control of an MSDB resource, the MSDB latch must be obtained.

MSDB Segment (Executing)The collector found that the application program running the transaction was waiting to obtain control of a resource in a main storage database (MSDB). The resource under control is an MSDB segment.

NQDQ Latch (Executing)The collector found the application program running the transaction waiting for the NQDQ latch. The NQDQ latch serializes ENQ/DEQ activity.

OBFM Latch (Executing)The collector found the application program running the transaction waiting for the OBFM latch. The OBFM latch serializes accesses to OSAM buffers, and their associated control information.


IMS Waits

Open/Close Latch (Executing)The collector found that the application program running the transaction was waiting for the open/close latch.

The open/close latch serializes resources to Fast Path databases.

OSAM Buffer WaitThe collector found a DL/I address space.

Other Abend (Executing)The collector found the application program processing the transaction IWAITing. It also found an indication that the application program was terminating due to an abend or because the dependent region was cancelled.

Other DL/I IWAIT (Executing)The collector found the application program processing the transaction in DL/I, but it could not attribute the condition to any of the DL/I oriented states listed above.

Currently PSTs waiting for space in both the ISAM/OSAM and VSAM pools will have the transactions they are processing counted in this category.

Note: This execution state should be small. If it is not, please inform IBM Software Support.

Other Latch (Executing)The collector found the application program running the transaction in ISERWAIT (latch wait), but not waiting for any of the latches described above.

Other Wait (Executing)The collector found a transaction waiting, but could not ascribe its execution state to any of the categories documented above.

If this execution state appears large, please report it to IBM Software Support.

PI Wait (Executing)The collector found the application program processing the transaction IWAITing for a program isolation (PI) resource. Program isolation is the mechanism which allows databases to be simultaneously accessed and even updated by different users.

A PI resource is essentially a DMB number to identify the physical database, and an RBA (relative byte address) to identify the physical block being held. When two programs attempt to access the same PI resource at the same time, one must wait.

IMS Waits


Pseudo Abend (Executing)The collector found that the application program processing the transaction was IWAITing and terminating due to a pseudo abend.

QBLKS I/O (Executing)The collector found the transaction waiting for I/O to complete to the queue blocks dataset.

QBUF Latch (Executing)The collector found the application program running the transaction waiting for the QBUF latch. The QBUF latch serializes accesses to message queue buffers, and their associated control information.

Queue Manager Latch (Executing)The collector found the transaction waiting for the Queue Manager Latch.

SHMSG I/O (Executing)The collector found the transaction waiting for I/O on the short message (SHMSG) dataset.

SMB Queue Latch (Executing)The collector found the transaction waiting for the SMB Queue Latch.

SMGT Latch (Executing)The collector found the application program running the transaction waiting for the SMGT (storage management) latch.

The IMS storage management module (DFSISMN0) uses this latch to serialize access to various control blocks and buffers, such as the message queue, CIOP, CWAP, DMB, and PSB pools.

SNDQ Latch (Executing)The collector found the application program running the transaction waiting for the scheduling management blocks (SMB) enqueue/dequeue latch. IMS uses the SNDQ latch to serialize the dynamic insertion and removal of SMBs.

SPA I/O (Executing)The collector found the transaction waiting for I/O against the scratch pad area (SPA) dataset. This dataset is used by conversational transactions which use DASD SPA.


IMS Waits

Sync Point Wait (Executing)The collector found the transaction waiting for I/O to complete as the result of synchronization (SYNC) point processing.

TCT Block Latch (Executing)The collector found the transaction waiting for the TCT Block Latch.

TM Subqueue Latch (Executing)The collector found the transaction waiting for the TM Subqueue Latch.

VBFM Latch (Executing)The collector found the application program running the transaction waiting for the VBFM latch. The VBFM latch serializes accesses to VSAM buffers, and their associated control information.

VTCB Pool Latch (Executing)The collector found the transaction waiting for the VTCB Pool Latch.

Wait HSSP PVT Pool (Executing)The collector found the application program executing inside a dependent HSSP BMP region. The application program is waiting for space in the HSSP private pool.

XCNQ Latch (Executing)The collector found the application program running the transaction waiting for the XCNQ latch.

Program isolation uses the XCNQ latch to serialize access to the PI ENQ/DEQ queues and control blocks.

Output Waits


Output Waits

IntroductionWhen outbound processing of a message is delayed because IMS is waiting for an output-related service or resource, Bottleneck Analysis detects an output wait.

Message on Fast Path Output Queue (Non-competing)The collector found that an output message generated by the transaction in the output queue was waiting to be dequeued. The Fast Path output router, which executes as an IMS task in the control region, dequeues Fast Path output messages.

Message on Non-Fast Path Output Queue (Non-competing)The collector found that an output message generated by a transaction in the non-fast path output queue was waiting to be dequeued.


External Subsystem Waits


IntroductionExternal subsystem waits are those in which the collector finds a dependent region waiting for a reply from an external subsystem (for example, DB2®).

Create Thread Wait (Executing)The collector found the dependent region in the process of creating a thread.

A thread is the DB2 structure that describes an application�s connection between DB2 and IMS regions. When create thread is in progress, DB2 is allocating an application plan to process the SQL CALL. The creation of a DB2 thread may consume considerable resources. Associated with create thread processing can be plan load, authorization checking, database open, and lock authorization. An application plan defines the DB2 resources being accessed from an application program.

SQL Call Wait (Executing)The collector found the application program in the process of executing an SQL call. An IMS application program issues SQL calls to request service from DB2.

Terminate Thread Wait (Executing)The collector found the dependent region in the process of terminating a thread.

When the sync point is completed, the thread will be terminated and the plan used by the SQL CALL will be unallocated unless the region is a WFI. DB2 database close may also occur at terminate thread.



Command Summary 83

Command Summary

Appendix overviewThis appendix summaries the Bottleneck Analysis commands.

Appendix contentsBottleneck Analysis Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Transaction Group Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86DBCTL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

A

Bottleneck Analysis Commands



IntroductionThe following sections list each bottleneck analysis command.

Major Command

Minor Commands of IDEG

IDEG Controls execution of Bottleneck Analysis. A hyphen (-) in column 1 attaches the Bottleneck Analysis collector.

ABCD Data collector ABEND completion code.

BEGN Begins Bottleneck Analysis data collector.

BMPX Displays current setting of BMP switch.

BMPXON Data collector ignores BMP activity.

BMPXOFF Data collector does not ignore BMP activity.

CLRL Specifies long-term clearing interval (minutes).

CLRS Specifies short-term clearing interval (minutes).

DBSW Displays current setting of database I/O switch.

DBSWON Collects and displays database I/O values by individual database name.

DBSWOFF Collects and displays total database I/O values only.

DOPT Displays information on competing, executing, or total (all) transactions.

DTCH Detaches collector subtask.

END Stops data collector.

*MDEX Displays bottleneck analysis results by count (group nn).

MTHR Specifies display threshold for MDEX.

*PDEX Displays bottleneck analysis results by percentage (group nn).

RESM Resumes collector.

SCAL Specifies scaling factor for MDEX.

STIM Sets collection interval (tenths of a second).

SUSP Suspends collector.

THRS Suppresses execution states that occur less than nn percent of the time on PDEX display.

Command Summary 85


To limit the MDEX and PDEX displays to a specific execution state group, enter one of the following arguments in the label field (column 1):

blank All execution state analyses

D DB I/O waits

I IMS waits

M MVS waits

S Scheduler waits

O Output waits

E External subsystem waits

Transaction Group Commands


Transaction Group Commands

IntroductionThe following table lists the transaction group commands.

GLBLcc Displays or changes current suffix of KOIGBLcc module; entering cc causes new module to be loaded.

MAXGnn Dynamically controls the number of transaction groups for IMS, or PSB groups for DBCTL, that OMEGAMON II supports.

aSETGnn ccc Displays or changes contents of a transaction, logical terminal, or node group. In this command, nn is the group number (enter 99 for all groups); ccc is the entry specification (PSB=xxx, TRAN=xxx, TERM=nnn, NODE=xxx, or CLASS=nnn); a is the function to be invoked. The functions are:

blank Lists the contents of group.

A Adds an entry to group definition.

C Creates a group.

D Deletes an entry from group.

L Lists the contents of group (default).

X Deletes all group contents.

Command Summary 87

DBCTL Environment

DBCTL Environment

IntroductionThe following commands are not applicable in a DBCTL environment:

� DOPT ccccc� AUTO � TRAN=, TERM=, CLASS= entry specifications of SETG

The following execution state groups are not applicable in a DBCTL environment:

� IMS scheduling waits� output waits� external subsystem waits

DBCTL Environment


Support Information 89

Support Information

If you have a problem with your IBM software, you want to resolve it quickly. This section describes the following options for obtaining support for IBM software products:

� �Searching knowledge bases� on page 89

� �Obtaining fixes� on page 90

� �Receiving weekly support updates� on page 90

� �Contacting IBM Software Support� on page 91

Searching knowledge basesYou can search the available knowledge bases to determine whether your problem was already encountered and is already documented.

Searching the information center

IBM provides extensive documentation that can be installed on your local computer or on an intranet server. You can use the search function of this information center to query conceptual information, instructions for completing tasks, and reference information.

Searching the Internet

If you cannot find an answer to your question in the information center, search the Internet for the latest, most complete information that might help you resolve your problem.

To search multiple Internet resources for your product, use the Web search topic in your information center. In the navigation frame, click Troubleshooting and support > Searching knowledge bases and select Web search. From this topic, you can search a variety of resources, including the following:

� IBM technotes

� IBM downloads

� IBM Redbooks®

� IBM developerWorks®

� Forums and newsgroups

� Google

B


Obtaining fixesA product fix might be available to resolve your problem. To determine what fixes are available for your IBM software product, follow these steps:

1. Go to the IBM Software Support Web site at (http://www.ibm.com/software/support).

2. Click Downloads and drivers in the Support topics section.

3. Select the Software category.

4. Select a product in the Sub-category list.

5. In the Find downloads and drivers by product section, select one software category from the Category list.

6. Select one product from the Sub-category list.

7. Type more search terms in the Search within results if you want to refine your search.

8. Click Search.

9. From the list of downloads returned by your search, click the name of a fix to read the description of the fix and to optionally download the fix.For more information about the types of fixes that are available, refer to the IBM Software Support Handbook at http://techsupport.services.ibm.com/guides/handbook.html.

Receiving weekly support updatesTo receive weekly e-mail notifications about fixes and other software support news, follow these steps:

1. Go to the IBM Software Support Web site at http:/www.ibm.com/software/support.

2. Click My Support in the upper right corner of the page.

3. If you have already registered for My Support, sign in and skip to the next step. If you have not registered, click register now. Complete the registration form using your e-mail address as your IBM ID and click Submit.

4. Click Edit Profile.

5. In the Products list, select Software. A second list is displayed.

6. In the second list, select a product segment, for example, Application servers. A third list is displayed.

7. In the third list, select a product sub-segment, for example, Distributed Application & Web Servers. A list of applicable products is displayed.

8. Select the products for which you want to receive updates, for example, IBM HTTP Server and WebSphere Application Server.

9. Click Add products.

10. After selecting all products that are of interest to you, click Subscribe to email on the Edit profile tab.

11. Select Please send these documents by weekly email.

http://www.ibm.com/software/support

http://techsupport.services.ibm.com/guides/handbook.html

http://techsupport.services.ibm.com/guides/handbook.html


12. Update your e-mail address as needed.

13. In the Documents list, select Software.

14. Select the types of documents that you want to receive information about.

15. Click Update. If you experience problems with the My support feature, you can obtain help in one of the following ways:

Online: Send an e-mail message to [email protected], describing your problem.

By phone: Call 1-800-IBM-4You (1-800-426-4968).

Contacting IBM Software SupportIBM Software Support provides assistance with product defects.

Before contacting IBM Software Support, your company must have an active IBM software maintenance contract, and you must be authorized to submit problems to IBM. The type of software maintenance contract that you need depends on the type of product you have:

� For IBM distributed software products (including, but not limited to, Tivoli, Lotus®, and Rational® products, as well as DB2® and WebSphere® products that run on Windows or UNIX operating systems), enroll in Passport Advantage® in one of the following ways:

� Online: Go to the Passport Advantage Web page (http://www.lotus.com/services/passport.nsf/WebDocs/ Passport_Advantage_Home) and click How to Enroll

� By phone: For the phone number to call in your country, go to the IBM Software Support Web site at http://techsupport.services.ibm.com/guides/contacts.html and click the name of your geographic region.

� For customers with Subscription and Support (S & S) contracts, go to the Software Service Request Web site at https://techsupport.services.ibm.com/ssr/login.

� For customers with IBMLink�, CATIA, Linux�, S/390®, iSeries�, pSeries®, zSeries®, and other support agreements, go to the Support Line Web site at http://www.ibm.com/services/us/index.wss/so/its/a1000030/dt006.

� For IBM eServer� software products (including, but not limited to, DB2 and WebSphere products that run in zSeries, pSeries, and iSeries environments), you can purchase a software maintenance agreement by working directly with an IBM sales representative or an IBM Business Partner. For more information about support for eServer software products, go to the IBM Technical Support Advantage Web site at http://www.ibm.com/servers/eserver/techsupport.html.

If you are not sure what type of software maintenance contract you need, call 1-800-IBMSERV (1-800-426-7378) in the United States. From other countries, go to the contacts page of the IBM Software Support Handbook on the Web at

http://techsupport.services.ibm.com/guides/contacts.html

http://www.lotus.com/services/passport.nsf/WebDocs/ Passport_Advantage_Home

http://www.lotus.com/services/passport.nsf/WebDocs/ Passport_Advantage_Home

http://www.ibm.com/servers/eserver/techsupport.html


http://www.ibm.com/servers/eserver/techsupport.html


http://techsupport.services.ibm.com/guides/contacts.html and click the name of your geographic region for phone numbers of people who provide support for your location.

To contact IBM Software Support, follow these steps:

1. �Determining the business impact� on page 922. �Describing problems and gathering information� on page 923. �Submitting problems� on page 93

Determining the business impactWhen you report a problem to IBM, you are asked to supply a severity level. Therefore, you need to understand and assess the business impact of the problem that you are reporting. Use the following criteria:

Describing problems and gathering informationWhen explaining a problem to IBM, be as specific as possible. Include all relevant background information so that IBM Software Support specialists can help you solve the problem efficiently. To save time, know the answers to these questions:

� What software versions were you running when the problem occurred?

� Do you have logs, traces, and messages that are related to the problem symptoms? IBM Software Support is likely to ask for this information.

� Can you re-create the problem? If so, what steps were performed to re-create the problem?

� Did you make any changes to the system? For example, did you make changes to the hardware, operating system, networking software, and so on.

� Are you currently using a workaround for the problem? If so, be prepared to explain the workaround when you report the problem.

� What software versions were you running when the problem occurred?

Severity 1 The problem has a critical business impact. You are unable to use the program, resulting in a critical impact on operations. This condition requires an immediate solution.

Severity 2 The problem has a significant business impact. The program is usable, but it is severely limited.

Severity 3 The problem has some business impact. The program is usable, but less significant features (not critical to operations) are unavailable.

Severity 4 The problem has minimal business impact. The problem causes little impact on operations, or a reasonable circumvention to the problem was implemented.



Submitting problemsYou can submit your problem to IBM Software Support in one of two ways:

� Online: Click Submit and track problems on the IBM Software Support site at http://www.ibm.com/software/support/probsub.html. Type your information into the appropriate problem submission form.

� By phone: For the phone number to call in your country, go to the contacts page of the IBM Software Support Handbook (http://techsupport.services.ibm.com/guides/contacts.html) and click the name of your geographic region.

If the problem you submit is for a software defect or for missing or inaccurate documentation, IBM Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the problem in detail. Whenever possible, IBM Software Support provides a workaround that you can implement until the APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the Software Support Web site daily, so that other users who experience the same problem can benefit from the same resolution.




Notices 95

Notices

OverviewThis information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in

C


new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject to change before the products described become available.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any

Notices 97

similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM�s application programming interfaces.

Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights reserved.

If you are viewing this information in softcopy form, the photographs and color illustrations might not display.

TrademarksIBM, the IBM logo, AIX, DB2, developerWorks, eServer, IBMLink, Informix, iSeries, Lotus, Passport Advantage, pSeries, Rational, Redbooks, S/390, Tivoli, the Tivoli logo, Tivoli Enterprise Console, TME, WebSphere, and zSeries are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, Celeron, Intel Centrino, Intel Xeon, Itanium, Pentium and Pentium III Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.


Other company, product, and service names may be trademarks or service marks of others.

Index 99

Index

Symbols*MDEX minor 84*PDEX minor 84/DBR AREA 73/STOP ADS 73/STOP AREA 73

AABCD 41ABCD minor 84abend

other 77termination due to 72

ACTL latch 70ADSC directory latch 70AFQ 66APPL

using CPU in 56application I/O 64aSETGnn 86at 81attaching the collector 26–28

at an MVS console 28from OMEGAMON II 26when OMEGAMON II initializes 27

AUTH latch 70Available Frame queue 66average transaction counts

statistics 50

Bbatch processing regions

ignoring 32, 33begin data collection 30BEGN 35BEGN minor 30, 84BLDL I/O 64block loader 59block mover wait 59BMP

transaction sampling (BMPX) 32, 48transaction sampling (NMSX) 33transaction type 61

BMPX 48BMPX minor 84from menu interface 33minor 33

BMPX? 32BMPXOFF 32BMPXOFF minor 84BMPXON 32BMPXON minor 84books

see publications 10, 13Bottleneck 84bottleneck analysis

bytes required 35commands summary 84description 10invoking 29menu 19methodology 56

buckets (virtual storage area) 24

CCBTS latch 70clear interval

long-term 34short-term 34

clearing counters 34–35CLRL 34CLRL minor 84CLRL05 and CLRL

commands output 34CLRS 35CLRS minor 84CLRS? 35CLRSnn and CLRS

command output 35collection, data

beginning 30collector 24–41

abend 41attaching from OMEGAMON II 26controlling 29detaching 31, 32

D


leave system command 30options, specifying 38restart 35starting 27, 30

collector abend display (ABCD) 41collector operation 24–25command argument field 45command label field 45commands

major 84minor 84transaction group 86

COMP 37competing transactions

description 52controlling

collector 29database sampling 35

conversation checkpoint latch 70counters

clearing 35counters (virtual storage area) 24CPU usage 56CPU wait (CTL) 64CPU wait (DEP) 65create thread 81Cross Memory Page 65CSA page (GFA) 65CTL EXT priv page 66CTL private page 66customer support

see Software Support 91

Ddata collection

starting 27, 30database I/O waits

execution states group 63database sampling

changing 35, 36option 36

database sampling (DBSW) 35DB system checkpoint latch 70DBCTL commands 87DBCTL environments 21, 49, 87DBSW 36, 48DBSW minor 35, 84DBSW? 36DBSWOFF 35

DBSWOFF minor 84DBSWON 35DBSWON minor 84DDIR block latch 59DDIR pool latch 59DEDB updates 63DEP EXT priv page 67DEP private page 66detaching the collector 31, 32detaching the collector (DTCH) 31display

limiting 45display commands format 44display size

reducing 39display threshold for MDEX command (MTHR) 39display threshold for PDEX command (THRS) 40displays

factors influencing 48limiting 54

displays (MDEX/PDEX) 44–50DL/I IWAIT

large 77DMAC control blocks

serializing access to 72DMAC latch 71DMB block latch 58DMB pool 58

how space is freed up 59DMBE latch 72documentation conventions 15DOPT 54DOPT minor 36, 47, 48, 53, 84

command format 37default in KOIGBLmp 37

DTCHfrom menu interface 31minor 31

DTCH minor 31, 84

EECSA page 67END 25, 30, 35END minor 84Ending Data Collection (END) 30EPLPA 67exclusive control resource blocks 73EXEC 54executing transactions

Index 101

E

description 52executing transactions screen 20execution states 44, 51, 75

ACTL latch (executing) 70ADSC directory latch (executing) 70application I/O (executing) 64AUTH latch (executing) 70BLDL I/O (executing) 64block loader (executing) 59block mover wait (executing) 59CBTS latch (executing) 70class 48CPU usage group 55CPU wait (CTL) (executing) 64CPU wait (DEP) (executing) 65create thread wait (executing) 81cross memory page (executing) 65CSA page (GFA) (executing) 65CSA page (MSDB) (executing) 65CTL EXT priv page (executing) 66CTL private page (executing) 66CTL private page (GFA) (executing) 66database I/O operations 63database I/O waits group 55DBBP latch (executing) 71DEDB area lock (executing) 71DEDB segment (executing) 71DEP EXT priv page (executing) 67DEP private page (executing) 66DEP private page (GFA) (executing) 67DMAC latch (executing) 71DMAC share latch (executing) 72DMB pool (competing) 59DMBE latch (executing) 72ECSA page (MSDB) (executing) 67ELPA page (executing) 67external subsystem waits group 55fast path buffer (executing) 72fast path IWAIT in term (executing) 72fast path other abend (executing) 72fast path overflow buffer allocation (executing) 72fast path overflow buffer lock (executing) 73fast path pseudo abend (executing) 73fast path resource latch (executing) 73fast path sync lock (executing) 73fast path syncpoint processing (executing) 73FNCB latch (executing) 73GCMD latch (executing) 74

GEN1 latch (executing) 74HDSM latch (executing) 74IMS scheduling waits group 55IMS waits group 55intent conflict (competing) 59intent conflict (executing) 59, 60, 61, 70, 71, 76,

78, 79IRLM conflict wait (executing) 74ISWITCHED to CTL (executing) 74ISWITCHED to fast path TCB (executing) 75ISWITCHed to LSO (executing) 75IWAIT in IMS dispatcher (executing) 75LGMSG I/O (executing) 75LOGL latch (executing) 76LPA page (executing) 68LPA page (GFA) (executing) 68message on fast path output queue (non-

competing) 80message on non-fast path output queue (non-

competing) 80MFS load (executing) 76MSDB latch (executing) 76MSDB segment (executing) 76MVS waits group 55NQDQ latch (executing) 76OBFM latch (executing) 76open/close latch (executing) 77osam buffer wait (executing) 77other abend (executing) 77other DL/I IWAIT (executing) 77other latch (executing) 77other wait (executing) 77output waits group 55PI wait (executing) 77program fetch I/O (executing) 68PSB pool (competing) 60PSBW pool (competing) 60pseudo abend (executing) 78QBLKS I/O (executing) 78QBUF latch (executing) 78scheduling blocked (competing) 61SHMSG I/O (executing) 78SMGT latch (executing) 78SNDQ latch (executing) 78SPA I/O (executing) 78SQL call wait (executing) 81swapping in (executing) 68sync point wait (executing) 79

F


terminate thread wait (executing) 81unschedulable (non-competing) 61using CPU in APPL (executing) 56using CPU in IMS (executing) 56VBFM latch (executing) 79wait for BMP (non-competing) 62wait for GU (competing) 62wait for IFP (competing) 62wait for MPP (competing) 62wait for reschedule (competing) 62wait HSSP PVT pool (executing) 79XCNQ latch (executing) 79X-MEM page (GFA) (executing) 69

execution states groupCPU usage 56

external subsystem waitsexecution state group 81

Ffast path

application IWAITing 72, 73application waiting for buffer 72output router 80overflow buffer allocation 72overflow buffer lock 73resource latch 73sync lock 73TCB 75

fast path pseudo abend 73frame allocation 66, 67, 68FREEMAIN

making frames available 66

GGFA queue 66GLBL major 86GLOBAL= parameter 27GRA queue 67GRP= keyword 45, 48

Hhardware CPU degradation

indication of 56HSSP private pool

application waiting for space 79

IIDEG 35

=BEGN keyword 27

from menu interface 26major 26, 29, 31with START Bottleneck Analysis deleted 27

IDEG and BEGNcommands output 30

IDEG and ENDcommands output 30

IDEG major 26, 84IDEG minors 84IMS resource contentions 70IMS scheduling waits

execution states group 58IMS waits

execution states group 70information centers, searching to find software

problem resolution 89installation standard

violated 64intent conflict 61invoke bottleneck analysis 29invoking

bottleneck analysis 29collector 24

invoking Bottleneck Analysis 19IRLM

waiting 74ISERWAIT (latch wait) 77ISWITCH

causing page fault 67macro 74

ISWITCHED toCTL 74Fast Path TCB 75LSO 75

IWAIT in IMS Dispatcher 75IWAIT in IMS dispatcher

large value 75IWAIT in term 72

Kknowledge bases, searching to find software problem

resolution 89KOIGBL module 27

specifying 27KOIGBLmp 27KOIGBLmp module 27

Llatch 72

ACTL 70

Index 103

M

ADSC directory 70AUTH 70CBTS 70conversation checkpoint latch 70DB system checkpoint 70DBBP 71, 74DC system checkpoint 71DC terminal latch 71DC user 71DEDB area lock 71definition 76DMAC 71DMAC share 72DMBE 74fast path resource 73fast path resource latch 73FNCB 73GCMD 74GEN1 74generic 74HDSM 74LOGL 76LQB 76MSDB 76NQDQ 76OBFM 76open/close 77other 77overflow buffer lock 73QBUF 78queue manager 78SMB enqueue/dequeue 78SMGT (storage management) 78SNDQ 78TCT block latch 79TM subqueue 79VBFM 79VTCB 79XCNQ 79

LGMSG IO 75local storage option

with ISWITCH 75long-term clear interval (CLRL) 34long-term interval 25LPA page 68LPA page (GFA) 68LQB pool latch 76LSO=X 75

LSO=Y 75LU 6.2 manager latch 76

Mmanuals

see publications 10, 13MAXG 35MAXG major 86MAXRGN of TRANSACT macro 58MDEX 36, 38, 40, 46, 48, 54, 63

command output 46label field arguments 85MDEX display 44

MDEX/PDEXcommand format 45MDEX and PDEX output examples 46

menubottleneck analysis 19

menu interface 18menus 18message on fast path output queue 80message on non-fast path output queue 80MFS load 76model 3270 screen 39MPP transaction type 61MSDB latch 76MSDB segment 76MTHR 39, 47, 48MTHR and SCAL

commands output 40MTHR minor 55, 84MVS waits

execution states group 64

Nnewsgroups 14NMSX 33non-competing transactions

description 52importance of excluding 53

non-message-driven sampling 33NQDQ latch 76

Oonline publications

accessing 13Open/Close Latch 77ordering publications 13OSAM Buffer Wait 77

P


other abend 77other DL/I wait 77other waits 77output waits

execution state group 80overflow allowed 73

Ppage faults 66, 67, 69parallel regions

controlling 58PDEX 36, 38, 46, 48, 50, 54, 63

command output 47display 44label field arguments 85

PDIR block latch 60PDIR pool latch 60PI resource 77PI wait 77processing state 24PROCLIM of TRANSACT macro 58program fetch 68PSB pool

insufficient space 60PSBW pool 60pseudo abend 78publications 10

accessing online 13ordering 13

QQBLKS I/O 78QBUF latch 78Queue Manager Latch 78

RREADY queue 66RESM 38RESM minor 84resuming collector sampling (RESM) 38

Ssample rate 24

changing 39–40sampling interval control (STIM) 39SCAL 40, 47, 48SCAL minor 84scaling factor

specifying 40scaling factor for MDEX command (SCAL) 40scheduling blocked 61scratch pad area (SPA) 78secondary index PCB 63SETG major 86SHMSG I/O 78short-term clear interval (CLRS) 35short-term interval 25SMB queue latch 78SMGT latch 59, 78SNDQ latch 78Software Support

contacting 91SPA I/O 78SQL call wait 81START Bottleneck Analysis 27START DEXAN 26STIM 39STIM minor 84STOP ID=DX 32STOPped

class of transaction type 61databases 61PSB 61transaction type 61

SUSP 38SUSP minor 84suspending the collector (SUSP) 38swapped in MPP 68swapping in 68sync lock, fast path 73sync point processing function 73sync point wait 79

TTCT block latch 79terminate thread 81threads

executing 19THRS 40THRS minor 48, 55, 84

command output 40Tivoli software information center 13TM allocate PSB latch 61TM scheduling latch 61TM subqueue latch 79TRANSACT macro 58transaction

Index 105

U

competing 52counts 44non-competing 52time 44

transaction countsaverage vs. total 50

transaction group commands 86transaction groups

number supported 24transaction sampling (DOPT) 36transit time

transparent to Bottleneck Analysis 50TYPRUN=HOLD 62

Uunschedulable 61using CPU

in APPL 56in IMS 56

USTOPpedtransaction type 61

VVBFM latch 79

Wwait

OSAM Buffer 77wait for BMP 62wait for GU 62wait for IFP 62wait for MPP 62wait for reschedule 62wait HSSP pvt pool 79WAIT/POST logic

comparative inefficiency 75

XXCNQ latch 79XCRB 73X-MEM page 69

X


IBM@

Part Number: SC32-9359-00

Printed in USA

SC32-9359-00

SC32-9359-00

Date post:	19-Apr-2021
Category:	Documents
Upload:	others
View:	11 times
Download:	0 times