configuration and customization guide -...

Configuration and Customization GuideAlert Adapter™ for AF/REMOTE®

Version 120

GC32-9147-00

August 2002

Candle Corporation201 North Douglas Street

El Segundo, California 90245-9796

2 Alert Adapter for AF/REMOTE Configuration and Customization Guide, V120

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, CandleNet Command Center, CT, CT/Data Server, CT/DS, DELTAMON, eBA, eBA*ServiceMonitor, eBA*ServiceNetwork, eBusiness Assurance, 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 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 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 © August 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

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Adobe Portable Document Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11The Alert Adapter Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12The Alert Emitter Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Section 1.Alert Adapter for A/F REMOTE

Chapter 2. Configuring the Alert Adapter for AF/REMOTE on OS/2 . . . . . . . . . . . . . . . . .19Configuration Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Choosing a Configuration Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Starting the Alert Adapter from the Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Starting Multiple Instances from a Single Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Starting the Alert Adapter at AF/REMOTE Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Stopping the Alert Adapter for AF/REMOTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Verifying Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Alert Adapter Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Chapter 3. Configuring the Alert Adapter for AF/REMOTE on NT . . . . . . . . . . . . . . . . . . . 37Configuring the Alert Adapter for AF/REMOTE for a TCP/IP connection . . . . . . . . . . . .38Using the Alert Adapter Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Starting AF/REMOTE Alert Adapter Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Starting the Alert Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Configuring and Managing Alert Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Verifying Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Chapter 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Full-screen and Line-mode Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Fullscreen_Mode_Console Attribute Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Line_Mode_Console Attribute Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Chapter 5. Product-Provided Situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Alert Adapter for AF/REMOTE Product-provided Situations . . . . . . . . . . . . . . . . . . . . .65

Contents


Section 2.Alert Emitter for AF/REMOTE

Chapter 6. Configuting the Alert Emitter for AF/REMOTE on OS/2 . . . . . . . . . . . . . . . . . . 75TCP/IP or SNA connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Starting and Stopping the Alert Emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Starting the Alert Emitter at AF/REMOTE Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79Alert Emitter Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Chapter 7. Configuring the Alert Emitter for AF/REMOTE on NT . . . . . . . . . . . . . . . . . . . 85Configuring the Alert Emitter for AF/REMOTE for a TCP/IP connection . . . . . . . . . . . .86Starting the Alert Emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Configuring and Managing Alert Emitters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Verifying Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

Chapter 8. Creating Simple Automation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Specifying Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96Testing Your Situation Trap Table Entries (CMS for MVS Only) . . . . . . . . . . . . . . . . . . .99Filtering Out Unwanted Alert Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Chapter 9. Customizing Your Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Performance Considerations of Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104Specifying Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105

Chapter 10. Situation Trap Table Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107The Situation Trap Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108The SITNAME Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109The ORIGINNODE Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111The STATE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113The DESTNODE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115The CALLTYPE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117The SCRIPT and SUBAGENT Tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118The ARGn Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

Appendix A. Guide to Candle Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Base Maintenance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126Enhanced Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130Customer Support Contact Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Preface 5

Preface

This Configuration and Customization Guide is designed to help you configure the Alert Adapter™ for AF/REMOTE Version 120. It also contains descriptions of the attributes and product-provided situations included with this Alert Adapter.

P

About This Book


About This Book

Who should read this bookThis Configuration and Customization Guide is designed to help you configure the Alert Adapter™ for AF/REMOTE Version 120. This manual assumes that you

� have installed and configured the Candle Management Server® (CMS™) and the CandleNet Portal™ or the Candle Management Workstation® (CMW™) as described in the Installing Candle Products and Candle Management Server on MVS manual.

� have installed the Alert Adapter for AF/REMOTE as described in the Installing Candle Products and Candle Management Server on MVS manual.

� are familiar with basic CandleNet Command Center® concepts and tasks, including:

– how to use attributes to define situations

– how to modify product-provided situations

– the roles managed systems and managed objects play in a CandleNet Command Center

– what alerts and events are and how they affect managed objects

� have installed and configured AF/REMOTE and are familiar with basic automation concepts. Please see the AF/REMOTE documentation for details.

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

� technical documentation CD-ROM that came with your product

� technical documentation information available on the Candle Web site at www.candle.com

� online help provided with this product

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

We would like to hear from youCandle welcomes your comments and suggestions for changes or additions to the documentation set. 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 "Alert Adapter for AF/REMOTE Configuration and Customization Guide, V120" in the subject line.

Preface 7

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 for� All� Current page� 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:� 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.)� 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.)� 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.

� 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



What’s New 9

What’s New

Alert information captured by the Alert Adapter™ for AF/REMOTE Version 120 is now available via CandleNet Portal Version 180 or above. CandleNet Portal is a Java-based user interface for viewing and monitoring your enterprise network. Depending on how it was installed, you can start CandleNet Portal as a desktop application or through your browser. For information about the capabilities and benefits of CandleNet Portal, see Getting Started with OMEGAMON Products: CandleNet Portal.

W

Introduction 11

Introduction

IntroductionThis chapter provides an overview of the Alert Adapter for AF/REMOTE alert adapter and alert emitter programs.

The Alert Adapter for AF/REMOTE comprises two programs that perform complementary functions:

� an alert adapter program that monitors consoles, defined as AF/REMOTE sessions, for critical events and sends alert information to the Candle Management Server (CMS)

� an alert emitter program that redirects alert information sent by the CMS to an AF/REMOTE automation script

This manual provides instructions for configuring both programs.

Important: The alert adapter and alert emitter programs function independently. You can configure either one or both to meet the needs of your enterprise.

Chapter ContentsThe Alert Adapter Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12The Alert Emitter Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1

The Alert Adapter Program


The Alert Adapter Program

IntroductionAn alert adapter is a type of remote agent that monitors managed systems and relays alert information to CandleNet Command Center products.

When an alert adapter detects an event that matches a situation you have defined, the adapter sends an alert to CMW and CNP via the CMS. In the case of the Alert Adapter for AF/REMOTE, the program detects console messages indicating critical events on systems, subsystems, and applications.

Attributes included with the alert adapterThe Alert Adapter for AF/REMOTE enables you to monitor messages written to full-screen and line-mode consoles. Line-mode consoles are those whose screen scrolls one line at a time. Full-screen consoles are those whose entire screen refreshes or whose screen displays some static text while part of the screen updates.

The attributes that the Alert Adapter for AF/REMOTE provides are in the Line_Mode_Console and Fullscreen_Mode_Console attribute groups.

Note: Unless you have OMEGAVIEW II® for the Enterprise, you cannot mix these attributes with those of any other attribute group.

Product-provided situationsThe Alert Adapter for AF/REMOTE provides a variety of product-provided situations that you can use as shipped to monitor your managed systems. You can also copy and modify them to suit the needs of your environment.

The Alert Adapter for AF/REMOTE product-provided situations use attributes from the Line_Mode_Console and Fullscreen_Mode_Console groups. See “Product-Provided Situations” on page 63 for a description of each product-provided situation.

Introduction 13

The Alert Emitter Program


IntroductionAn alert emitter is an agent that enables you to transmit alert information to an associated managed system.

The Alert Emitter for AF/REMOTE automatically executes predefined action command scripts on a managed system controlled by a Candle automation product. You can use alert emitters to integrate your existing automation capabilities with the capabilities of the CandleNet Command Center products.

Process overviewDuring normal operation of a CandleNet Command Center product, information about a managed object is stored on the CMS. If a situation you have defined for a managed object evaluates to true, information about the event is forwarded from the CMS to the managed object on the CMW. A change in the managed object’s icon and color indicates an event has occurred. Information about the event is then available as attributes, which you can view when you open the object.

After you have made the modifications described in this manual, the CMS compares event information to a table you will customize for your site. This table specifies which situations are candidates for emitting their alert information and the destinations for that information. The CMS will continue to send information to the CMW as usual. The modification has no effect on the normal operation of a CandleNet Command Center and causes no noticeable increase in CPU activity on the CMS.

After you activate the alert emitter and modify your CMS, the alert emitter forwards alert information from the CMS to another program. When you use alert emitters for automation, alert information is sent to a predefined command script. You determine the action that the command script performs.



Alert Adapters and OMEGAMON Monitoring Agents are represented as remote agents in the illustration below.

The situation trap table, KFAASITRThe situation trap table resides on the CMS in a text file (or member) called KFAASITR. Minimally, it lists the locations of all the alert emitters that will receive information from the CMS. If the KFAASITR member is not present, no situation information will be forwarded to your alert emitters.

Part II of this document describes how to create the situation trap table and add entries for automation.

Command scriptsWhen an alert emitter is used for automation, it passes information to a command script.

The Alert Emitter for AF/REMOTE passes information to REXX scripts that run under AF/REMOTE control. The alert emitter includes sample scripts that you can use to perform some common automation tasks and to learn how to send alert information from the CMS to an automation command script.

For more details on command scripts, see the chapter “Customizing Your Automation” on page 103.

Introduction 15

Software Requirements


IntroductionThe software requirements for the alert adapter and the alert emitter are identical. Be aware, however, that the products required by these programs have additional hardware and software requirements not listed here. Please see the documentation of the respective products for those requirements.

Software requirementsThe Alert Adapter and Alert Emitter for AF/REMOTE require the following software:

� CNP Version 180 or above

or

� CMW Version 130 or above

Note: To determine the version level of your CMW, go to the Help menu and select Product Information. The Product Information panel tells you the version level of your CMW.

� CMS Version 130 or above

� AF/REMOTE Version 270 or above (for OS/2)

� AF/REMOTE on Windows NT version 100 (for NT)

Note: Be sure to have AF/REMOTE installed, configured, and running on the PC connected to each managed system you want to monitor from the CMW. See the AF/REMOTE product documentation for details.

Section 1. Alert Adapter for A/F REMOTE 17

Section 1. Alert Adapter for A/F REMOTE

Configuring the Alert Adapter for AF/REMOTE on OS/2 19

Configuring the Alert Adapter forAF/REMOTE on OS/2

IntroductionThis chapter describes how to configure the Alert Adapter for AF/REMOTE on OS/2 after it is installed.

Note: In this chapter, all references to the Alert Adapter for AF/REMOTE are to the Alert Adapter for AF/REMOTE on OS/2.

The Alert Adapter for AF/REMOTE is provided on the Candle CD-ROM; it is not included in the box containing AF/REMOTE. See the Installing Candle Products and Candle Management Server on MVS manual for instructions on how to install the alert adapter on the AF/REMOTE PC.

Note: The Alert Adapter for AF/REMOTE was called the AF/REMOTE agent in a previous release. Both names refer to the same component. This document refers to this component as the Alert Adapter for AF/REMOTE.

Chapter ContentsConfiguration Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Choosing a Configuration Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Starting the Alert Adapter from the Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Starting Multiple Instances from a Single Icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Starting the Alert Adapter at AF/REMOTE Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Stopping the Alert Adapter for AF/REMOTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Verifying Your Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Alert Adapter Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2

Configuration Prerequisites



TCP/IP or SNA connectionYou can configure the Alert Adapter for AF/REMOTE for either of the following connections:

The following sections list the prerequisites for each type of connection.

Prerequisites for TCP/IP connectionBefore you can configure the Alert Adapter for AF/REMOTE for a TCP/IP connection, you must perform the steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.

TCP/IP CMS hub on any platform

SNA CMS hub on MVS only

✔ Prerequisite How to Perform

Install and configure IBM’s TCP/IP for OS/2 on the PC that will run AF/REMOTE.

Follow the instructions in the IBM product documentation.

Install and configure AF/REMOTE on a PC that can communicate with the system you want to monitor.

If you have just installed a new version of AF/REMOTE, be sure to stop the Alert Adapter for AF/REMOTE before you start the new version of AF/REMOTE. See “Stopping the Alert Adapter for AF/REMOTE” on page 31.

Follow the instructions in the AF/REMOTE product documentation.

Configure the CMS.

Skip this step if the CMS is already configured on your hub system.

Follow the instructions in the Installing Candle Products and Candle Management Server on MVS manual.

Configure TCP/IP network software on the host running the CMS.

See the TCP/IP documentation for details.

Ensure that the hostname of the PC that will run the alert adapter is registered with a TCP/IP domain server. (This is so the CMS can find the AF/REMOTE system.)

Test the TCP/IP connection by pinging the CMS from the AF/REMOTE PC and vice versa. For example, from an OS/2 command prompt, enter:

ping hostname

where hostname is the name of the CMS. (Press <Ctrl>C to stop pinging.)



Stop all instances of the Alert Adapter for AF/REMOTE, if any.

Select the window of an instance to make it active. Press <Ctrl>C to terminate that instance.




Prerequisites for SNA connectionBefore you can configure the Alert Adapter for AF/REMOTE for an SNA connection, you must perform the steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.


Install and configure IBM’s Communications Manager on the PC that will run AF/REMOTE and on the host running the CMS.

Ensure that LU6.2 connections have been defined for Communications Manager and for VTAM®. LU6.2 definitions for VTAM may require an IPL. For further information, see the IBM product documentation.




Configure the CMS.



Update the GLB_SITE.TXT file to specify the SNA location broker address.

The GLB_SITE.TXT file can be found in the drive:\candle CMW directory, where drive and candle are the drive and directory where the CMW is located. The SNA location broker address can be found in the following format in the MVS CMS configuration file &rhilev.RKANPAR(KDCSSITE):

SNA:netid.lbapplid.logmode.SNASOCKETS

where netid is the network ID, lbapplid is the location broker’s applid, and logmod is the logmode for the session.


Select the window of an instance to make it active. Press <Ctrl>C to terminate that instance.

Ensure that Communications Manager is started before you start AF/REMOTE and the Alert Adapter for AF/REMOTE.




Worksheet for the Alert Adapter for AF/REMOTENo matter which configuration method you choose, you will need some or all of the following information for each AF/REMOTE session you plan to monitor with the alert adapter.

Variable Comments Your Value

session_name The name of the session you want to begin monitoring when you start the alert adapter from this icon.

If the session name contains an embedded blank, enclose the name in double quotes. This value is case sensitive. To find a list of current console session names, go to the Sessions pull-down menu on the REMOTE main panel. See the AF/REMOTE documentation for details.

Note: If your session name includes an embedded blank (for example, Message Collector), enclose the session name in double quotes.

port The CMS port number.

The port number was either determined automatically during installation or specified by the person who installed the alert adapter. The default port number is 1918.

The port value is stored in the KA2CMA.INI file.

If CMS is running on an MVS hub: You can also find the port number in the &rhilev.RKANPAR dataset in the KDCSDEFN or KDSENV member.

ctira_cell_name The cellname was either determined automatically during installation or specified by the person who installed the alert adapter. This variable is case sensitive. The default cellname is CANDLE.

The cellname value is stored in the KA2CMA.INI file.

If CMS is running on an MVS hub: The cellname must be the same as the NODEID value specified in &rhilev.RKANPAR dataset in the KDSCNFG or KBBENV member. The NODEID is normally in the form NETID.*SMFID. However, the alert adapter does not recognize the value *SMFID. In its place, substitute the 1- to 4-byte SMFID of the system where the CMS is started.

Choosing a Configuration Method


Choosing a Configuration Method

IntroductionThis section describes the configuration methods for the Alert Adapter for AF/REMOTE.

The method you choose to configure the Alert Adapter for AF/REMOTE depends on how you want to start the alert adapter. You do not have to use the same method for all the sessions you want to monitor. Decide how you want to start the alert adapter, then follow the corresponding configuration procedure.

Note: If you want to monitor multiple AF/REMOTE sessions at the same time, you must start multiple instances of the alert adapter. Start only one instance of the alert adapter per session.

Methods of starting the alert adapterYou can start instances of the Alert Adapter for AF/REMOTE using any of the following methods.

� Start the alert adapter from its icon.

This method enables you to start each instance of the agent individually as needed. If AF/REMOTE terminates, you must restart the alert adapter from the icon to reestablish the connection.

� Start multiple instances of the alert adapter from the icon.

This method enables you to start monitoring multiple sessions by double-clicking one icon. If AF/REMOTE terminates, the connection for a particular monitored session will be reestablished as soon as AF/REMOTE restarts, if you choose the reconnect option during configuration as described below.

� Start one or more instances of the alert adapter as part of AF/REMOTE startup.

This method starts one or more instances of the alert adapter automatically and ensures that AF/REMOTE is running when the alert adapter starts. If AF/REMOTE terminates, the connection can be reestablished as part of the AF/REMOTE restart sequence.


Starting the Alert Adapter from the Icon


IntroductionThis section describes how to start the alert adapter from its icon.

Each time you start the Alert Adapter for AF/REMOTE, it begins monitoring the specified AF/REMOTE session. To monitor multiple AF/REMOTE sessions at the same time, you must start multiple instances of the alert adapter. However, you can only run one instance of the alert adapter per session.

ProcedureTo start the Alert Adapter for AF/REMOTE from its icon, follow the steps below.

If you would prefer not to specify the session name at startup, you can configure the icon settings with this information. See “Avoiding prompts at startup time” on page 26 for details.

Step Action

1 Double-click the Alert Adapter for AF/REMOTE icon.

Result: A panel prompts you for the name of the AF/REMOTE session you want to monitor.

2 Type the session name and click OK. If you are unsure what to type, see “Worksheet for the Alert Adapter for AF/REMOTE” on page 23 for information.

Result: A window for the alert adapter opens on the OS/2 desktop. The name of the icon appears in the window title. You can minimize this window to help clear the desktop, but this window will remain active as long as the alert adapter is running.

3 To start additional instances of the alert adapter from the icon, repeat the steps above and specify a different session name each time.



Avoiding prompts at startup timeWhen you start the alert adapter from its icon, you are prompted for the name of the AF/REMOTE session you want to monitor. By specifying the session name at execution time, you can start multiple instances of the alert adapter from the same icon.

If for any reason, however, you want to avoid being prompted for this information when you start the alert adapter, you can specify the session name as a parameter in the icon settings notebook. You will need to have an icon for each session you want to monitor. Once you have configured each alert adapter icon, you will be able to begin monitoring a particular session by double-clicking the corresponding alert adapter icon.

To avoid prompts at startup, follow the steps below.

Step Action

1 Right-click the alert adapter icon and open the settings notebook. If the Program page is not displayed, click on the Program tab.

Result: The Program page displays.

2 Note the values already specified in the Parameters field. The value in square brackets is a placeholder for the session name. Replace the placeholder value [Session name] with the name of the AF/REMOTE session monitored by this instance of the alert adapter. See “Methods of starting the alert adapter” on page 24 for details.

Important:

1. Do not edit the other values specified in the Parameters field.

They enable the alert adapter to communicate with the CMS.

2. Be sure to delete the square brackets when you replace the placeholder value.

3 Close the settings notebook and save your changes.

If you plan to monitor additional AF/REMOTE sessions and want to configure additional icons for each one, go to the next step. Otherwise, you have completed the configuration process for the alert adapter icon.

4 If you plan to monitor additional AF/REMOTE sessions, create a copy of the alert adapter icon for each session you want to monitor (see your OS/2 documentation for details). Be sure to give each icon a unique name. Repeat the previous steps as needed for the other alert adapter icons you create.


Starting Multiple Instances from a Single Icon


IntroductionThis section describes how to start multiple instances of the alert adapter from a single icon.

You can configure a single icon to start multiple instances of the alert adapter. Each instance you start will begin monitoring a different AF/REMOTE session. If you use this method, you can begin monitoring many sessions with a single action.

Configuration ProcedureTo configure a single alert adapter icon to start multiple instances of the alert adapter, follow the steps below.

Step Action

1 Go to an OS/2 command prompt and change to the directory where the alert adapter resides.

2 Copy the file AFRIRA.CMD to a new file:

COPY AFRIRA.CMD filename.CMD

where filename is your name for the copy of AFRIRA.CMD.

Repeat this step until you have a copy of AFRIRA.CMD for each AF/REMOTE session you want to monitor. Use a different name for each copy of AFRIRA.CMD.

3 Using any text editor, edit each copy of AFRIRA.CMD.� If AF/REMOTE terminates for any reason, the connection between the alert

adapter and AF/REMOTE will be lost. If you want the alert adapter to try to reestablish the connection, change the value of the variable AI_RECONNECT to

AI_RECONNECT=YES

� Change the following variables. Use the values described in “Worksheet for the Alert Adapter for AF/REMOTE” on page 23– KDC_PORTS = 2 135 port– CTIRA_CELL_NAME = ctira_cell_name

� Locate the SESSION parameter on the KA2AA.EXE executable. Replace SESSION with the name of the AF/REMOTE session you want to monitor.

Exit the file, saving your changes.

4 Right-click the alert adapter icon and open the settings notebook. If the Program page is not displayed, click on the Program tab.

Result: The Program page displays.



Startup ProcedureTo start multiple instances of the alert adapter from an icon,

✒ Double-click on the alert adapter icon.

Result: An instance of the Alert Adapter for AF/REMOTE starts for each session represented by a copy of AFRIRA.CMD and specified as a parameter in the icon settings. Each instance of the alert adapter starts minimized in a separate window.

5 Note the values specified in the Parameters field. The first two values enable the alert adapter to communicate with the CMS. Preserve these values.

Delete any remaining values (including square brackets) then specify the name of each copy of AFRIRA.CMD:

-filename -filename2 -filename3

Important: Be sure to prefix the name of each file with a hyphen as shown above. The hyphen indicates that the value is the name of a file and not another kind of parameter. You do not need to specify the .CMD suffix.

6 Close the settings notebook for the alert adapter icon, saving your changes.

Step Action


Starting the Alert Adapter at AF/REMOTE Startup


IntroductionThis section describes how to start the alert adapter at AF/REMOTE startup.

The Alert Adapter for AF/REMOTE depends on AF/REMOTE for information about the managed systems the alert adapter monitors. You can modify the AF/REMOTE startup procedure so it will start one or more instances of the alert adapter when AF/REMOTE itself starts.

Configuration procedureFollow the steps below to start the alert adapter at AF/REMOTE startup.

Step Action

1 Go to an OS/2 command prompt and change to the directory where the Alert Adapter for AF/REMOTE resides.

2 Copy the file AFRIRA.CMD to a new file:

COPY AFRIRA.CMD filename.CMD

where filename is your name for the copy of AFRIRA.CMD.

Use a name that will help you identify this instance of the alert adapter. Repeat this step until you have a copy of AFRIRA.CMD for each AF/REMOTE session you want to monitor. Use a different name for each copy of AFRIRA.CMD.

3 Using any text editor, edit each copy of AFRIRA.CMD.� Uncomment the statements specifying the current drive and directory for the

Alert Adapter for AF/REMOTE. Change the drive letter and directory name, as needed.

� Change the following variables. Use the values described in “Worksheet for the Alert Adapter for AF/REMOTE” on page 23.– KDC_PORTS = 2 135 port– CTIRA_CELL_NAME = ctira_cell_name

� Locate the SESSION parameter on the KA2AA.EXE executable. Replace SESSION with the name of the AF/REMOTE session you want to monitor.

Exit the file, saving your changes.

4 Go to the AF/REMOTE directory (default name AFR) and create a file called AUTOUSER.REX if such a file does not already exist. Be sure that AUTOUSER.REX resides in the AF/REMOTE directory and not in the SCRIPTS directory.

5 Open the AUTOEXEC.REX file in the AF/REMOTE directory, using any text editor.

6 Scan the file until you find the section labeled “Candle Alert Adapter(s).”

7 Copy the entire section from AUTOEXEC.REX to AUTOUSER.REX.



Startup ProcedureTo start one or more instances of the alert adapter as part of AF/REMOTE startup,

✒ Restart AF/REMOTE.

Result: As part of AF/REMOTE startup, each instance of the Alert Adapter for AF/REMOTE specified in AUTOUSER.REX starts in its own minimized window on the OS/2 desktop.

8 Uncomment and copy the START statement as needed to create a START statement for each copy you created of AFRIRA.CMD.

9 Modify the path of each START statement to point to a different copy of AFRIRA.CMD.

10 Save your edits and exit AUTOUSER.REX.

Step Action


Stopping the Alert Adapter for AF/REMOTE

Stopping the Alert Adapter for AF/REMOTE

IntroductionThis section describes how to stop the Alert Adapter for AF/REMOTE.

ProcedureTo stop an instance of the Alert Adapter for AF/REMOTE, follow the steps below.

Step Action

1 Make the window of the alert adapter you want to stop the active window on the OS/2 desktop.

Note: There will be a window for each instance of the alert adapter currently running. Be sure the window you select corresponds to the session you want to stop monitoring.

2 Press <Ctrl>C.

Result: The screen displays the message:

AFRAGENT has terminated.Press any key when ready...

3 Press any key.

Result: The alert adapter window closes and you are returned to the OS/2 desktop.

Verifying Your Configuration



IntroductionThis section describes how to verify your configuration.

The configuration process enables communication between the alert adapter and alert emitter CMS. After you have completed the configuration tasks for these programs, you must verify that the alert emitter and alert emitter can communicate with the CMS.

Important: You must have installed the Alert Adapter for AF/REMOTE on the OMEGAVIEW as described in the Installing Candle Products and Candle Management Server on MVS manual before you can complete this procedure.

ProcedureTo verify your configuration, follow the steps below.

Note: This alert adapter does not provide reports.

Identifying alert adapters by typeThe Managed Systems folder may include more than one type of alert adapter. You can identify your alert adapters by the format of the name as shown below.

Step Action

1 Start the alert adapter as described in “Starting the Alert Adapter from the Icon” on page 25 Start the alert emitter as described in “Starting and Stopping the Alert Emitter” on page 78

2 Start the OMEGAVIEW and open the Managed Systems folder.

3 Scan the Managed Systems folder for the alert adapter and alert emitter you configured and started. See the sections below if you are not sure how your alert adapter and alert emitter would be represented in the Managed Systems folder.

If you find an item in the Managed Systems folder and its online status is yes, it is active and communicating with the CMS.

Alert Adapter Name Format

Alert Adapter for AF/REMOTE

hostname:ARAlertswhere

hostname the TCP/IP host name of the alert adapter (for TCP/IP connection) or the host name of the AF/REMOTE machine (as specified by the HOSTNAME environment variable defined in CONFIG.SYS)

ARActions the name suffix that identifies an Alert Adapter for AF/REMOTE



Identifying alert emitters by typeThe Managed Systems folder may include more than one type of alert emitter. You can identify your alert emitters by the format of the name as shown below.

Alert Emitter Name Format

Alert Emitter for AF/REMOTE

hostname:ARActionswhere

hostname the TCP/IP host name of the alert emitter

ARActions the name suffix that identifies an Alert Emitter for AF/REMOTE

Alert Adapter Migration Issues



IntroductionThis section describes how to migrate situations for use with Version 120.

After you have installed and configured the Version 120 alert adapter, you will be able to see the situations you created either with Version 100 or Version 110.

There are no migration actions necessary if you are migrating from Version 110 to Version 120. However, if you are migrating from Version 100 to Version 120, the Version 100 situations will not work until you convert them for use with Version 120.

Note: Product-provided templates and managed objects from Version 100 do not require any special handling to be used with Version 120.

Before you startThe procedure below assumes that you have already performed the procedure for migrating user-modified objects described in the Installing Candle Products and Candle Management Server on MVS manual. If you have not yet performed this task, please do so before starting the procedure described below.

Migrating situations to Version 120Follow the steps below to migrate your Version 100 situations for use with Version 120.

Step Action

1 Open the Situations folder and then open in Graphics View a Version 100 situation you want to use with Version 120.

2 Click a predicate in the situation to select it, then right-click to display a popup menu. Select Open as Settings from the popup menu.

Result: The settings notebook for the selected predicate opens to the Expressions page.

3 Click the Change Attribute button.

Result: The Select Attribute panel pops up with the selected attribute group and item already highlighted.

4 Click OK to save your selection and exit the panel.

Result: You are returned to the predicate settings notebook.

5 Click OK to save the settings and close the notebook.

Result: You are returned to the Graphic view of the situation.

6 Repeat steps 2-5 for each predicate in the situation.

7 Go to the View menu and select Settings View.

Result: The settings notebook for the situation opens to the Distribution page.



8 Redistribute the situation to the managed systems and managed system lists to which it was assigned in Version 100. Click OK when you are ready to close the notebook and save your changes.

9 Repeat steps 7-8 for each Version 100 situation you want to use with Version 120 of the alert adapter.

10 Select all of the Version 100 situations that you have converted, then go to the Situations menu and choose Restart.

Result: A confirmation panel pops up to report the status of the restart operation for each managed system to which a restarted situation is distributed.

11 Create a new managed object by dragging and dropping a template that reference migrated situations onto the Enterprise folder.

Result: You are prompted for the name and description of your new managed object.

12 Specify the name and description, and then click the Create button.

Result: The settings notebook for the new managed object prompts you for the managed systems and managed system lists to be represented by the managed object.

13 Add the managed systems and managed system lists you want then click OK.

Result: The icon for your new managed object appears in the Enterprise folder.

14 Repeat steps 11-13 until you have a new set of managed objects for Version 120, then delete obsolete Version 100 managed objects.

Step Action

Configuring the Alert Adapter for AF/REMOTE on NT 37

Configuring the Alert Adapter forAF/REMOTE on NT

IntroductionThis chapter describes how to configure the Alert Adapter for AF/REMOTE on NT using the Alert Adapter Manager. See “Using the Alert Adapter Manager” on page 40 for detailed information on the AF/REMOTE Alert Adapter Manager.

Note: In this chapter, all references to the Alert Adapter for AF/REMOTE are to the Alert Adapter for AF/REMOTE on NT.

The Alert Adapter for AF/REMOTE is provided on the Candle CD-ROM; it is not included in the box containing AF/REMOTE. See the Installing Candle Products and Candle Management Server on MVS manual for instructions on how to install the alert adapter on the AF/REMOTE PC.

Chapter ContentsConfiguring the Alert Adapter for AF/REMOTE for a TCP/IP connection . . . . . . . . . . . . . 38Using the Alert Adapter Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Starting AF/REMOTE Alert Adapter Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Starting the Alert Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Configuring and Managing Alert Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Verifying Your Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3

Configuring the Alert Adapter for AF/REMOTE for a TCP/IP connection



IntroductionYou will need to configure the Alert Adapter for AF/REMOTE for a TCP/IP connection.

Before you can configure the Alert Adapter for AF/REMOTE for a TCP/IP connection, you must perform the prerequisite steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.


Install and configure IBM’s TCP/IP for NT on the PC that will run AF/REMOTE.





Configure the CMS.





Ensure that the hostname of the PC that will run the alert adapter is registered with a TCP/IP domain server. (This is so the CMS can find the AF/REMOTE system.)

Test the TCP/IP connection by pinging the CMS from the AF/REMOTE PC and vice versa. For example, from a Windows NT command prompt, enter:

ping hostname

where hostname is the name of the CMS (Press <Ctrl>C to stop pinging.)


Select the Alert Adapter Manager General tab and stop the AF/REMOTE Alert Adapter Service. This will stop all alert adapters and emitters.



Worksheet for the Alert Adapter for AF/REMOTEYou will need some or all of the following information for each AF/REMOTE session you plan to monitor with the alert adapter.


AF/REMOTE host session name

The name of the session you want to begin monitoring when you start the alert adapter.

The session name must be unique on the AF/REMOTE server. This is a required field.

You can use up to 24 characters, but shorter names are easier to read. Embedded blanks are accepted. You cannot use the following special characters:

| : > < + ; = ? * & “

Note: You cannot edit the session name once you save the definition.

CMS Hostname or IP Address

The hostname or IP of the CMS to which your alert adapter is connecting.

The default CMS hostname is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

CMS Name The name of the CMS to which your alert adapter is connecting.

The default CMS name is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

CMS Port Number The port number for the CMS to which your alert adapter is connecting.

The default CMS port number is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

Using the Alert Adapter Manager



IntroductionThis section provides an overview of the AF/REMOTE Alert Adapter Manager.

Understanding the Alert Adapter ManagerAF/REMOTE provides an Alert Adapter Manager that allows you to configure and manage AF/REMOTE Alert Adapter Service, and the alert adapters and emitters running underneath it.

AF/REMOTE Alert Adapter Service is an NT service application that supports piped communications with the NT Service Control Manager, the AF/REMOTE Alert Adapter Manager, the alert adapter and alert emitter, and the AF/REMOTE server.

The Alert Adapter Manager manages the alert adapter executables by sending messages to Alert Adapter Service using named command pipes. Alert Adapter Service then carries out the requested function. AF/REMOTE and other applications can also communicate with Alert Adapter Service using pipes.

Managing alert adapters with the Alert Adapter ManagerUsing the AF/REMOTE Alert Adapter Manager you can

� start and stop the alert adapter

� add and remove an alert adapter

� view alert adapter status, properties and statistics

� enable message logging for alert adapters

Before you can use the Alert Adapter Manager to start and manage the alert adapter, AF/REMOTE Alert Adapter Service must be started. AF/REMOTE Alert Adapter Service can be started automaticaly when you start Windows NT or you can start it manually.

Also, you can choose to have the alert adapter start automatically when AF/REMOTE Alert Adapter Service starts or you can start it manually.



Accessing the Alert Adapter ManagerTo access the Alert Adapter Manager, follow the steps below.

Step Action

1 From the Start menu on your desktop, select Programs.

2 From the list of programs, select AF_Remote and then select Alert Adapter Manager.

Result: The AF/REMOTE Alert Adapter Manager dialog displays.

Starting AF/REMOTE Alert Adapter Service



IntroductionThis section describes how to start the AF/REMOTE Alert Adapter Service.

You can choose to start the Alert Adapter Service from the

� Alert Adapter Manager (either automatically or manually)

� CandleNet Command Center Start menu (either automatically or manually)

Starting the Alert Adapter Service from the Alert Adapter ManagerTo start the Alert Adapter Service from the Alert Adapter Manager, follow the steps below.

Step Action

1 Access the Alert Adapter Manager.

2 Click on the General tab.

3 Under AF/REMOTE Alert Adapter Service, specify how you want to start the Alert Adapter Service. You can choose to� start service automatically when NT boots� start service manually

4 If you chose to start service manually, you must click the Start button to start the Alert Adapter Service.



Starting Alert Adapter Service from CandleNet Command Center Start MenuTo start the Alert Adapter Service from the CandleNet Command Center Start menu, follow the steps below.

Step Action

1 From the Start menu on you desktop, select Programs.

2 From the list of programs, select CandleNet Command Center and then select Manage Candle Services.

Result: The Manage Candle Services on Local Computer dialog displays.

3 Select Candle Alert Adapter for AF/REMOTE and click the Start button.

Starting the Alert Adapter



IntroductionThis section describes how to start the alert adapter.

You can choose to start the alert adapter

� automatically when the Alert Adapter Service starts

� manually from the Alert Adapter Manager

Starting the alert adapter when the Alert Adapter Service startsTo start the alert adapter automatically when the Alert Adapter Service starts, follow the steps below.

Step Action


Result: The AF/REMOTE Alert Adapter Manager dialog displays with the Alert Adapters and Emitters tab selected.

2 In the Alert Adapters box, select the alert adapter in the Session Name column and click the Properties button.

Result: The Alert Adapter Properties dialog displays.

3 On the Alert Adapter Properties dialog, check the Enable checkbox and click OK.

Result: The alert adapter will now start automatically when the Alert Adapter Service starts.



Starting the alert adapter from the Alert Adapter ManagerTo start the alert adapter from the Alert Adapter Manager, follow the steps below.

Note: The Alert Adapter Service must be running to be able to successfully start the alert adapter.

Step Action



2 In the Alert Adapters box, select the alert adapter in the Session Name column and click the Start button.

Result: The Alert Adapter Start Confirmation dialog displays.

3 Select Yes to start the alert adapter.

Configuring and Managing Alert Adapters



IntroductionThis section describes how to configure and manage alert adapters, including how to

� add and remove alert adapters

� stop alert adapters

� enable alert adapter message logging

� view alert adapter statistics

Adding or creating alert adaptersTo add or create a new alert adapter, follow the steps below.

Removing or deleting alert adaptersTo remove or delete an alert adapter, follow the steps below.

Step Action



2 Click the Add button.

Result: The Add Alert Adapter or Alert Emitter dialog displays.

3 Select Add Alert Adapter.


4 Specify the values for the new alert adapter and click OK.

Result: The AF/REMOTE Alert Adapter Manager dialog redisplays with the new alert adapter listed in the Alert Adapters box.

Step Action



2 In the Alert Adapters box, select the alert adapter you want to remove in the Session Name column and click the Remove button.

Result: The Alert Adapter Remove Configuration dialog displays.

3 Click Yes to remove the alert adapter.

Result: The AF/REMOTE Alert Adapter Manager dialog redisplays and the alert adapter is no longer listed in the Alert Adapters box.



Stopping an alert adapterTo stop an alert adapter, follow the steps below.

Enabling alert adapter message loggingTo enable alert adapter message logging, follow the steps below.

Viewing alert adapter statisticsTo view alert adapter statistics, follow the steps below.

Step Action



2 In the Alert Adapters box, select the alert adapter you want to stop in the Session Name column and click the Stop button.

Result: The Alert Adapter Stop Confirmation dialog displays.

3 Click Yes to stop the alert adapter.

Step Action



2 In the Alert Adapters box, select the alert adapter for which you want to enable message logging and click the Properties button.


3 In the Alert Adapter Log box, check the Enable Logging checkbox.

4 Specify the required log values, including the log filename.

5 Click OK to update the alert adapter properties and enable message logging.

Step Action



2 In the Alert Adapters box, you can view the status and other statistical information about the alert adapters.

Note: You can use the scroll bar at the bottom of the box to view additional information for the alert adapters.





The configuration process enables communication between the alert adapter and alert emitter and the CMS. After you have completed the configuration tasks for these programs, you must verify that the alert adapter and alert emitter can communicate with the CMS.

Important: You must have installed the Alert Adapter for AF/REMOTE on the CMW as described in the Installing Candle Products and Candle Management Server on MVS manual before you can complete this procedure.

ProcedureTo verify your configuration, follow the steps below.

Note: This alert adapter does not provide reports.

Step Action

1 Start the alert adapter using one of the procedures described in “Starting the Alert Adapter” on page 44 Start the alert emitter using the procedure described in “Starting the Alert Emitter” on page 88

2 Start the CMW and open the Managed Systems folder.

3 Scan the Managed Systems folder for the alert adapter and alert emitter you configured and started. See the sections below if you are not sure how your alert adapter and alert emitter would be represented in the Managed Systems folder.

If you find an item in the Managed Systems folder and its online status is yes, it is active and communicating with the CMS.



Identifying alert adapters by typeThe Managed Systems folder may include more than one type of alert adapter. You can identify your alert adapters by the format of the name as shown below.

Identifying alert emitters by typeThe Managed Systems folder may include more than one type of alert emitter. You can identify your alert emitters by the format of the name as shown below.

Alert Adapter Name Format

Alert Adapter for AF/REMOTE

hostname:ARAlertswhere

hostname the TCP/IP host name of the alert adapter (for TCP/IP connection) or the host name of the AF/REMOTE machine (as specified by the HOSTNAME environment variable defined in CONFIG.SYS)

ARAlerts the name suffix that identifies an Alert Adapter for AF/REMOTE






Attributes 51

Attributes

IntroductionThis chapter provides information on the Alert Adapter for AF/REMOTE attributes.

Chapter ContentsFull-screen and Line-mode Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Fullscreen_Mode_Console Attribute Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Line_Mode_Console Attribute Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4

Full-screen and Line-mode Consoles


Full-screen and Line-mode Consoles

OverviewThe Alert Adapter for AF/REMOTE enables you to monitor messages written to full-screen and line-mode consoles.

Line-mode consoles are those whose screen scrolls one line at a time. Examples of line-mode consoles are:

� VT100 consoles

� Tandem™ 6530 consoles in line mode

� ASCII consoles

� Message Collector

Full-screen consoles are those whose entire screen refreshes or whose screen displays some static text while part of the screen scrolls. Examples of full-screen consoles are:

� MVS console

� VTAM console

� Tandem™ 6530 consoles in block mode

The attributes provided by the Alert Adapter for AF/REMOTE are in the Line_Mode_Console and Fullscreen_Mode_Console attribute groups. Without OMEGAVIEW II for the Enterprise, you cannot mix the attributes of either group with those of any other attribute group.

If you are unsure which attribute group to useIf you are unsure which type of console you have, use the full-screen console attributes to create your situations. The full-screen console attributes work with line-mode consoles and provide better support to the VT100 and Tandem consoles than do the line-mode console attributes.

The line-mode console attributes work exclusively with line-mode consoles. The advantage is that they provide better handling of multiple occurrences of the same message text.

Attributes 53

Fullscreen_Mode_Console Attribute Group


IntroductionThis section describes the Fullscreen_Mode_Console attributes.

The Fullscreen_Mode_Console attributes are:

� Begin_Column

� Begin_Row

� Managed_System_Name

� Return_Column

� Return_Length

� Return_Row

� Return_Text

� Row_Number

� Sample_Number

� Scan_Length

� Target_Text

� Timestamp

Begin_ColumnBeginning column number of the full-screen display area where Target_Text is to be found.

Valid Values

� Integer

� In the range 0-80

Usage

� If you specify 0, or if you do not specify a beginning column and the default value of 0 takes effect, then all the columns are checked.

� Although Begin_Column is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.



Begin_RowBeginning row number of the full-screen display area where Target_Text is to be found.

Valid Values

� Integer


Usage

� If you specify 0, or if you do not specify a beginning row and the default value of 0 takes effect, then all the rows are checked.

� Although Begin_Row is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Managed_System_NameName of the monitored system, in the format

sessionname:afservername:ARAlerts

Usage

This attribute is output only. Do not specify a value for it and do not use it as a situation predicate.

Return_ColumnBeginning column on the full-screen display where Return_Text is to be captured.

Valid Values

� Integer


Usage

� If you specify 0, or if you do not specify a return column and the default of 0 takes effect, then the entire line containing the target text is returned.

� Although Return_Column is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Attributes 55


Return_LengthLength in bytes of the full-screen display area to be captured in Return_Text.

Valid Values

� Integer


Usage

� Default value is 80.

� Although Return_Length is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Return_RowBeginning row on the full-screen display where Return_Text is to be captured.

Valid Values

� Integer


Usage

� If you do not specify a return row, then the first line containing the target text is returned.

� Although Return_Row is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Return_TextThe full-screen display area that is captured for return to event queries.

Valid Values

� Alphanumeric

� Maximum length of 480 characters

Usage

� The display area is determined by the values specified for the attributes Return_Column, Return_Row, and Return_Length.

� If no return values are specified, then the line containing the target text is returned.



Row_NumberAutomatically generated row number of the event.

Usage


Sample_NumberAutomatically generated sample number.

Usage


Scan_LengthLength of the full-screen display area in which the target text is to be scanned.

Valid Values

� Integer

� Range of 1 to 3440 bytes

Example

If Scan_Length=3 and Target_Text=DOWN, then each of the following areas will be scanned:

DOWNxxx

xxxDOWN

xDOWNxx

xxDOWNx

Usage

� The default of 0 scans only the target text and none of the surrounding area.

� Although Scan_Length is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Attributes 57


Target_TextText to be found in the full-screen display area specified by Begin_Row and Begin_Column.

Valid Values

� Alphanumeric


Usage

If Target_Text is not specified, the situation immediately becomes true.

TimestampDate and time when the event was detected.

Valid Values

The format is cyymmddhhmmssmmm, where:

c=century (0=20th)

y=year

m=month

d=day

h=hour

m=minute

s=second

m=millisecond

Example

0960601080000000

indicates that the event was detected on June 1, 1996, at 8:00 a.m.

Line_Mode_Console Attribute Group



IntroductionThis section describes the Line_Mode_Console attributes.

The Line_Mode_Console attributes are:

� Begin_Column_1

� Begin_Column_2

� Managed_System_Name

� Message_Text

� Row_Number

� Sample_Number

� Target_Text_1

� Target_Text_.2

� Timestamp

Begin_Column_1Beginning column number where Target_Text_1 is to be trapped. If you do not specify a column number, the whole line is trapped.

Valid Values

� Integer


Usage

Although Begin_Column_1 is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Attributes 59


Begin_Column_2Beginning column number where Target_Text_2 is to be trapped. If you do not specify a column number, the whole line is trapped.

Valid Values

� Integer


Usage

Although Begin_Column_2 is a numeric attribute, the *AVG, *MAX, *MIN, and *SUM functions are not meaningful with its values.

Managed_System_NameName of the monitored system, in the format

sessionname:.afservername:ARAlerts

Usage


Message_TextEntire text of the message associated with an event.

Usage


Row_NumberAutomatically generated row number of the event.

Usage




Sample_NumberAutomatically generated sample number.

Usage


Target_Text_1Text to be trapped.

Valid Values

� Alphanumeric


Usage

Use Target_Text_1 together with Begin_Column_1. If you do not specify Begin_Column_1, the entire line is trapped.

Target_Text_2Text to be trapped.

Valid Values

� Alphanumeric


Usage

Use Target_Text_2 together with Begin_Column_2. If you do not specify Begin_Column_2, the entire line is trapped.

Attributes 61


TimestampDate and time when the event was detected.

Valid Values

The format is cyymmddhhmmssmmm, where:

c=century (0=20th)

y=year

m=month

d=day

h=hour

m=minute

s=second

m=millisecond

Example

0960601080000000

indicates that the event was detected on June 1, 1996, at 8:00 a.m.

Product-Provided Situations 63

Product-Provided Situations

IntroductionThis chapter provides information on the Alert Adapter for AF/REMOTE product-provided situations.

The Alert Adapter for AF/REMOTE provides a variety of situations that use attributes from the Line_Mode_Console and Fullscreen_Mode_Console groups. Some of the Line_Mode_Console situations are intended specifically for use with Tandem consoles.

For instructions on modifying situations and creating managed objects to monitor them and reflect their status, see the Candle Management Workstation Quick and the CMW online help.

Chapter ContentsOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Alert Adapter for AF/REMOTE Product-provided Situations . . . . . . . . . . . . . . . . . . . . . . . 65

5

Overview


Overview

Naming ConventionsYou can find the product-provided situations in the CMW Situations container. The first part of the name of each product-provided situation identifies its console group.

TemplatesIn addition, the Alert Adapter for AF/REMOTE provides two templates:

Accessing a product-provided situationTo access a product-provided situation, follow the steps below.

Modifying a situationTo modify the situation, or to create a managed object to monitor the situation and reflect its status, follow the instructions in the Candle Management Workstation Quick Reference.

Note that product-provided situations that feature a wildcard syntax cannot be edited within CandleNet Portal. Modifications must be made within Candle Management Workstation.

AFR_* Line-mode consoles other than Tandem

AFR_FS_* Fullscreen-mode consoles

Tandem_* Tandem consoles

AFR_Sample All product-provided situations for fullscreen-mode consoles and for line-mode consoles other than Tandem are preassigned to the AFR_Sample template. You can drag and drop this template to create a managed object, and then activate the desired situations to start monitoring.

Tandem_Sample All product-provided Tandem situations are preassigned to the Tandem_Sample template. You can drag and drop this template to create a managed object, and then activate the desired situations to start monitoring.

Step Action

1 Double-click the Administration container, then double-click the Situations container.

Result: The Situations window lists all defined situations.

2 Scroll down to the desired situation and double-click to select it.

Result: The situation editor displays the graphic view of the situation.


Alert Adapter for AF/REMOTE Product-provided Situations


IntroductionThis section describes each of the Alert Adapter for AF/REMOTE product-provided situations. The product-provided situations are:

� AFR_down_CRITICAL

� AFR_down_COL11_CRITICAL

� AFR_FS_disconnected_CRITICAL

� AFR_FS_line_down_CRITICAL

� AFR_FS_sys_error_CRITICAL

� AFR_unrecoverable_error_CRITICAL

� Tandem_app_looping_WARNING

� Tandem_bus_down_CRITICAL

� Tandem_bus_errors_WARNING

� Tandem_channel_error_CRITICAL

� Tandem_channel_error_WARNING

� Tandem_disk_error_CRITICAL

� Tandem_memory_error_CRITICAL

� Tandem_memory_error_WARNING

� Tandem_net_reqs_aborted_CRITICAL

� Tandem_processor_down_CRITICAL

� Tandem_remt_app_looping_WARNING

Situation AFR_down_CRITICALSituation AFR_down_CRITICAL detects when a resource on a monitored system is down. This product-provided situation checks each message for the word DOWN, by the following formula:

If

the value of attribute Target_Text_1 *EQ DOWN

then

situation AFR_down_CRITICAL is true.

This situation is preassigned to template AFR_Sample.



Situation AFR_down_COL11_CRITICALSituation AFR_down_COL11_CRITICAL looks for a particular word in a particular location. This product-provided situation checks each message for the word DOWN and specifies that the word should begin in column 11:

If


and

the value of attribute Begin_Column_1 *EQ 11

then

situation AFR_down_COL11_CRITICAL is true.


Situation AFR_unrecoverable_error_CRITICALSystem messages may use different terms to report states of critical severity. Situation AFR_unrecoverable_error_CRITICAL checks each message for more than one term, by the following formula:

If


or

the value of attribute Target_Text_1 *EQ UNRECOVERABLE

then

situation AFR_unrecoverable_error_CRITICAL is true.

Because this situation uses the OR operator, the same attribute can have more than one possible value.


Situation AFR_FS_disconnected_CRITICALSituation AFR_FS_disconnected_CRITICAL looks for a particular text string anywhere on the screen. This situation uses the attribute Scan_Length to specify that the search should cover the entire screen:

If

the value of attribute Target_Text *EQ Disconnected

and

the value of attribute Scan_Length *EQ 2000

then

situation AFR_FS_disconnected_CRITICAL is true.




Situation AFR_FS_line_down_CRITICALSituation AFR_FS_line_down_CRITICAL looks for a text string in a particular location on the screen. This situation searches for the text LINE DOWN at row 20 and column 20:

If

the value of attribute Begin_Row *EQ 20

and


and

the value of attribute Begin_Column *EQ 20

and

the value of attribute Target_Text *EQ LINE DOWN

then

situation AFR_FS_line_down_CRITICAL is true.


Situation AFR_FS_sys_error_CRITICALSituation AFR_FS_sys_error_CRITICAL scans all rows, beginning from a particular column, for the specified text, and returns the entire row where the text is found:

If

the value of attribute Target_Text *EQ SYS ERR

and


and

the value of attribute Begin_Column *EQ 15

and

the value of attribute Return_Row *EQ 0

and

the value of attribute Return_Column *EQ 0

and

the value of attribute Return_Length *EQ 80

then

situation AFR_FS_sys_error_CRITICAL is true.




Situation Tandem_app_looping_WARNINGSituation Tandem_app_looping_WARNING checks each message for text strings that indicate a local looping program or application:

If

the value of attribute Target_Text_1 *EQ 118 APPLICATION LOOPING*

or

the value of attribute Target_Text_1 *EQ 119 LOOPING PROGRAM*

then

situation Tandem_app_looping_WARNING is true.

This situation is preassigned to template Tandem_Sample.

Situation Tandem_bus_down_CRITICALSituation Tandem_bus_down_CRITICAL checks each message for text indicating that a path to a processor is down:

If

the value of attribute Target_Text_1 *EQ 20 X BUS TO PROCESSOR procnum DOWN

or

the value of attribute Target_Text_1 *EQ 21 Y BUS TO PROCESSOR procnum DOWN

then

situation Tandem_bus_down_CRITICAL is true.

Before you can use this situation, you must modify it by substituting a processor number for each occurrence of the variable procnum.




Situation Tandem_bus_errors_WARNINGSituation Tandem_bus_errors_WARNING checks each message for text indicating non-fatal errors on a path to a processor:

If

the value of attribute Target_Text_1 *EQ 24 X BUS ERRORS TO CPU procnum*

or

the value of attribute Target_Text_1 *EQ 26 X BUS ERRORS TO CPU procnum*

or

the value of attribute Target_Text_1 *EQ 25 Y BUS ERRORS TO CPU procnum*

or

the value of attribute Target_Text_1 *EQ 27 Y BUS ERRORS TO CPU procnum*

then

situation Tandem_bus_errors_WARNING is true.

Before you can use this situation, you must modify it by substituting a processor number for each occurrence of the variable procnum.


Situation Tandem_channel_error_CRITICALSituation Tandem_channel_error_CRITICAL checks each message for text strings that indicate a serious channel error:

If

the value of attribute Target_Text_1 *EQ 61 SCHANL ERROR*

or

the value of attribute Target_Text_1 *EQ 63 IIO/HIIO I/O BUS CHANNEL ERROR*

or

the value of attribute Target_Text_1 *EQ 76 CHANNEL DOWNED*

then

situation Tandem_channel_error_CRITICAL is true.




Situation Tandem_channel_error_WARNINGSituation Tandem_channel_error_WARNING checks each message for text strings that indicate potentially troublesome channel errors:

If

the value of attribute Target_Text_1 *EQ 37 CCL OR CHANNEL PARITY ERROR*

or

the value of attribute Target_Text_1 *EQ 39 MULTIPLE (#100) CCLS*

or

the value of attribute Target_Text_1 *EQ 77 CHANNEL RESET*

then

situation Tandem_channel_error_WARNING is true.


Situation Tandem_disk_error_CRITICALSituation Tandem_disk_error_CRITICAL checks each message for text strings that indicate a disk error:

If

the attribute Target_Text_1 contains (*SCAN) the string UNEXPECTED MOUNT - STATUS

or

the value of attribute Target_Text_1 *EQ 18 $AOPR I/O ERROR*

or

the value of attribute Target_Text_1 *EQ 19 OPERATOR DISC FILE I/O ERROR*

or

the value of attribute Target_Text_1 *EQ 163 VOLUME DIRECTORY*

then

situation Tandem_disk_error_CRITICAL is true.




Situation Tandem_memory_error_CRITICALSituation Tandem_memory_error_CRITICAL checks each message for text that indicates an uncorrectable memory error:

If

the value of attribute Target_Text_1 *EQ 30 UNCORRECTABLE MEMORY ERROR*

then

situation Tandem_memory_error_CRITICAL is true.


Situation Tandem_memory_error_WARNINGSituation Tandem_memory_error_WARNING checks each message for text that indicates correctable memory errors:

If

the value of attribute Target_Text_1 *EQ 32 CORRECTABLE MEMORY ERRORS*

then

situation Tandem_memory_error_WARNING is true.


Situation Tandem_net_reqs_aborted_CRITICALSituation Tandem_net_reqs_aborted_CRITICAL checks each message for text indicating that an event has resulted in the termination of all network traffic:

If

the value of attribute Target_Text_1 *EQ 117 NETWORK REQUESTS ABORTED*

then

situation Tandem_net_reqs_aborted_CRITICAL is true.




Situation Tandem_processor_down_CRITICALSituation Tandem_processor_down_CRITICAL checks each message for text indicating that a processor is down:

If

the value of attribute Target_Text_1 *EQ 40 PROCESSOR :hp1.procnum:ehp1. DOWN

then

situation Tandem_processor_down_CRITICAL is true.

Before you can use this situation, you must modify it by substituting a processor number for the variable procnum.


Situation Tandem_remt_app_looping_WARNINGSituation Tandem_remt_app_looping_WARNING checks each message for text strings that indicate a remote looping program or application:

If

the value of attribute Target_Text_1 *EQ 120 REMOTE APPLICATION LOOPING*

or

the value of attribute Target_Text_1 *EQ 121 REMOTE APPLICATION LOOPING*

then

situation Tandem_remt_app_looping_WARNING is true.


Section 2. Alert Emitter for AF/REMOTE 73

Section 2. Alert Emitter for AF/REMOTE

Configuting the Alert Emitter for AF/REMOTE on OS/2 75

Configuting the Alert Emitter forAF/REMOTE on OS/2

IntroductionThis chapter describes how to configure the Alert Emitter for AF/REMOTE on OS/2.

Note: In this chapter, all references to the Alert Emitter for AF/REMOTE are to the Alert Emitter for AF/REMOTE on OS/2.

The Alert Emitter for AF/REMOTE is included when you install the Alert Adapter for AF/REMOTE from the Candle CD-ROM. See the Installing Candle Products and Candle Management Server on MVS manual for installation instructions.

You can start the alert emitter using either of the following methods.

� Start the alert emitter from the alert emitter icon.

This method enables you to start the alert emitter as needed. If the alert emitter terminates or is stopped, you can restart the alert emitter from the icon to reestablish the connection.

� Start the alert emitter as part of AF/REMOTE startup.

This method starts the alert emitter automatically and ensures that AF/REMOTE is running when the alert emitter starts.

If you followed the installation instructions in the Installing Candle Products and Candle Management Server on MVS manual, the alert emitter is already configured to start from its icon. Candle recommends that you complete the configuration steps for starting the alert emitter automatically, so the alert emitter can be started using either method.

Chapter ContentsTCP/IP or SNA connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Starting and Stopping the Alert Emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Starting the Alert Emitter at AF/REMOTE Startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Alert Emitter Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6

TCP/IP or SNA connection



OverviewYou can configure the Alert Emitter for AF/REMOTE for either of the following connections:

The following sections list the prerequisites for each type of connection.

Prerequisites for TCP/IP connectionBefore you can configure the Alert Emitter for AF/REMOTE for a TCP/IP connection, you must perform the steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.

TCP/IP CMS hub on any platform

SNA CMS hub on MVS only


Install and configure IBM’s TCP/IP for OS/2 on the PC that will run AF/REMOTE.




Configure the CMS.





Ensure that the hostname of the PC that will run an AF/REMOTE alert adapter or alert emitter is registered with a TCP/IP domain server. (This is so the CMS can find the AF/REMOTE system.)

Test the TCP/IP connection by pinging the CMS from the AF/REMOTE PC and vice versa. For example, from an OS/2 command prompt, enter:

ping hostname


Stop all alert adapters, if any. Select the window of an alert adapter to make it active. Press <Ctrl>C to terminate that instance of the alert adapter.



Prerequisites for SNA connectionBefore you can configure the Alert Emitter for AF/REMOTE for an SNA connection, you must perform the steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.


Install and configure IBM’s Communications Manager on the PC that will run AF/REMOTE and on the host running the CMS.

Ensure that LU6.2 connections have been defined for Communications Manager and for VTAM®. LU6.2 definitions for VTAM may require an IPL. For further information, see the IBM product documentation.



Configure the CMS.



Update the GLB_SITE.TXT file to specify the SNA location broker address.

The GLB_SITE.TXT file can be found in the drive:\candle\CMW directory, where drive and candle are the drive and directory where the CMW is located. The SNA location broker address can be found in the following format in the MVS CMS configuration file &rhilev.RKANPAR(KDCSSITE):

SNA:netid.lbapplid.logmode.SNASOCKETS

where netid is the network ID, lbapplid is the location broker’s applid, and logmode is the logmode for the session.

Stop all alert adapters, if any. Select the window of an alert adapter to make it active. Press <Ctrl>C to terminate that instance of the alert adapter.

Ensure that Communications Manager is started before you start AF/REMOTE and the Alert Emitter for AF/REMOTE.


Starting and Stopping the Alert Emitter


Starting and Stopping the Alert Emitter

IntroductionThis section describes how to start and stop the alert emitter.

Each time you start the AF/REMOTE alert emitter, it connects to the CMS and waits for incoming alert information. If you installed the Alert Adapter and Alert Emitter for AF/REMOTE according to the instructions in the Installing Candle Products and Candle Management Server on MVS manual, the alert emitter icon is already configured with the information it needs to connect to the CMS.

Starting the alert emitter from its iconTo start the AF/REMOTE alert emitter from its icon,

✒ Double-click on the alert emitter icon.

Result: A window for the alert emitter opens on the OS/2 desktop.

This window will remain active as long as the underlying alert emitter continues to run.

Stopping the Alert EmitterTo stop the AF/REMOTE alert emitter, follow the steps below.

Starting the alert emitter automaticallyIf you do not want to depend on a manual startup, Candle recommends that you modify the AF/REMOTE startup procedure to start the alert emitter automatically. See “Starting the Alert Emitter at AF/REMOTE Startup” on page 79 for details.

Step Action

1 Select the alert emitter window to make it the active window on the OS/2 desktop.

2 Press <Ctrl>C.

Result: The screen displays the message:

AF/REMOTE Emitter has terminated.Press any key when ready...

3 Press any key.

Result: The alert emitter window closes and you are returned to the OS/2 desktop.


Starting the Alert Emitter at AF/REMOTE Startup


IntroductionThis section describes how to start the alert emitter at AF/REMOTE startup.

The alert emitter depends on AF/REMOTE for information about the managed systems the alert emitter monitors. You can modify a file called by the AF/REMOTE startup procedure so the alert emitter will start when AF/REMOTE itself starts.

WorksheetYou will need the following information to configure the alert emitter for automatic startup.


port The CMS port number.

The port number was either determined automatically during installation or specified by the person who installed the alert adapter. The default port number is 1918.

If CMS is running on an MVS hub: You can also find the port number in the &rhilev.RKANPAR dataset in the KDCSDEFN or KDSENV member.

ctira_cell_name The cellname was either determined automatically during installation or specified by the person who installed the alert adapter. This variable is case sensitive. The default cellname is CANDLE.

If CMS is running on an MVS hub: The cellname must be the same as the NODEID value specified in &rhilev.RKANPAR dataset in the KDSCNFG or KDSENV member. The NODEID is normally in the form NETID.*SMFID. However, the alert adapter does not recognize the value *SMFID. In its place, substitute the 1- to 4-byte SMFID of the system where the CMS is started.



ProcedureFollow the steps below to configure the AF/REMOTE startup procedure to start the alert emitter.

Step Action

1 Go to an OS/2 command prompt and change to the directory where the alert emitter resides.

2 Using any text editor, open and edit the AFREMIT.CMD file as described below.� Uncomment the statements specifying the current drive and directory for

the alert emitter as shown in the example below:

C:CD \AFRAGENT

Change the drive letter and directory name, as needed.� Change the following variables. Use the values described in “Worksheet”

on page 79.– KDC_PORTS=(2 135 port)– CTIRA_CELL_NAME=ctira_cell_name

3 Go to the AF/REMOTE directory (default name AFR) and create a file called AUTOUSER.REX if such a file does not already exist. Be sure that AUTOUSER.REX resides in the AF/REMOTE directory and not in the SCRIPTS directory.

4 Open the AUTOEXEC.REX file in the AF/REMOTE directory using any text editor.

5 Scan the file until you find the section labeled “Candle Alert Emitter.”

6 Copy the entire alert emitter section from AUTOEXEC.REX to AUTOUSER.REX.

7 Uncomment the START statement in AUTOUSER.REX to create a START statement for the AFREMIT.CMD file.

When you start AF/REMOTE, the startup process will call the AUTOUSER.REX file and execute the START command for AFREMIT.CMD.

8 Modify the path of the START statement as needed to point to AFREMIT.CMD.

Note: Unlike the Alert Adapter for AF/REMOTE, only one instance of an alert emitter is used for each AF/REMOTE PC.

9 Save your changes and exit AUTOUSER.REX.

10 Restart AF/REMOTE.

Result: As part of AF/REMOTE startup, the alert emitter starts in its own minimized window on the OS/2 desktop.



Verifying your configurationYou should ensure that your alert emitter has been properly configured before continuing to the next chapter. See “Verifying Your Configuration” on page 32 for instructions.

Alert Emitter Migration Issues



IntroductionThis section describes how to migrate information to the new Version 120 alert emitter.

There are no migration actions necessary if you are migrating from Version 110 to Version 120.

However, if you are migrating from version 100 to Version 120, be aware that the name of the Version 120 alert emitter has a different suffix from that of the Version 100 program. This enables you to tell the difference between versions.

The situation trap table, KFAASITR, should include DESTNODE entries for each Version 100 alert emitter used with that CMS. The DESTNODE entries identify the receiving alert emitters by name.

If you are upgrading from Version 100, you must update the DESTNODE entries in the situation trap table with the Version 120 alert emitter names. If you do not make this change, the CMS will not send alert information to the Version 120 program.



Migrating information to the Version 120 alert emitterWhen you have finished configuring the Version 120 alert emitter, follow the steps below to redirect alert information to the new alert emitter.

Table 1.

Step Action

1 Start the Version 120 alert emitter as described in “Starting and Stopping the Alert Emitter” on page 78. Ensure that the alert emitter can communicate with the CMS as described in “Verifying Your Configuration” on page 32.

2 Log on to the CMS host system.

3 Change to the CMS directory (or dataset) where you created the situation trap table in Version 100. The situation trap table is named KFAASITR.� For the CMS for MVS, go to the &rhilev.RKANPAR runtime parameter library.� For the CMS for Unix, go to the candle/cms/tables directory, where candle is the

directory where the CMS resides.� For the CMS for Windows NT, go to the drive:\candle\CMS directory, where drive

and candle are the drive and directory where the CMS resides.For more information about the location of the CMS, see the Installing Candle Products and Candle Management Server on MVS manual.

4 Create a copy of the Version 100 KFAASITR in the corresponding location in Version 120, to create a backup copy.

5 Open your Version 120 KFAASITR using any text editor.

6 Edit each DESTNODE entry to update the alert emitter name with the new suffix.

Version 100 format hostname:OS2_ACTIONS

Version 110 format hostname:ARActions

where hostname is the TCP/IP host name of the alert emitter (for TCP/IP connection) or the host name of the AF/REMOTE machine (for SNA connection)

Be sure to end each entry with a semicolon (;). “Situation Trap Table Tags” on page 107 provides details about using the DESTNODE tag and other tags.

7 If you have DESTNODE entries in your situation trap table, compare the managed system names in the KFAASITR file to those in the Managed Systems folder. Update the managed system names assigned to DESTNODE tags as needed.

For example, managed systems monitored by the Alert Adapter for AF/REMOTE Version 120 use a different suffix than with Version 100:

Version 100 format hostname:AFREMOTE

Version 110 format hostname:ARAlerts

where hostname is the TCP/IP host name of the alert adapter (for TCP/IP connection) or the host name of the AF/REMOTE machine (for SNA connection)

8 Save KFAASITR and exit the file.

9 Refresh the Situation Monitor so the CMS will recognize the updated entries. See “Refreshing the Situation Monitor” on page 98 for the procedure. Alternatively, you can restart the CMS.

Configuring the Alert Emitter for AF/REMOTE on NT 85

Configuring the Alert Emitter forAF/REMOTE on NT

IntroductionThis chapter describes how to configure the Alert Emitter for AF/REMOTE on NT using the Alert Adapter Manager. See “Using the Alert Adapter Manager” on page 40 for detailed information on the AF/REMOTE Alert Adapter Manager.

Note: In this chapter, all references to the Alert Adapter for Alert Emitter are to the Alert Emitter for AF/REMOTE on NT.

The Alert Emitter for AF/REMOTE is provided on the Candle CD-ROM; it is not included in the box containing AF/REMOTE. See the Installing Candle Products and Candle Management Server on MVS manual for instructions on how to install the alert emitter on the AF/REMOTE PC.

Chapter ContentsConfiguring the Alert Emitter for AF/REMOTE for a TCP/IP connection . . . . . . . . . . . . . . 86Starting the Alert Emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Configuring and Managing Alert Emitters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Verifying Your Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7

Configuring the Alert Emitter for AF/REMOTE for a TCP/IP connection



OverviewYou will need to configure the Alert Emitter for AF/REMOTE for a TCP/IP connection.

PrerequisitesBefore you can configure the Alert Emitter for a TCP/IP connection, you must perform the prerequisite steps listed in the table below. The table indicates where to find the instructions to perform each prerequisite step.


Install and configure IBM’s TCP/IP for NT on the PC that will run AF/REMOTE.




Configure the CMS.





Ensure that the hostname of the PC that will run the alert emitter is registered with a TCP/IP domain server. (This is so the CMS can find the AF/REMOTE system.)

Test the TCP/IP connection by pinging the CMS from the AF/REMOTE PC and vice versa. For example, from a Windows NT command prompt, enter:

ping hostname


Stop all alert emitters, if any. Select the Alert Adapter Manager General tab and stop the AF/REMOTE Alert Adapter Service. This will stop all alert adapters and emitters.



Worksheet for the Alert Emitter for AF/REMOTEYou will need some or all of the following information for configuring the alert emitter.


CMS Hostname or IP Address

The hostname or IP of the CMS to which your alert emitter is connecting.

The default CMS hostname is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

CMS Name The name of the CMS to which your alert emitter is connecting.

The default CMS name is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

CMS Port Number

The port number for the CMS to which your alert emitter is connecting.

The default CMS port number is the one provided in the Candle Management Agent Configuration application when you installed the AF/REMOTE Monitoring Agent.

Starting the Alert Emitter



IntroductionThis section describes how to start the alert emitter.

You can choose to start the alert emitter

� automatically when the Alert Adapter Service starts

� manually from the Alert Adapter Manager

For instructions on starting the Alert Adapter Service, see “Starting AF/REMOTE Alert Adapter Service” on page 42.

For instructions on accessing the Alert Adapter Manager, see “Accessing the Alert Adapter Manager” on page 41.

Starting the alert emitter when the Alert Adapter Service startsTo start the alert emitter automatically when Alert Adapter Service starts, follow the steps below.

Step Action



2 In the Alert Emitters box, select the alert emitter in the CMS Name column and click the Properties button.

Result: The Alert Emitter Properties dialog displays.

3 On the Alert Emitter Properties dialog, check the Enable checkbox and click OK.

Result: The alert emitter will now start automatically when the Alert Adapter Service starts.



Starting the alert emitter from the Alert Adapter ManagerTo start the alert emitter from the Alert Adapter Manager, follow the steps below.

Note: The Alert Adapter Service must be running to be able to successfully start the alert emitter.

Step Action



2 In the Alert Emitters box, select the alert emitter in the CMS Name column and click the Start button.

Result: The Alert Emitter Start Confirmation dialog displays.

3 Select Yes to start the alert emitter.

Configuring and Managing Alert Emitters



IntroductionThis section describes how to configure and manage alert emitters, including how to

� add and remove the alert emitter

� stop the alert emitter

� enable alert emitter message logging

� view alert emitter statistics

Adding the alert emittersTo add the alert emitter, follow the steps below.

Removing or deleting the alert emitterTo remove or delete the alert emitter, follow the steps below.

Step Action



2 Click the Add button.

Result: The Add Alert Adapter or Alert Emitter dialog displays.

3 Select Add Alert Emitter.


4 Specify the values for the alert emitter and click OK.

Result: The AF/REMOTE Alert Adapter Manager dialog redisplays with the alert emitter listed in the Alert Emitters box.

Step Action



2 In the Alert Emitters box, select the alert emitter you want to remove in the CMS Name column and click the Remove button.

Result: The Alert Emitter Remove Configuration dialog displays.

3 Click Yes to remove the alert emitter.

Result: The AF/REMOTE Alert Adapter Manager dialog redisplays and the alert emitter is no longer listed in the Alert Emitters box.



Stopping an alert emitterTo stop the alert emitter, follow the steps below.

Enabling alert emitter message loggingTo enable alert emitter message logging, follow the steps below.

Step Action



2 In the Alert Emitters box, select the alert emitter you want to stop in the CMS Name column and click the Stop button.

Result: The Alert Emitter Stop Confirmation dialog displays.

3 Click Yes to stop the alert emitter.

Step Action



2 In the Alert Emitters box, select the alert emitter for which you want to enable message logging and click the Properties button.


3 In the Alert Emitter Log box, check the Enable Logging checkbox.

4 Specify the required log values, including the log filename.

5 Click OK to update the alert emitter properties and enable message logging.



Viewing alert emitter statisticsTo view alert emitter statistics, follow the steps below.

Step Action



2 In the Alert Emitters box, you can view the status and other statistical information about the alert emitter.

Note: You can use the scroll bar at the bottom of the box to view additional information for the alert emitter.





You should ensure that your alert emitter has been properly configured before continuing with creating simple automation. See “Verifying Your Configuration” on page 48 for instructions.

Creating Simple Automation 95

Creating Simple Automation

IntroductionThis chapter provides instructions on how to create the situation trap table entries you need for simple automation. This is a good method for learning how the alert emitters work before trying more advanced automation scenarios.

An important purpose of the situation trap table is to determine when the CMS should forward information to an alert emitter. The more information you provide in the situation trap table, the less the default action script will have to filter at the alert emitter level. You may prefer, however, to keep your situation trap table entries simple and just allow for more filtering work later on in the process.

The simplest form of automation you can create with alert emitters sends information about every situation status change to all the alert emitters defined in the situation trap table.

Chapter ContentsSpecifying Destinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Testing Your Situation Trap Table Entries (CMS for MVS Only) . . . . . . . . . . . . . . . . . . . . . 99Filtering Out Unwanted Alert Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8

Specifying Destinations



IntroductionThis section describes how to specify destinations for an alert emitter.

For the CMS to send alert information to an alert emitter, there must be at least one entry in the situation trap table specifying that alert emitter as the destination system. Using this very basic form of automation, you can send information about each situation status change to each alert emitter defined in the table. This method requires the following steps:

1. gathering destination names

2. creating the situation trap table

3. refreshing the CMS Situation Monitor

4. testing the situation trap table entries

Gathering destination namesWhen you want to indicate that situation status change information should be sent to an alert emitter, you must specify that alert emitter as a destination in the situation trap table. In the table, each alert emitter is identified by its name as displayed in the CMW Managed Systems folder.

Follow the steps below to gather and record the name of each alert emitter at your site, so you will have the information you need when you create the situation trap table.

Now that you have a list of the alert emitters installed at your site, continue with creating the situation trap table.

Step Action

1 Start each alert emitter at your site so it will appear in the CMW Managed Systems folder.

See “Configuting the Alert Emitter for AF/REMOTE on OS/2” on page 75 or “Configuring the Alert Emitter for AF/REMOTE on NT” on page 85 for instructions.

2 Start the CMW and open the Managed Systems folder.

Result: If you have configured the alert emitters correctly, each active alert emitter should be displayed in the Managed Systems folder.

3 Locate and record the name of each active alert emitter.

Important: The names are case sensitive. Record them exactly as shown.

You can identify which items are alert emitters by the name format.

For AF/REMOTE on OS/2, see “Verifying Your Configuration” on page 32 for a complete list. For AF/REMOTE on NT, see “Verifying Your Configuration” on page 48 for a complete list.



Creating the situation trap tableThe situation trap table is a text file (or PDS member) that you create for the CMS.

Follow the steps below to create the situation trap table.

You have supplied the basic information for automation. For the CMS to recognize the entries in the situation trap table, continue with refreshing the situation monitor.

Step Action

1 Log on to the CMS host system.

2 Change to the CMS directory (or dataset) where you will create the situation trap table.� For the CMS for MVS, go to the &rhilev.RKANPAR runtime parameter library.� For the CMS for Unix, go to the candle/cms/tables/cmsname directory, where

candle is the directory where the CMS resides and cmsname is the name of the CMS.

� For the CMS for Windows NT, go to the drive\candle\CMS directory, where drive and candle are the drive and directory where the CMS resides.

For more information about the location of the CMS, see the Installing Candle Products and Candle Management Server on MVS manual.

3 Create a new file called KFAASITR, using any text editor.

Important: If you are using the CMS for AIX or Windows NT, be sure to specify the filename in uppercase letters.

The KFAASITR file is the situation trap table, even though it is empty at this point.

4 Add an entry for each alert emitter designating it as a destination for situation status change information. Each entry should look like this:

DESTNODE=alert_emitter_name;

Be sure to end each entry with a semicolon (;). “Situation Trap Table Tags” on page 107 provides details about using DESTNODE and the other tags. At this stage, you only need to use the DESTNODE tag as shown above.

When you finish adding an entry for each alert emitter at your site, your situation trap table should look something like this:

DESTNODE=AFREMOTE1:ARActions;DESTNODE=AFREMOTE2:ARActions;DESTNODE=AFREMOTE3:ARActions;

5 Save KFAASITR and exit the file.



Refreshing the Situation MonitorThe procedure for refreshing the Situation Monitor depends on the CMS type you are using.

1. To ensure that the alert automation environment is initialized, issue the following command from any MVS console:

F cms_job_name,CTDS START KFAAUTOX.KFAAINIT

Note: The alert automation enviroment enables the KFAASITR command to accept REFRESH, DISPLAY, and TESTSIT requests. This environment is initialized automatically at CMS startup the first time a situation occurs.

2. To refresh the CMS, issue the following command:F cms_job_name,CTDS KFAASITR REFRESH

3. To confirm the refresh, issue the following commandF cms_job_name,CTDS KFAASITR DISPLAY

Result: The current contents of the situation trap table will be displayed on the console.

Your next stepOnce you have refreshed the Situation Monitor, you should run a test of your situation trap table entries to ensure that information will be sent successfully to each alert emitter defined in the table.

The next section describes how you can simulate a situation status change for testing purposes.

CMS for MVS

CMS on other platforms

End of CMS for MVS

✒ You must restart the CMS to effect a refresh.

End of CMS on other platforms


Testing Your Situation Trap Table Entries (CMS for MVS Only)


IntroductionThis section describes how you can simulate a situation status change if you use the CMS for MVS.

If you use the CMS for MVS, you do not need to wait for an actual problem event to occur on a managed system to test your situation trap table entries.

ProcedureFollow the steps below to create a simulated situation status change.

1. To ensure that the alert automation environment is initialized, issue the following command from any MVS console:

F cms_job_name,CTDS START KFAAUTOX.KFAAINIT

Note: The alert automation enviroment enables the KFAASITR command to accept REFRESH, DISPLAY, and TESTSIT requests. This environment is initialized automatically after the first situation is detected.

2. Issue the following command:F cms_job_name,CTDS KFAASITR TESTSIT

This simulates a situation called TestSituation, which has been provided to test the connection from the CMS. Information about the simulated status change is sent to each alert emitter correctly specified in the situation trap table. The alert emitter passes the incoming information to a default action script. The default action script then takes a predefined action.

For example, the default script for the Alert Emitter for AF/REMOTE takes the information passed to it by the alert emitter and logs a message similar to:

KARDFACT test processing for TestSituation

KARDFACT ARG1= TestSituation

KARDFACT ARG2= 0960521070024000

KARDFACT ARG3= 0

KARDFACT ARG4= 1

KARDFACT ARG5= TESTNODE:TEST

KARDFACT ARG6= Test_Object.Test_Attrib1>80 Test_Object.TestAttrib2<100

If the status change information about TestSituation is displayed on the system running an alert emitter, that alert emitter is correctly specified as a DESTNODE in the situation trap table.



What is a default action script?Each alert emitter has a default action script that receives information passed to it by the alert emitter. The default action script takes action under conditions defined in the script. You can specify that a different script (or, for some alert adapters, a subagent) should receive the information, but unless you indicate otherwise, the information will go to the default action script.

“Customizing Your Automation” on page 103 discusses, in more detail, the data sent to this and other sample command scripts. “Default scripts” on page 118 lists the default script names for various alert emitters.

Your next stepYou have now confirmed that your situation trap table entries are correct, and that the default action script is receiving information from the alert emitter. At this point, however, every alert emitter sends information for each status change. There is no filtering at the CMS level or at the command script level.

Your next step is to learn more about filtering. The following section introduces filtering at the command script level.


Filtering Out Unwanted Alert Information


IntroductionThis section describes how to add conditional statements to a default action script. Use these conditional statements to specify when the default action script should respond to incoming alert information.

Note: As an alternative, you can add to the situation trap table information that will restrict or modify the alert information sent to the alert emitter. This approach to automation is more advanced than altering the command script. It may or may not be the best choice at first for the automation needs of your site. See “Customizing Your Automation” on page 103 for details.

ProcedureEach of the default action scripts includes a conditional IF statement that tests the incoming alert information for a specific situation name. The example below shows a segment from KARDFACT, the default action script for the Alert Emitter for AF/REMOTE.

You can copy this statement and modify it to specify the names of situations on which you want to take action. By default, the situation name is the first argument passed. Therefore, you should modify the IF statement to test whether the first argument equals the name of a situation on which you want to take action.

For example:

/* REXX PROGRAM KARDFACT */...IF arg.1 = ‘TestSituation’ THEN stat = AFR_LOG(program_name ‘test processing for TestSituation’)ELSE stat = AFR_LOG(program_name ‘entered’)...

/* REXX PROGRAM MODIFIED KARDFACT */... IF arg.1 = ‘AFR_down_CRITICAL’ THENDO...END IF arg.1 = ‘AFR_down_COL11_CRITICAL’ THENDO...ENDELSE stat = AFR_LOG(program_name ‘entered’)...

Customizing Your Automation 103

Customizing Your Automation

IntroductionThis chapter presents examples of customizing the situation trap table to supply the correct data to the sample scripts.

Customizing allows you to send only the data of interest to specific alert emitters on the systems you want to contact. For example, you can customize the situation trap table to execute a specific script in response to a specific situation. You can send up to 9 parameters (ARG1 through ARG9) to the script you specify. For a complete list of tags that can be used in the situation trap table, and their syntax, see “Situation Trap Table Tags” on page 107.

If you customize the data sent, you will also need to customize the command script which receives the data. You can copy and modify the sample scripts provided with the alert emitter to meet the requirements of your site.

Chapter ContentsPerformance Considerations of Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Specifying Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

9

Performance Considerations of Customization


Performance Considerations of Customization

OverviewIn the simple implementation of alert emitter automation, alert information is not filtered at the CMS level. Instead, filtering is performed by the command script. For example, a command script may receive all 6 default arguments from the CMS trap table and then use only some of that information. Elaborate IF statements can be added to a default command script to filter by situation name, then trigger command scripts that take an action appropriate to the event.

It may be tempting to perform all filtering at the command script level because the script library is easily accessed. This is certainly the easiest method while scripts are being tested and refined. The most efficient method is to modify the situation trap table to send only the necessary information.

Disadvantages of filteringThe disadvantages of filtering at the CMS level are:

� the trap table is somewhat harder to maintain, because it is centrally administered

� modifications to the trap table require a refresh of the CMS Situation Monitor (as described in “Refreshing the Situation Monitor” on page 98).

Customizing Your Automation 105

Specifying Arguments


IntroductionThis section describes how you specify arguments.

If you do not specify argumentsWhen no ARGn= values are specified in the situation trap table and a situation is trapped, six default items of information are passed as positional arguments to the alert emitters listed in the table. By default, the information sent is:

ARG1=SITNAME

ARG2=TIMESTAMP

ARG3=PRESTATE

ARG4=CURRSTATE

ARG5=NODE

ARG6=THRESHOLD

If this information is sufficient, then you do not need to specify arguments.

The default command script delivered with your alert emitter is set up to receive the six default arguments but will parse up to nine arguments.

Specifying attribute names as argumentsThe following situation trap table entry, for a situation named EXAMPLE, illustrates the proper way to specify attribute names in an argument list.

SITNAME=EXAMPLE DESTNODE=AFREMOTE1:ARActions

SCRIPT=TEST123

ARG1=Line_Mode_Console.Target_Text_1


ARG3=Line_Mode_Console.Message_Text

ARG4=Line_Mode_Console.Timestamp

;

Note that each attribute is specified as a fully qualified attribute name in the form:

group_name.attribute_name

This is the way attribute names appear in a managed object on the Candle Management Workstation desktop when, after an event has occurred, you first Open as Events and then Open as Attributes.

Situation Trap Table Tags 107

Situation Trap Table Tags

IntroductionThis chapter describes how to create entries in the situation trap table.

Each time the status of a situation changes, the CMS checks the situation trap table to see whether action should be taken, and if so, what action.

Chapter ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107The Situation Trap Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108The SITNAME Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109The ORIGINNODE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111The STATE Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113The DESTNODE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115The CALLTYPE Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117The SCRIPT and SUBAGENT Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118The ARGn Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

10

The Situation Trap Table


The Situation Trap Table

IntroductionThis section describes the situation trap table.

The situation trap table file: KFAASITRThe situation trap table is a text file (or member) that you create with any text editor. You must name the file KFAASITR and save it to a specified location:

� For the CMS for MVS, save KFAASITR to the &rhilev.RKANPAR runtime parameter library.

� For the CMS for Unix, save KFAASITR to the candle/cms/tables/cmsname directory, where candle is the directory where the CMS resides and cmsname is the name of the CMS.

� For the CMS for Windows NT, save KFAASITR to the candle\CMS directory, where candle is the drive where the CMS resides.

See “Creating the situation trap table” on page 97 for the complete procedure. For more information about the location of the CMS, see the Installing Candle Products and Candle Management Server on MVS manual.

Rules for using situation trap table tagsWhen you create entries in the situation trap table, follow these rules:

� You can use any text editor to create and modify the KFAASITR file.

� Only the DESTNODE tag is required.

� Each tag=value entry must be separated by one or more blank spaces.

� Do not use any blank spaces between the tag, the equals sign (=), and the value.

� If you specify a value that includes embedded blanks, you must enclose the value in double quotes (“ “).

� You must terminate each complete entry with a semi-colon (;).

� If you specify an asterisk (*) in column 1, that line will be ignored; you can use these lines for comments in the file.

Individual tags have their own specific rules as described in the remainder of this chapter.


The SITNAME Tag

The SITNAME Tag

IntroductionThis section describes the SITNAME tag.

DescriptionThe SITNAME tag enables you to specify actions for particular situations. Although this tag is optional, you can specify the SITNAME tag to limit the number of alerts sent to the alert emitters. This will help to reduce overall CPU and network overhead.

If the status of a situation changes and CMS finds no entries for that situation in the trap table, no further action is taken.

Specifying a situation nameTo specify a situation name, use the format:

SITNAME=situation_name

SITNAME tag rulesWhen you use the SITNAME tag, follow these rules:

� Use up to 32 characters.

� If you specify the asterisk wildcard (see below) as the situation name, the entry will match any situation.

� The default value for this tag is:

SITNAME=*

Using the asterisk wildcardYou can create a single table entry that applies to multiple situations by specifying a pattern for the situation name. To create a pattern, use an asterisk (*) as a wildcard character in your situation name. For example, by specifying:

SITNAME=High_CPU*

you would match situations named:

High_CPU_for_CICS

High_CPU_for_MVS

but not:

CPU_High

You can use the asterisk wildcard as a leading, trailing, or embedded character in the situation name. Use no more than one wildcard in your situation name.

The SITNAME Tag


ExampleThe example below would apply to any situation with a name beginning with “Disk_Failure” and assigned to the managed system SERVER12:NT.

SITNAME=Disk_Failure*

ORIGINNODE=SERVER12:NT

DESTNODE=AFREMOTE1:ARActions;

Note that this entry does not specify any arguments with the ARGn tag. Therefore, the CMS will send the default set of arguments to the alert emitter on the destination system. The first default argument is the situation name (SITNAME). From this, the script or subagent invoked by the alert emitter can determine which of the Disk_Failure situations actually changed status. See “Arguments passed by default” on page 122 for details.


The ORIGINNODE Tag

The ORIGINNODE Tag

IntroductionThis section describes the ORIGINNODE tag.

DescriptionUse the ORIGINNODE tag to specify the managed system name associated with the action you want to take. Although this tag is optional, you can specify the ORIGINNODE tag to limit the number of alerts sent to the alert emitters. This will help to reduce the overall CPU and network overhead.

If the status of a situation changes due to events on a managed system, and CMS finds no entries for that managed system in the trap table, no further action will be taken.

Specifying a managed system nameTo specify a managed system name, use the format:

ORIGINNODE=managed_system_name

ORIGINNODE tag rulesWhen you use the ORIGINNODE tag, follow these rules:


� If you specify the asterisk wildcard (see below) as the managed system name, the entry will match any managed system.

� The default value for this tag is:

ORIGINNODE=*

Using the asterisk wildcardYou can create a single table entry that applies to multiple managed systems by specifying a pattern for the name. To create a pattern, use an asterisk (*) as a wildcard character in your managed system name. For example, by specifying:

ORIGINNODE=REDWOOD:*

you would match managed systems named:

REDWOOD:UNIX

REDWOOD:SYBASE

but not:

SNMP:REDWOOD

You can use the asterisk wildcard as a leading, trailing, or embedded character in the managed system name. Use no more than one wildcard in your managed system name.

The ORIGINNODE Tag


ExampleThe example below shows a trap table entry for the situation Disk_Failure on any managed system with a name that ends with “:NT.”

SITNAME=Disk_Failure

ORIGINNODE=*:NT

DESTNODE=AFREMOTE1:ARActions

SCRIPT=RESTORE

ARG1=NT_Logical_Disk.Server_Name ARG2=NODE;

The use of the wildcard character with the ORIGINNODE tag makes it possible to apply this single entry to multiple managed systems. If this entry matches the name and managed system of a detected situation, the actual ORIGINNODE name for the event will be passed as the second argument (ARG2) to the script RESTORE.


The STATE Tag

The STATE Tag

IntroductionThis section describes the STATE tag.

DescriptionYou can define situations that represent satisfactory or problem conditions. When the status of a situation changes to TRUE, this may be good news or cause for concern. Use the STATE tag to indicate when a status change should trigger action.

Specifying a new situation stateTo specify a new situation state, use the format:

STATE=new_situation_state

STATE tag rulesWhen you use the STATE tag, specify one of the following values:

The default value for this tag is:

STATE=TRUE

TRUE to take action when the situation is true

FALSE to take action when the situation is not true (or is reset)

UNKNOWN to take action when the situation state is unknown

* to take action when any status change occurs

The STATE Tag


ExampleThe example below shows a trap table entry for the situation Server_not_Resp on managed system NFSERVER:UNIX.

SITNAME=Server_not_Resp

ORIGINNODE=NFSERVER:UNIX


STATE=UNKNOWN

SCRIPT=BEEPER

ARG1=SITNAME ARG2=TIMESTAMP ARG3=NODE ARG4=CURRSTATE

ARG5=”(310)555-4455” ARG6=”Bob Smith”;

This example illustrates how to notify someone automatically if communication between a managed system and the CMS is disrupted. When the state of situation Server_not_Resp becomes unknown, the CMS passes arguments that provide information about the event and the name and beeper number of the person to notify. The alert emitter AFREMOTE1:ARActions will include these arguments when invoking a user-created automation script named BEEPER.


The DESTNODE Tag

The DESTNODE Tag

IntroductionThis section describes the DESTNODE tag.

DescriptionThe DESTNODE tag specifies the name of the alert emitter that should receive information about situation status changes. Each entry in the situation trap table must include the DESTNODE tag so the CMS will know where to send the event information.

You can use the DESTNODE tag by itself or combine it with other tags. If you use the DESTNODE tag by itself, the CMS will send a default set of arguments to the alert emitter whenever any situation changes status. “Arguments passed by default” on page 122 describes these values. Alternatively, you can narrow the criteria for sending information to an alert emitter by combining the DESTNODE tag with other tags.

Name formats for alert emittersWhen you check the CMW Managed Systems folder for an active alert emitter, you can identify the alert emitter type by the format of its name.

When you use the DESTNODE tag and specify the name of an alert emitter, use the full name exactly as displayed in the Managed Systems folder.

Specifying the destination alert emitterTo specify a new situation state, use the format:

DESTNODE=destination_alert emitter

Be sure to specify the full name as described in “Name formats for alert emitters” on page 115.

Table 2.






The DESTNODE Tag


DESTNODE tag rulesWhen you use the DESTNODE tag, follow these rules:


� The DESTNODE tag is required for each entry in the situation trap table.

� Specify the name of an active alert emitter started on the destination system. You can find the valid names of active alert emitters in the CMW Managed Systems folder. These names are case sensitive and must be specified on the DESTNODE tag exactly as they appear in the Managed Systems folder.

� You cannot specify wildcard characters with this tag.

� There is no default value for the DESTNODE tag.

ExampleThe example below shows a trap table entry for the situation Server_not_Resp on managed system NFSERVER:UNIX. Based on the format of the DESTNODE value, AFREMOTE1:ARActions, you can see that action would be taken by the Alert Emitter for AF/REMOTE on the AF/REMOTE host PC AFREMOTE1.




SCRIPT=BEEPER

ARG1=SITNAME ARG2=TIMESTAMP ARG3=NODE ARG4=CURRSTATE

ARG5=”(310)555-4455” ARG6=”Bob Smith”;


The CALLTYPE Tag

The CALLTYPE Tag

IntroductionThis section describes the CALLTYPE tag.

DescriptionThe CALLTYPE tag specifies which call mechanism the CMS will use in forwarding information to an alert emitter. The choice of call mechanism determines what kind of action the alert emitter will take.

Specifying the call mechanismTo specify a call mechanism, use the format:

CALLTYPE=calltype_integer_value

CALLTYPE tag rulesWhen you use the CALLTYPE tag, specify the value appropriate for your purpose as described below:

1. For alert emitter automation, use calltype 0.

2. For alert delivery to a subagent, use the non-zero calltype that corresponds to a particular subagent. See the subagent documentation for details about what calltype to use.The default value for this tag is:

CALLTYPE=0

ExampleThe example below shows a Trap Table entry for the situation Server_not_Resp on managed system NFSERVER:UNIX.




CALLTYPE=0

SCRIPT=BEEPER

ARG1=SITNAME ARG2=TIMESTAMP ARG3=NODE

ARG4=”(310)555-4455” ARG5=”Bob Smith”;

When this situation changes status, the CMS will issue a system call that invokes a user-created script on the destination system. The system call will include the arguments specified with the ARGn tags.

The SCRIPT and SUBAGENT Tags



IntroductionThis section describes the SCRIPT and SUBAGENT tags.

DescriptionThe SCRIPT and SUBAGENT tags enable you to specify the name of the program that the alert emitter should invoke on the destination system. These two tags are interchangeable; however, you may want to use both as appropriate to make it easier to remember which entries are for automation scripts and which are for another purpose that requires a subagent.

Default scriptsIf you do not use the SCRIPT or SUBAGENT tag to specify a program, a default script will be invoked by the alert emitter.

These default scripts filter the data sent by the CMS by situation name and managed system name. If a match is found, the data sent by the CMS is passed to one of the product-supplied scripts.

You can edit these default scripts as needed.

Specifying a script or subagentTo specify a program for your script or subagent use the format:

SCRIPT=program_name

or

SUBAGENT=program_name

Script Name Alert Emitter

KOGDFACT Alert Emitter for OG/MVS

KARDFACT Alert Emitter for AF/REMOTE®



SCRIPT and SUBAGENT tag rulesWhen you use the SCRIPT or SUBAGENT tag, follow these rules:

� Specify a program name of up to 8 characters.

Note: AF/REMOTE for OS/2 appends the .REX extension to the program name, not the .CMD extension as is the default for REXX scripts running under OS/2.

� The program you specify must have authority to issue any commands executed by the alert emitter or invoked by the script.

ExampleThe example below shows a Trap Table entry for the situation Disk_Failure on managed system NTFSERVER:NT.

SITNAME=Disk_Failure

ORIGINNODE=NTFSERVER:NT


SCRIPT=RESTORE

ARG1=NT_Logical_Disk.Server_Name;

When situation Disk_Failure changes status, the alert emitter on the destination system will pass the incoming alert information to the script RESTORE.

The ARGn Tag


The ARGn Tag

IntroductionThis section describes the ARGn tag.

DescriptionYou can use the ARGn tag to send situation attribute values or other information to the script or subagent on the destination system. The CMS passes these values as positional arguments enclosed in quotes. The value of the tag suffix n is an integer between 1 and 9, indicating the position of the arguments.

Passing alert dataWhen a situation changes status, the CMS checks for a corresponding entry in the Trap Table. If the CMS finds an entry and that entry includes ARGn tags with alert attributes, the CMS assigns to the alert attributes values specific to the situation status change. This way, the command string sent to the destination system can include useful information about a specific status change.

You can use a set of predefined alert attributes to pass alert data to a script or subagent. When an event occurs that generates an alert, different kinds of information about that alert are stored in the alert attributes. Unlike situation attributes, alert attributes can be used in any combination and can pass alert data about any managed system. Use alert attributes with the ARGn tag.


The ARGn Tag

Predefined alert attributes for the ARGn tagPredefined alert attributes you can assign to the ARGn tag are:

SITNAME The name of the situation that changed status.

TIMESTAMP The date and time of the status change. The timestamp format is:

cyymmddhhmmssmmm

where:

c=century (0=20th)

y=year

m=month

d=day

h=hour

m=minute

s=second

m=millisecond

For example, 0960601080000000 indicates that the status change occurred on June 1, 1996, at 8:00 a.m.

PRESTATE The status of the situation before an event caused a status change. An integer indicates the previous status, where:

0 The previous status of the situation was UNKNOWN.

1 The previous status of the situation was TRUE.

2 The previous status of the situation was FALSE.

CURRSTATE The current status of the situation. An integer indicates the current status, where:

0 The current status of the situation is UNKNOWN.

1 The current status of the situation is TRUE.

2 The current status of the situation is FALSE.

The ARGn Tag


Specifying argumentsTo specify positional arguments use the following formats as applicable:

ARG1=alert_attribute_name

for specifying alert attributes

ARG1=attribute_group.situation_attribute_name

for specifying situation attributes

ARG1=”literal_value”

for specifying values that should be passed exactly as written.

Arguments passed by defaultIf you do not assign any values to the ARGn tag, the CMS will pass the following set of arguments by default:

ARG1=SITNAME

ARG2=TIMESTAMP

ARG3=PRESTATE

ARG4=CURRSTATE

ARG5=NODE

ARG6=THRESHOLD

NODE The ORIGINNODE name of the managed system on which the event occurred.

THRESHOLDS A string of predicate information associated with the situation when its status is true. Your script or subagent can use this information to determine the circumstances that caused the situation status change.

Important: The CMS passes predicate information only when the current state of a situation is true. When the state of a situation changes to false (CURRSTATE=2), the CMS passes a null string in the place of event-specific situation predicates.

The value of each attribute in the situation predicate is passed in the string. Each attribute is represented in the string by three values: the attribute name, a relational operator, and the value of the attribute specified in the situation.

For example, if a situation predicate included the attribute Job_Name, the string sent as part of THRESHOLDS might include something like this:

JOB_NAME=IMSPROD2


The ARGn Tag

ARGn tag rulesWhen you use the ARGn tag, follow these rules:

� Use up to 32 characters for each ARGn tag in your entry.

� The command comprised of the script or subagent name plus all the argument values must be no longer than 600 bytes. Specific alert emitters may have further restrictions. For example, the Alert Emitter for AF/REMOTE restricts the total number of bytes that can be passed as arguments to a REXX script to 242 or fewer.

� Any value you enclose in double quotes (“ ”) will be passed exactly as specified.

� If you use an invalid attribute with an ARGn tag, the name of the invalid attribute itself will be passed in the command string.

� Numeric values will be converted to decimal characters and passed in character arguments.

� Bitstrings will be converted to printable hexadecimal characters in the form

0xhhhhhhh

where h is 0-9 and A-F.

� Double quotes (“) used in substituted values will be converted to a single quote (‘).

� Null terminator characters (0x00) used in substituted values will be converted to blanks.

� If you specify an attribute as an argument, you must prefix the attribute name with the group from which that attribute comes. For example, you would specify the Target_Text_1 attribute from the Line_Mode_Console group as shown below:


The ARGn Tag


ExampleThe example below shows a Trap Table entry for the situation Server_not_Resp on managed system NFSERVER:UNIX.




SCRIPT=BEEPER

ARG1=SITNAME ARG2=TIMESTAMP ARG3=NODE


ARG5=”(310)555-4455” ARG6=”Bob Smith”;

Note that the ARGn tags for this entry specify both alert attributes (SITNAME, TIMESTAMP, NODE) and literal values enclosed in double quotes.

When this situation changes status, the alert emitter on the destination system will receive arguments similar to the following

“Server_not_Resp” “0960318183456000” “NFSERVER:UNIX”

“NFS I/O ERROR” “(310)555-4455” “Bob Smith”

The alert emitter AFREMOTE1:ARActions will include these arguments when invoking a user-created script named BEEPER.

Guide to Candle Customer Support 125

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126– 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130– Assigned Support Center Representative (ASCR)

– Maintenance Assessment Services (MAS)

– Multi-Services Manager (MSM)

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

A

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:

� Unlimited multi-language defect, installation and operations support

� eSupport using the World Wide Web

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

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

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

� 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

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

AAdobe portable document format 7AFR_Sample template 64alert adapter 19, 20, 22, 27–28, 29–30, 37, 38, 86

AF/REMOTE startup 29–30configuring 19–35, 37–49multiple from an icon 27–28name format 32, 49name in Managed Systems folder 32, 49overview 12prerequisites 19, 37starting 25–26stopping 31TCP/IP connection 20, 38, 86verifying connection to the CMS 32–33, 48–49,

93worksheet 23, 39, 87

alert dapterSNA connection

Communications Manager connection 22alert emitter 75, 76, 77, 79, 85

at AF/REMOTE startup 79configuring 75–81, 85–93migrating from previous releases 82name format 33, 49, 115name in Managed System folder 33name in Managed Systems folder 49overview 13–14prerequisites 75, 85SNA connection

Communications Manager connection 77starting 78stopping 78TCP/IP connection 76verifying connection to the CMS 32–33, 48–49,

93worksheet 79

ARGn tag 120–124ASCR

assigned support center representative 130assigned support center representative

ASCR 130ation 108attibutes 12attributes 51–61

Fullscreen_Mode_Console group 53–57Line_Mode_Console group 58–61

mixing with other groups 12

BBegin_Column attribute 53Begin_Column_1 attribute 58Begin_Column_2 attribute 59Begin_Row attribute 54

CCALLTYPE tag 117Candle Management Server

verifying connection 32–33, 48–49, 93cellname 23CMS name variable 39, 87CMS port number variable 39, 87command scripts

see scripts, product-providedCommunications Manager 22, 77configuring 19, 20, 22, 37, 38, 75, 76, 77, 85, 86

alert adapter 19–35, 37–49alert emitter 75–81, 85–93prerequisites 19, 37, 75, 85SNA connection

Communications Manager connection 22, 77TCP/IP connection 20, 38, 76, 86

Configuting 75ctira_cell_name variable 23, 79CURRSTATE alert attribute 121customer support

base maintenance plan 126contact information 132enhanced support services 130eSupport 127severity levels 127telephone support 126

DDESTNODE tag 115–116

Eems 49eSupport

customer support 127execs

see scripts, product-provided

Index


Ffor 19from 25Fullscreen_Mode_Console attributes 53–57

Hhost name or IP address variable 39, 87host session name variable 39

KKFAASITR file

see situation trap table

LLine_Mode_Console attributes 58–61LU6.2 22, 77

Mmaintenance assessment service

MAS 130managed objects, migrating 34–35Managed_System_Name attribute

Fullscreen_Mode_Console group 54Managed_Sysytem_Name attribute

Line_Mode_Console group 59MAS

maintenance assessment service 130Message_Text attribute 59migrating

alert emitter 82situation trap table 82situations

managed objects 34MSM

multi-services manager 130multi-services manager

MSM 130

Nname format

alert adapter 32, 49alert emmiter 33, 49, 115

NODE alert attribute 122NODEID 23, 79

OORIGINNODE tag 111–112

Pplan 26port variable 23, 79

PRESTATE alert attribute 121printing problems 7Product 65product-provided situations 12, 65–72product-provided templates 64

Rrefreshing the CMS 98requirements, software 15Return_Column attribute 54Return_Length attribute 55Return_Row attribute 55Return_Text attribute 55REXX execs

see scripts, product-providedRKANPAR dataset 22, 23, 77, 79Row_Number attribute

Fullscreen_Mode_Console group 56Line_Mode_Console group 59

SSample_Number attribute

Fullscreen_Mode_Console group 56Line_Mode_Console group 60

Scan_Length attribute 56SCRIPT tag 118–119section 93session_name variable 23severity levels

customer support 127SITNAME alert attribute 121SITNAME tag 109–110Situation 108situation 72situation trap

overview 108rules 108

situation trap table 14, 108migrating from previous releases 82tags 108–124

situationsmigrating from previous release 34–35product-provided 63–72

situations, product-provided 12SMFID 23, 79SNA 22, 77software requirements 15starting 27, 28, 29, 30, 79

AF/REMOTE startup 29–30alert adapter 25–26alert emitter 78at AF/REMOTE startup 79

Index 135

multiple from an icon 27–28STATE tag 113stopping

alert adapter 31alert emitter 78

SUBAGENT tagsee SCRIPT tag

Ttags, situation trap table 107–124Tandem_Sample template 64Target_Text attribute 57Target_Text_1 attribute 60Target_Text_2 attribute 60TCP/IP 20, 38, 76, 86telephone support

customer support 126templates, product provided 64THRESHOLDS alert attribute 122TIMESTAMP alert attribute 121Timestamp attribute 57, 61trap table tags 107–124

Vverifying your configuration 33, 48–49, 93VTAM 22, 77

Wworksheets

alert adapter 39, 87alert emitter 79

worlsheetsalert adapter 23

configuration and customization guide -...

Documents