Bottleneck Analysis Reference Manual -...

Bottleneck AnalysisReference ManualOMEGAMON II® for IMS

Version 510

GC32-9265-00

March 2002

Candle Corporation201 North Douglas Street

El Segundo, California 90245

2 OMEGAMON II for IMS Bottleneck Analysis Reference Manual V510

Registered trademarks and service marks of Candle Corporation: AF/OPERATOR, AF/PERFORMER, AF/REMOTE, Availability Command Center, Candle, Candle Command Center, Candle Direct logo, Candle Electronic Customer Support, Candle logo, Candle Management Server, Candle Management Workstation, Candle Technologies, CL/CONFERENCE, CL/SUPERSESSION, CommandWatch, CT, CT/Data Server, CT/DS, DELTAMON, eBA, eBA*ServiceMonitor, eBA*ServiceNetwork, eBusiness Institute, ETEWatch, IntelliWatch, IntelliWatch Pinnacle, MQSecure, MQView, OMEGACENTER, OMEGAMON, OMEGAMON/e, OMEGAMON II, OMEGAMON Monitoring Agent, OMEGAVIEW, OMEGAVIEW II, PQEdit, Solutions for Networked Applications, Solutions for Networked Businesses, and Transplex.Trademarks and service marks of Candle Corporation: Alert Adapter, Alert Adapter Plus, Alert Emitter, AMS, Amsys, AutoBridge, AUTOMATED FACILITIES, Availability Management Systems, Candle Alert, Candle Business Partner Logo, Candle Command Center/SentinelManager, Candle CommandPro, Candle CIRCUIT, Candle eDelivery, CandleLight, CandleNet, CandleNet 2000, CandleNet Command Center, CandleNet eBP, CandleNet eBP Access, CandleNet eBP Administrator, CandleNet eBP Broker Access, CandleNet eBP Configuration, CandleNet eBP Connector, CandleNet eBP File Transfer, CandleNet eBP Host Connect, CandleNet eBP Object Access, CandleNet eBP Object Browser, CandleNet eBP Secure Access, CandleNet eBP Service Directory, CandleNet eBP Universal Connector, CandleNet eBP Workflow Access, CandleNet eBusiness Assurance, CandleNet eBusiness Exchange, CandleNet eBusiness Platform, CandleNet eBusiness Platform Administrator, CandleNet eBusiness Platform Connector, CandleNet eBusiness Platform Connectors, CandleNet eBusiness Platform Powered by Roma Technology, CandleNet eBusiness Platform Service Directory, CandleNet Portal, CCC, CCP, CEBA, CECS, CICAT, CL/ENGINE, CL/GATEWAY, CL/TECHNOLOGY, CMS, CMW, Command & Control, Connect-Notes, Connect-Two, CSA ANALYZER, CT/ALS, CT/Application Logic Services, CT/DCS, CT/Distributed Computing Services, CT/Engine, CT/Implementation Services, CT/IX, CT/Workbench, CT/Workstation Server, CT/WS, !DB Logo, !DB/DASD, !DB/EXPLAIN, !DB/MIGRATOR, !DB/QUICKCHANGE, !DB/QUICKCOMPARE, !DB/SMU, !DB/Tools, !DB/WORKBENCH, Design Network, DEXAN, e2e, eBAA, eBAAuditor, eBAN, eBANetwork, eBAAPractice, eBP, eBusiness Assurance, eBusiness Assurance Network, eBusiness at the speed of light, eBusiness at the speed of light logo, eBusiness Exchange, eBusiness Institute, eBX, End-to-End, ENTERPRISE, Enterprise Candle Command Center, Enterprise Candle Management Workstation, Enterprise Reporter Plus, EPILOG, ER+, ERPNet, ESRA, ETEWatch Customizer, HostBridge, InterFlow, Candle InterFlow, Lava Console, MessageMate, Messaging Mastered, Millennium Management Blueprint, MMNA, MQADMIN, MQEdit, MQEXPERT, MQMON, NBX, NetGlue, NetGlue Extra, NetMirror, NetScheduler, OMA, OMC Gateway, OMC Status Manager, OMEGACENTER Bridge, OMEGACENTER Gateway, OMEGACENTER Status Manager, OMEGAMON Management Center, OSM, PC COMPANION, Performance Pac, PowerQ, PQConfiguration, PQScope, Response Time Network, Roma, Roma Application Manager, Roma Broker, Roma BSP, Roma Connector, Roma Developer, Roma FS/A, Roma FS/Access, RomaNet, Roma Network, Roma Object Access, Roma Secure, Roma WF/Access, Roma Workflow Access, RTA, RTN, SentinelManager, Somerset, Somerset Systems, Status Monitor, The Millennium Alliance, The Millennium Alliance logo, The Millennium Management Network Alliance, TMA2000, Tracer, Unified Directory Services, Volcano and ZCopy.Trademarks and registered trademarks of other companies: AIX, DB2, MQSeries and WebSphere are registered trademarks of International Business Machines Corporation. SAP is a registered trademark and R/3 is a trademark of SAP AG. UNIX is a registered trademark in the U.S. and other countries, licensed exclusively through X/Open Company Ltd. HP-UX is a trademark of Hewlett-Packard Company. SunOS is a trademark of Sun Microsystems, Inc. All other company and product names used herein are trademarks or registered trademarks of their respective companies.

Copyright © March 2002, Candle Corporation, a California corporation. All rights reserved. International rights secured.

Threaded Environment for AS/400, Patent No. 5,504,898; Data Server with Data Probes Employing Predicate Tests in Rule Statements (Event Driven Sampling), Patent No. 5,615,359; MVS/ESA Message Transport System Using the XCF Coupling Facility, Patent No. 5,754,856; Intelligent Remote Agent for Computer Performance Monitoring, Patent No. 5,781,703; Data Server with Event Driven Sampling, Patent No. 5,809,238; Threaded Environment for Computer Systems Without Native Threading Support, Patent No. 5,835,763; Object Procedure Messaging Facility, Patent No. 5,848,234; End-to-End Response Time Measurement for Computer Programs, Patent No. 5,991,705; Communications on a Network, Patent Pending; Improved Message Queuing Based Network Computing Architecture, Patent Pending; User Interface for System Management Applications, Patent Pending.

NOTICE: This documentation is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the Government is subject to restrictions set forth in the applicable license agreement and/or the applicable government rights clause.This documentation contains confidential, proprietary information of Candle Corporation that is licensed for your internal use only. Any unauthorized use, duplication, or disclosure is unlawful.

Contents 3

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Adobe Portable Document Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Documentation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Application Trace Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16New OMEGAMON II Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Documentation Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

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

Chapter 2. Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25About the Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Attaching the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Controlling the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Invoking Bottleneck Analysis (IDEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Specifying Collector Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

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

Chapter 4. Bottleneck Analysis Execution States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55About Execution States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61IMS Scheduling Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Database I/O Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69MVS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70IMS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Output Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88External Subsystem Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Contents


Appendix A. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Bottleneck Analysis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92Transaction Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95DBCTL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

Appendix B. Guide to Candle Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Base Maintenance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98Enhanced Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102Customer Support Contact Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

List of Figures 5

FIGURE 1. Bottleneck Analysis Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21FIGURE 2. Executing Transactions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22FIGURE 3. Attaching the Bottleneck Analysis Collector Using IDEG . . . . . . . . . . . . . . . . . . . . . . . .28FIGURE 4. IDEG and BEGN Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33FIGURE 5. IDEG and END Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33FIGURE 6. DTCH Command Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34FIGURE 7. Using DTCH from the Menu Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34FIGURE 8. BMPXOFF and BMPXON Commands Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35FIGURE 9. Using BMPX from the Menu Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

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

List of Figures

6 OMEGAMON II for IMS Bottleneck Analysis Reference Manual Version 510

Preface 7

Preface

IntroductionThis manual contains reference information about the Bottleneck Analysis component of OMEGAMON II for IMS.

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

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

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

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

n 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 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 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 Book


About This Book

Who should use 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 Candle-developed 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.

Documentation set informationThe documentation listed in the following table is available for the Candle IMS Products. To order additional product manuals, contact your Candle Support Services representative.

Table 1. OMEGAMON II for IMS Documentation Set

Document Number

Document Name Description

ET53-5586 End-to-End Response Time Feature (ETE) Reference Manual

Provides reference information about ETE commands, error messages, return codes, and sense codes.

IC51-6057 Installing Candle Products on MVS

Provides installation instructions and other installation considerations.

I251-5610 OMEGAMON II for IMS and OMEGAMON II for DBCTL Configuration and Customization Guide

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

I253-6332 OMEGAMON II for IMS Realtime Commands Reference Manual

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

I253-6333 OMEGAMON II for IMS Bottleneck Analysis Reference Manual

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

Preface 9

About This Book

I253-6336 OMEGAMON II for IMS Historical Component (EPILOG) Reference Manual

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

I254-6334 OMEGAMON II for IMS User’s Guide

Teaches the basics of using OMEGAMON II for IMS to manage realtime IMS environments.

I254-6335 OMEGAMON II for IMS Historical Component (EPILOG) User’s Guide

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

I254-6337 OMEGAMON II for IMS Response Time Analysis (RTA) Reference Manual

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

I299-6303 OMEGAMON II for IMS and OMEGAMON II for DBCTL Application Trace Facility

Provides user and reference information about the features of the Application Trace Facility (ATF) component.

I299-6338 OMEGAMON II for IMS and OMEGAMON II for DBCTL Transaction Reporting Facility

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

I299-6339 OMEGAMON II for IMS and OMEGAMON II for DBCTL IMS Console Facility

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

W052-6238, W052-6239, W052-6240,W052-6356,W052-6357

Candle Products Messages Manual, Vol. 1 through 5

Provides reference summary information for all Candle product messages.

Table 1. OMEGAMON II for IMS Documentation Set

Document Number

Document Name Description

About This Book


Where to look for more informationFor more information related to your product, please see the

n technical documentation CD-ROM that came with your productn technical documentation information available on the Candle Web site at

www.candle.comn online help provided with your product

Ordering additional product documentationTo order additional product manuals, contact your Candle Customer Support representative.

Preface 11

About This Book

We would like to hear from youCandle welcomes your comments and suggestions for changes or additions to the documentation sets. A user comment form, located at the back of each manual, provides simple instructions for communicating with the Candle Information Development department.

You can also send email to [email protected]. Please include “OMEGAMON II for IMS Bottleneck Analysis Reference Manual V510“ in the subject line.

Adobe Portable Document Format


Adobe Portable Document Format

Printing this bookCandle supplies documentation in the Adobe Portable Document Format (PDF). The Adobe Acrobat Reader will print PDF documents with the fonts, formatting, and graphics in the original document. To print a Candle document, do the following:

1. Specify the print options for your system. From the Acrobat Reader Menu bar, select File > Page Setup… and make your selections. A setting of 300 dpi is highly recommended as is duplex printing if your printer supports this option.

2. To start printing, select File > Print... on the Acrobat Reader Menu bar.

3. On the Print pop-up, select one of the Print Range options forn Alln Current pagen Pages from: [ ] to: [ ]

4. (Optional). Select the Shrink to Fit option if you need to fit oversize pages to the paper size currently loaded on your printer.

Printing problems?The print quality of your output is ultimately determined by your printer. Sometimes printing problems can occur. If you experience printing problems, potential areas to check are:n settings for your printer and printer driver. (The dpi settings for both your

driver and printer should be the same. A setting of 300 dpi is recommended.)

n the printer driver you are using. (You may need a different printer driver or the Universal Printer driver from Adobe. This free printer driver is available at www.adobe.com.)

n the halftone/graphics color adjustment for printing color on black and white printers (check the printer properties under Start > Settings > Printer). For more information, see the online help for the Acrobat Reader.

n the amount of available memory in your printer. (Insufficient memory can cause a document or graphics to fail to print.)

For additional information on printing problems, refer to the documentation for your printer or contact your printer manufacturer.

Contacting AdobeIf additional information is needed about Adobe Acrobat Reader or printing problems, see the Readme.pdf file that ships with Adobe Acrobat Reader or contact Adobe at www.adobe.com.

http://www.adobe.com



Preface 13

Documentation Conventions


IntroductionCandle documentation adheres to accepted typographical conventions for command syntax. Conventions specific to Candle documentation are discussed in the following sections.

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

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

Variables and literalsIn examples of 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.

Note: In ordinary text, variable names appear in italics.



SymbolsThe following symbols may appear in command syntax:

Table 2. 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.

What’s New 15

What’s New

Chapter overviewVersion 510 of OMEGAMON II for IMS and OMEGAMON II for DBCTL significantly enhanced the Application Trace Facility. This version also provides several new functions, which broaden the overall functionality of OMEGAMON II for IMS and OMEGAMON II for DBCTL.

Chapter contentsApplication Trace Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16New OMEGAMON II Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Documentation Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

W

Application Trace Facility


Application Trace FacilityApplication Trace Facility (ATF) is a monitoring agent in OMEGAMON II for IMS and OMEGAMON II for DBCTL. In Version 510, ATF was significantly enhanced so that:

n Multiple ATF OMEGAMON Classic address space sessions can monitor the same IMS

n The IMS Monitor can run concurrently with these ATF sessions

n All environments for IMS, IMS DB/DC, IMS DC and IMS DBCTL are supported

n A site has external control of its operations

n IMS Version 7 DC Monitor is supported

n Concurrent Online TRF display and ATF display functions are supported

In the previous Version 500, ATF had a DETAIL parameter that could be set to LOW or HIGH. In Version 510, this parameter was removed and the function was separated to display this information on separate sets of panels:

n What used to be DETAIL=LOW in ATF V500 is now the Online TRF Display

n What used to be DETAIL=HIGH in ATF V500 is now new ATF panels

The changes made to ATF in this release are explained in detail in the OMEGAMON II for IMS and OMEGAMON II for DBCTL Application Trace Facility Manual, Version 510. ATF’s online help has been upgraded to reflect these new features.

What’s New 17

New OMEGAMON II Functions

New OMEGAMON II FunctionsSeveral new functions were added to OMEGAMON II for IMS and OMEGAMON II for DBCTL. These functions are:

n Expanded generic IMS command support

n Enhanced VSAM buffer pool statistics

n Enhanced fast path buffer pool statistics

n Enhanced fast path statistics

n Enhanced operator assistance for fast path areas

n Additional data and sorting on IMS Message region fields

Documentation Changes


Documentation Changes

Online documentationWith version 510, Candle Corporation has moved OMEGAMON II for IMS manuals from IBM BookMaster to Adobe FrameMaker. This move was made to better enable us to address our customers’ needs by providing tools that enhance productivity.

One of the results of the move is that it is no longer possible to create BookManager versions of the OMEGAMON II for IMS manuals. However, the manuals remain available online in the Adobe PDF version on CD-ROM and are also available on the Candle Corporation website at www. Candle.com.

The documentation CD being provided with this release has robust and easy-to-use search capabilities. You can search for information in multiple volumes, multiple versions, and across products. The CD also provides easy setup of search indexes with a single click of the mouse.

If you want to order printed copies of the documentation, please contact your Candle Support Services representative.

Bottleneck Analysis Menu Screens 19

Bottleneck Analysis Menu Screens

Chapter overviewThis chapter describes the Bottleneck Analysis menu screens.

Chapter contentsAccessing the Bottleneck Analysis Menu Screens . . . . . . . . . . . . . . . . . . . 20Accessing the Bottleneck Analysis Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 21Accessing the Factors Affecting Executing Transactions Screen . . . . . . . . . 22

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 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 45 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 28 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 21 and Figure 2 on page 22. (Since transactions do not exist in a DBCTL environment, fields relating to transactions will not appear.) See “DBCTL Environment” on page 96 for a list of commands that are not applicable in a DBCTL environment.



Bottleneck Analysis Collector 25

Bottleneck Analysis Collector

Chapter overviewThis chapter provides information about the Bottleneck Analysis collector.

Chapter contentsAbout the Bottleneck Analysis Collector . . . . . . . . . . . . . . . . . . . . . . . . . . 26Attaching the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Controlling the Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Invoking Bottleneck Analysis (IDEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Specifying Collector Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

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 55 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. Candle 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:

n 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. Candle ships Bottleneck Analysis with a default short-term interval of 5 minutes.

n 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. Candle 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:

n from OMEGAMON II with the -IDEG command

n when OMEGAMON II initializes with the START DEXAN command

n 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 29.)

Note: You can also start the collector from the OMEGAMON II System Overview panel in the CUA interface. For more information, see the 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

________________ 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 ===========================================================================



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.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 33.

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 Candle-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

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 <<



sampling (DBSW)” on page 39 describes how this is done with the DBSW command.)

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 >.

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 << ===============================================================================



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 28.

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

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

n 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.

n 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 Candle supplies.)

-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 <<



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 36.

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 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.

________________ 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 <<==========================================================================



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 Candle 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 37.

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 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.

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

NMSXON NMSXOFF

BMPX ON

Non-message BMP activity ignored


BMPX OFF


Non-message BMP activity is recorded



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 Candle supplies.)

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 Candle supplies.)

-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 <<

-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 <<



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).

Candle 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 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 collector, change the DBSW setting, and then issue the IDEG and BEGN commands to restart the collector. Figure 14 on page 39 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 Candle 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 55 describes the concepts of executing and competing transactions. Executing transactions are those actually associated with an IMS dependent region.

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 <<



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

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.

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


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:

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

n set the long-term clear intervaln set the short-term clear intervaln control whether the collector collects data by individual database namen suspend the collectorn resume collector samplingn set the sampling intervaln display the threshold for the MDEX commandn display the scaling factor for the MDEX commandn display the threshold for the PDEX commandn 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 Candle 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 45.) 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.

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 <<



FIGURE 19. MTHR Command Output

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 Candle 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 45.)

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

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

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 <<



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 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 Candle Customer 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 << THRS >> 0 is PDEX wait percent threshold <<

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

Bottleneck Analysis Displays (MDEX/PDEX) 45

Bottleneck Analysis Displays(MDEX/PDEX)

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

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

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 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 55 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.

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.



FIGURE 23. MDEX/PDEX Commands Format

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 60 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 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.

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

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:

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

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

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

n 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



n 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.

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

n 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.

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

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

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

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

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



n The PDEX display is limited to executing transactions, indicating that the DOPT option was set to EXEC. (“Transaction sampling (DOPT)” on page 39 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.


Factors That Influence the Displays


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

n 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 35 describes the BMPX command.

n 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 39describes the DBSW command.

n 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 46 describes.

n 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 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.

n 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 39.

n 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 42 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 43.



n 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 43 describes the THRS command.

n 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.

n 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


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 55

Bottleneck Analysis Execution States

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

Chapter contentsAbout Execution States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61IMS Scheduling Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Database I/O Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69MVS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70IMS Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Output Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88External Subsystem Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

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.

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.



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

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

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.



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:

n 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 35 discusses the BMPX option.

n 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 OMEGAMON II for IMS Realtime Commands Reference Manual.

n 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 39 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 55.


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 46.

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:

n 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.

n 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.

CPU Usage


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 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:

n Block loadern Block mover waitn DDIR Block Latchn PDIR Pool Latchn DMB pooln DMB Block Latchn Intent conflictn PDIR Block Latchn PDIR Pool Latchn PSB Block Latchn PSB pooln PSBW pooln Scheduling blockedn TM Allocate PSB Latchn TM Scheduling Latchn Unselectablen Wait for BMPn Wait for IFPn Wait for GUn Wait for MPP



n 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:

n The transaction type was STOPped.

n The transaction type was USTOPped.

n The class of the transaction type was STOPped.

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

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

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

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

n 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:

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

n 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:

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

n 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.


MVS Waits

Some amount of CPU Wait—and perhaps even other states such as Database I/O Wait—will be seen as Using CPU.

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:

n 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).

n 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 72.

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).

MVS Waits


n 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).

n 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.

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:

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

n 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:

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

n 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.


MVS Waits

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.

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).

n 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).

n 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:

MVS Waits


n 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).

n 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:

n 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).

n 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:

n 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).

n 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.

MVS Waits


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.

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.

IMS Waits


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

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.


IMS Waits

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.

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).

IMS Waits


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

n I/O to ISAM files

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

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

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

n users issuing large numbers of IMS commands

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

n 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:

n 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.

n 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 Candle Customer Support.


IMS Waits

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 Candle Customer 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.

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.

IMS Waits


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.

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 Candle Customer 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.


IMS Waits

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 Candle Customer 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.

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.

IMS Waits


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.

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.


IMS Waits

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 91

Command Summary

Appendix overviewThis appendix summaries the Bottleneck Analysis commands.

Appendix contentsBottleneck Analysis Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Transaction Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95DBCTL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

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).

Command Summary 93


SUSP Suspends collector.

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



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

Command Summary 95

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.

DBCTL Environment


DBCTL Environment

IntroductionThe following commands are not applicable in a DBCTL environment:

n DOPT cccccn AUTO n TRAN=, TERM=, CLASS= entry specifications of SETG

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

n IMS scheduling waitsn output waitsn external subsystem waits

Guide to Candle Customer Support 97

Guide to CandleCustomer Support

IntroductionCandle Corporation is committed to producing top-quality software products and services. To assist you with making effective use of our products in your business environment, Candle is also committed to providing easy-to-use, responsive customer support.

Precision, speed, availability, predictability—these terms describe our products and Customer Support services.

Included in this Guide to Candle Customer Support is information about the following:

Base Maintenance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98– Telephone Support

– eSupport

– Description of Severity Levels

– Service-level objectives

– Recording and monitoring calls for quality purposes

– Customer Support Escalations

– Above and Beyond

Enhanced Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102– Assigned Support Center Representative (ASCR)

– Maintenance Assessment Services (MAS)

– Multi-Services Manager (MSM)

Customer Support Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . 104– Link to Worldwide Support Telephone and E-mail information

B

Base Maintenance Plan



OverviewCandle offers a comprehensive Base Maintenance Plan to ensure that you realize the greatest value possible from your Candle software investments. We have more than 200 technicians providing support worldwide, committed to being responsive and to providing expedient resolutions to support requests. Technicians are available worldwide at all times during the local business day. In the event of an after-hours or weekend emergency, our computerized call management and forwarding system will ensure that a technician responds to Severity One situations within one hour. For customers outside of North America, after-hours and weekend support is provided in English language only by Candle Customer Support technicians located in the United States.

Telephone supportCandle provides consistently reliable levels of service—thanks to our worldwide support network of dedicated experts trained for specific products and operating systems. You will always work with a professional who truly understands your problem.

We use an online interactive problem management system to log and track all customer-reported support requests. We give your support request immediate attention by routing the issue to the appropriate technical resource, regardless of geographic location.

Level 0 Support is where your call to Candle Customer Support is first handled. Your support request is recorded in our problem management system, then transferred to the appropriate Level 1 support team. We provide Level 0 manual interaction with our customers because we support more than 170 products. We feel our customers would prefer personal interaction to a complex VRU or IVR selection menu.

Level 1 Support is the service provided for initial support requests. Our Level 1 team offers problem determination assistance, problem analysis, problem resolutions, installation assistance, and preventative and corrective service information. They also provide product usage assistance.

Level 2 Support is engaged if Level 1 cannot provide a resolution to your problem. Our Level 2 technicians are equipped to analyze and reproduce errors or to determine that an error is not reproducible. Problems that cannot be resolved by Level 2 are escalated to Candle’s Level 3 R&D support team.

Level 3 Support is engaged if a problem is identified in Candle product code. At Level 3, efforts are made to provide error correction, circumvention or notification that a correction or circumvention is not available. Level 3 support provides available maintenance modifications



and maintenance delivery to correct appropriate documentation or product code errors.

eSupportIn order to facilitate the support process, Candle also provides eSupport, an electronic full-service information and customer support facility, using the World Wide Web at www.candle.com/support/. eSupport allows you to open a new service request and update existing service requests, as well as update information in your customer profile. New and updated service requests are queued to a support technician for immediate action. And we can respond to your request electronically or by telephone—it is your choice.

eSupport also contains a continually expanding knowledge base that customers can tap into at any time for self-service access to product and maintenance information.

The Candle Web Site and eSupport can be accessed 24 hours a day, 7 days a week by using your authorized Candle user ID and password.

Description of Candle severity levelsResponses to customer-reported product issues and usage questions are prioritized within Candle according to Severity Code assignment. Customers set their own Severity Levels when contacting a support center. This ensures that we respond according to your individual business requirements.

Severity 1 Crisis

A crisis affects your ability to conduct business, and no procedural workaround exists. The system or application may be down.

Severity 2High

A high-impact problem indicates significant business effect to you. The program is usable but severely limited.

Severity 3Moderate

A moderate-impact problem involves partial, non-critical functionality loss or a reasonable workaround to the problem. A “fix” may be provided in a future release.

Severity 4Low

A low-impact problem is a “how-to” or an advisory question.

Severity 5Enhancement Request

This is a request for software or documentation enhancement. Our business units review all requests for possible incorporation into a future release of the product.

http://www.candle.com/support/



Candle has established the following service-level objectives:

Recording and Monitoring Calls for Quality PurposesCandle is committed to customer satisfaction. To ensure that our customers receive high levels of service, quality and professionalism, we’ll monitor and possibly record incoming and outgoing Customer Support calls. The information gleaned from these calls will help us serve you better. If you prefer that your telephone call with Candle Customer Support in North America not be monitored or recorded, please advise the representative when you call us at (800) 328-1811 or (310) 535-3636.

Customer Support EscalationsCandle Customer Support is committed to achieving high satisfaction ratings from our customers. However, we realize that you may occasionally have support issues that need to be escalated to Candle management. In those instances, we offer the following simple escalation procedure:

If you experience dissatisfaction with Candle Customer Support at any time, please escalate your concern by calling the Candle support location closest to you. Ask to speak to a Customer Support manager. During standard business hours, a Customer Support manager will be available to talk with you or will return your call. If you elect to hold for a manager, you will be connected with someone as soon as possible. If you wish a return call, please tell the Candle representative coordinating your call when you will be available. After contacting you, the Customer Support manager will develop an action plan to

Call Status Severity 1 Goal

Severity 2 Goal

Severity 3 Goal

Severity 4 Goal

Severity 5Goal

First Call Time to Answer

90% within one minute

Level 1 Response

(Normal Business Hours)

90% within 5 minutes

90% within one hour

Level 2 Response

(Normal Business Hours)

Warm Transfer

90% within two hours

90% within eight hours

Scheduled follow-up (status update)

Hourly or as agreed

Daily or as agreed

Weekly or as agreed Notification is made when an enhancement is incorporated into a generally available product.

Notification is made when a fix is incorporated into a generally available product.

The above information is for guideline purposes only. Candle does not guarantee or warrant the above service levels. This information is valid as of October 1999 and is subject to change without prior notice.



resolve your issue. All escalations or complaints received about support issues are logged and tracked to ensure responsiveness and closure.

Above and BeyondWhat differentiates Candle’s support services from our competitors? We go the extra mile by offering the following as part of our Base Maintenance Plan:

n Unlimited multi-language defect, installation and operations support

n eSupport using the World Wide Web

n Regularly scheduled product updates and maintenance provided at no additional charge

n Over 200 specialized technicians providing expert support for your Candle products

Enhanced Support Services



OverviewOur Base Maintenance Plan provides a high level of software support in a packaged offering. However, in addition to this plan, we have additional fee-based support services to meet unique customer needs.

The following are some examples of our added-value support services:

n Assigned Support Center Representative Services (ASCR)

– An assigned focal point for managing support escalation needs

– Proactive notification of available software fixes

– Proactive notification of product version updates

– Weekly conference calls with your ASCR to review active problem records

– Monthly performance reviews of Candle Customer Support service levels

– Optional on-site visits (extra charges may apply)

n Maintenance Assessment Service (MAS)

– On-site assessment services

– Advice about product maintenance and implementation

– Training your staff to develop efficient and focused procedures to reduce overall cost of ownership of your Candle software products

– Analysis of your Candle product environment: versions, updates, code correction history, incident history and product configurations

– Reviews to ensure that purchased Candle products and solutions are used effectively

n Multi-Services Manager (MSM)

Multi-Services Manager provides highly valued services to customers requiring on-site full time expertise to complement their technical resources.

– Dedicated on-site Candle resource (6 months or one year) at your site to help ensure maximum use and effectiveness of your Candle products

– Liaison for all Candle product support activities, coordination and assistance with implementation of all product updates and maintenance releases

– Works with your staff to understand business needs and systems requirements



– Possesses technical and systems management skills to enhance your staff’s knowledge and expertise

– Other projects as defined in Statement of Work for MSM services

Customer Support Contact Information


Customer Support Contact Information

Link to Worldwide Support Telephone and E-mail informationTo contact Customer Support, the current list of telephone numbers and e-mail addresses can be found on the Candle Web site, www.candle.com/support/.

Select Support Contacts from the list on the left of the page.

http://www.candle.com/support/

Index 105

Symbols*MDEX minor 92*PDEX minor 92/DBR AREA 80/STOP ADS 80/STOP AREA 80

AABCD 44ABCD minor 92abend

other 84termination due to 79

ACTL latch 77Adobe portable document format 12ADSC directory latch 77AFQ 72–73APPL

using CPU in 61application I/O 70ASCR

assigned support center representative 102aSETGnn 95assigned support center representative

ASCR 102at 89attaching the collector 28–31

at an MVS console 31from OMEGAMON II 28when OMEGAMON II initializes 29

AUTH latch 77Available Frame queue 72average transaction counts

statistics 53

Bbatch processing regions

ignoring 35, 36begin data collection 33BEGN 39BEGN minor 33, 92BLDL I/O 70block loader 64block mover wait 64BMP

transaction sampling (BMPX) 35, 51

transaction sampling (NMSX) 36transaction type 66

BMPX 51BMPX minor 92from menu interface 36minor 36

BMPX? 35BMPXOFF 35BMPXOFF minor 92BMPXON 35BMPXON minor 92Bottleneck 92bottleneck analysis

bytes required 39commands summary 92description 8invoking 32menu 21methodology 61

buckets (virtual storage area) 26

CCBTS latch 77clear interval

long-term 37short-term 37

clearing counters 37–38CLRL 37CLRL minor 92CLRL05 and CLRL

commands output 38CLRS 38CLRS minor 92CLRS? 38CLRSnn and CLRS

command output 38collection, data

beginning 33collector 26–44

abend 44attaching from OMEGAMON II 28controlling 32detaching 34, 35leave system command 33options, specifying 41restart 39

Index


starting 29, 33collector abend display (ABCD) 44collector operation 26–27command argument field 47command label field 47commands

major 92minor 92transaction group 95

COMP 40competing transactions

description 57controlling

collector 32database sampling 39

conversation checkpoint latch 77counters

clearing 38counters (virtual storage area) 26CPU usage 61CPU wait (CTL) 70CPU wait (DEP) 71create thread 89Cross Memory Page 71CSA page (GFA) 71CTL EXT priv page 72CTL private page 72customer support

base maintenance plan 98contact information 104enhanced support services 102eSupport 99severity levels 99telephone support 98

Ddata collection

starting 29, 33database I/O waits

execution states group 69database sampling

changing 39option 39

database sampling (DBSW) 39DB system checkpoint latch 78DBCTL commands 96DBCTL environments 23, 52, 96DBSW 39, 51DBSW minor 39, 92DBSW? 39DBSWOFF 39DBSWOFF minor 92DBSWON 39

DBSWON minor 92DDIR block latch 64DDIR pool latch 64DEDB updates 69DEP EXT priv page 73DEP private page 73detaching the collector 34, 35detaching the collector (DTCH) 34display

limiting 47display commands format 46display size

reducing 42display threshold for MDEX command (MTHR) 42display threshold for PDEX command (THRS) 43displays

factors influencing 51limiting 58

displays (MDEX/PDEX) 46–53DL/I IWAIT

large 84DMAC control blocks

serializing access to 79DMAC latch 78DMB block latch 63DMB pool 63

how space is freed up 64DMBE latch 79documentation set information 12DOPT 59DOPT minor 39, 49, 50, 51, 58, 92

command format 40default in KOIGBLmp 40

DTCHfrom menu interface 35minor 34

DTCH minor 34, 92

EECSA page 73END 27, 33, 39END minor 92Ending Data Collection (END) 33EPLPA 74eSupport

customer support 99exclusive control resource blocks 80EXEC 59executing transactions

description 57executing transactions screen 22execution states 46, 55, 83

ACTL latch (executing) 77

Index 107

ADSC directory latch (executing) 77application I/O (executing) 70AUTH latch (executing) 77BLDL I/O (executing) 70block loader (executing) 64block mover wait (executing) 64CBTS latch (executing) 77class 51CPU usage group 60CPU wait (CTL) (executing) 70CPU wait (DEP) (executing) 71create thread wait (executing) 89cross memory page (executing) 71CSA page (GFA) (executing) 71CSA page (MSDB) (executing) 71CTL EXT priv page (executing) 72CTL private page (executing) 72CTL private page (GFA) (executing) 72–73database I/O operations 69database I/O waits group 60DBBP latch (executing) 78DEDB area lock (executing) 78DEDB segment (executing) 78DEP EXT priv page (executing) 73DEP private page (executing) 73DEP private page (GFA) (executing) 73DMAC latch (executing) 78DMAC share latch (executing) 79DMB pool (competing) 64DMBE latch (executing) 79ECSA page (MSDB) (executing) 73ELPA page (executing) 73external subsystem waits group 60fast path buffer (executing) 79fast path IWAIT in term (executing) 79fast path other abend (executing) 79fast path overflow buffer allocation (executing) 79fast path overflow buffer lock (executing) 80fast path pseudo abend (executing) 80fast path resource latch (executing) 80fast path sync lock (executing) 80fast path syncpoint processing (executing) 80FNCB latch (executing) 80GCMD latch (executing) 81GEN1 latch (executing) 81HDSM latch (executing) 81IMS scheduling waits group 60IMS waits group 60intent conflict (competing) 65intent conflict (executing) 64, 65, 66, 77, 78, 83,

85, 86IRLM conflict wait (executing) 81

ISWITCHED to CTL (executing) 81ISWITCHED to fast path TCB (executing) 82ISWITCHed to LSO (executing) 82IWAIT in IMS dispatcher (executing) 82LGMSG I/O (executing) 83LOGL latch (executing) 83LPA page (executing) 75LPA page (GFA) (executing) 75message on fast path output queue

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

(non-competing) 88MFS load (executing) 83MSDB latch (executing) 83MSDB segment (executing) 84MVS waits group 60NQDQ latch (executing) 84OBFM latch (executing) 84open/close latch (executing) 84osam buffer wait (executing) 84other abend (executing) 84other DL/I IWAIT (executing) 84other latch (executing) 84other wait (executing) 85output waits group 60PI wait (executing) 85program fetch I/O (executing) 75PSB pool (competing) 65PSBW pool (competing) 65pseudo abend (executing) 85QBLKS I/O (executing) 85QBUF latch (executing) 85scheduling blocked (competing) 66SHMSG I/O (executing) 85SMGT latch (executing) 86SNDQ latch (executing) 86SPA I/O (executing) 86SQL call wait (executing) 89swapping in (executing) 76sync point wait (executing) 86terminate thread wait (executing) 89unschedulable (non-competing) 66using CPU in APPL (executing) 61using CPU in IMS (executing) 62VBFM latch (executing) 86wait for BMP (non-competing) 67wait for GU (competing) 67wait for IFP (competing) 67wait for MPP (competing) 67wait for reschedule (competing) 67wait HSSP PVT pool (executing) 86XCNQ latch (executing) 87


X-MEM page (GFA) (executing) 76execution states group

CPU usage 61external subsystem waits

execution state group 89

Ffast path

application IWAITing 79, 80application waiting for buffer 79output router 88overflow buffer allocation 79overflow buffer lock 80resource latch 80sync lock 80TCB 82

fast path pseudo abend 80frame allocation 72, 73, 75FREEMAIN

making frames available 73

GGFA queue 72GLBL major 95GLOBAL= parameter 29GRA queue 73GRP= keyword 47, 51

Hhardware CPU degradation

indication of 61HSSP private pool

application waiting for space 86

IIDEG 39

=BEGN keyword 29from menu interface 28major 28, 32, 34with START Bottleneck Analysis deleted 29

IDEG and BEGNcommands output 33

IDEG and ENDcommands output 33

IDEG major 28, 92IDEG minors 92–93IMS resource contentions 77IMS scheduling waits

execution states group 63IMS waits

execution states group 77installation standard

violated 70intent conflict 66invoke bottleneck analysis 32invoking

bottleneck analysis 32collector 26

invoking Bottleneck Analysis 21IRLM

waiting 81ISERWAIT (latch wait) 84ISWITCH

causing page fault 73macro 81

ISWITCHED toCTL 81Fast Path TCB 82LSO 82

IWAIT in IMS Dispatcher 82IWAIT in IMS dispatcher

large value 82IWAIT in term 79

KKOIGBL module 29

specifying 29KOIGBLmp 29KOIGBLmp module 29

Llatch 79

ACTL 77ADSC directory 77AUTH 77CBTS 77conversation checkpoint latch 77DB system checkpoint 78DBBP 78, 81DC system checkpoint 78DC terminal latch 78DC user 78DEDB area lock 78definition 83DMAC 78DMAC share 79DMBE 81fast path resource 80fast path resource latch 80FNCB 80GCMD 81GEN1 81generic 81HDSM 81

Index 109

LOGL 83LQB 83MSDB 83NQDQ 84OBFM 84open/close 84other 84overflow buffer lock 80QBUF 85queue manager 85SMB enqueue/dequeue 86SMGT (storage management) 86SNDQ 86TCT block latch 86TM subqueue 86VBFM 86VTCB 86XCNQ 87

LGMSG IO 83local storage option

with ISWITCH 82long-term clear interval (CLRL) 37long-term interval 27LPA page 75LPA page (GFA) 75LQB pool latch 83LSO=X 82LSO=Y 82LU 6.2 manager latch 83

Mmaintenance assessment service

MAS 102MAS

maintenance assessment service 102MAXG 39MAXG major 95MAXRGN of TRANSACT macro 63MDEX 39, 41, 43, 48, 51, 58, 59, 69

command output 48label field arguments 94MDEX display 46

MDEX/PDEXcommand format 47MDEX and PDEX output examples 48

menubottleneck analysis 21

menu interface 20menus 20message on fast path output queue 88message on non-fast path output queue 88MFS load 83

model 3270 screen 42MPP transaction type 66MSDB latch 83MSDB segment 84MSM

multi-services manager 102MTHR 42, 49, 51MTHR and SCAL

commands output 43MTHR minor 60, 92multi-services manager

MSM 102MVS waits

execution states group 70

NNMSX 37non-competing transactions

description 56importance of excluding 57

non-message-driven sampling 36NQDQ latch 84

OOpen/Close Latch 84OSAM Buffer Wait 84other abend 84other DL/I wait 84other waits 85output waits

execution state group 88overflow allowed 80

Ppage faults 72, 73, 76parallel regions

controlling 63PDEX 39, 41, 48, 51, 53, 58, 59, 69

command output 49display 46label field arguments 94

PDIR block latch 65PDIR pool latch 65PI resource 85PI wait 85printing problems 12processing state 26PROCLIM of TRANSACT macro 63program fetch 75PSB pool

insufficient space 65PSBW pool 65


pseudo abend 85

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

RREADY queue 72RESM 41RESM minor 92resuming collector sampling (RESM) 41

Ssample rate 26

changing 42–43sampling interval control (STIM) 42SCAL 43, 49, 51SCAL minor 92scaling factor

specifying 43scaling factor for MDEX command (SCAL) 43scheduling blocked 66scratch pad area (SPA) 86secondary index PCB 69SETG major 95severity levels

customer support 99SHMSG I/O 85short-term clear interval (CLRS) 38short-term interval 27SMB queue latch 85SMGT latch 64, 86SNDQ latch 86SPA I/O 86SQL call wait 89START Bottleneck Analysis 29START DEXAN 28STIM 42STIM minor 92STOP ID=DX 35STOPped

class of transaction type 66databases 66PSB 66transaction type 66

SUSP 41SUSP minor 93suspending the collector (SUSP) 41swapped in MPP 76swapping in 76sync lock, fast path 80

sync point processing function 80sync point wait 86

TTCT block latch 86telephone support

customer support 98terminate thread 89threads

executing 21THRS 43THRS minor 52, 60, 93

command output 44TM allocate PSB latch 66TM scheduling latch 66TM subqueue latch 86TRANSACT macro 63transaction

competing 56counts 46non-competing 56time 46

transaction countsaverage vs. total 53

transaction group commands 95transaction groups

number supported 26transaction sampling (DOPT) 39transit time

transparent to Bottleneck Analysis 53TYPRUN=HOLD 67

Uunschedulable 66using CPU

in APPL 61in IMS 61

USTOPpedtransaction type 66

VVBFM latch 86

Wwait

OSAM Buffer 84wait for BMP 67wait for GU 67wait for IFP 67wait for MPP 67wait for reschedule 67wait HSSP pvt pool 86

Index 111

WAIT/POST logiccomparative inefficiency 82

XXCNQ latch 87XCRB 80X-MEM page 76


Date post:	23-May-2018
Category:	Documents
Upload:	hathu
View:	222 times
Download:	1 times

Bottleneck Analysis Reference Manual -...

Documents