Version 2.1 May 28, 1998publib.boulder.ibm.com/tividd/td/TMB/tmb21/en_US/PDF/tmb21.pdf · Tivoli Module Builder User’s Guide Version 2.1 May 28, 1998. Tivoli Module Builder User’s

Tivoli Module Builder User’s Guide

Version 2.1

May 28, 1998

Tivoli Module Builder User’s Guide (May, 1998)Copyright NoticeCopyright © 1998 by Tivoli Systems, an IBM Company, including this documentation and all software.All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement orAddendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication maybe reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computerlanguage, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, orotherwise, without prior written permission of Tivoli Systems. The document is not intended forproduction and is furnished “as is” without warranty of any kind.All warranties on this document arehereby disclaimed including the warranties of merchantability and fitness for a particular purpose.

Note to U.S. Government Users—Documentation related to restricted rights—Use, duplication ordisclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.

TrademarksThe following product names are trademarks of Tivoli Systems or IBM Corporation: AIX, IBM, OS/2,RS/6000, Tivoli Management Environment, TME 10, Tivoli Global Enterpise Manager, TME 10Distributed Monitoring, TME 10 Enterprise Console, TME 10 Framework, Tivoli Module Builder, andTivoli Module Designer.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks or registered trademarks ofMicrosoft Corporation.

UNIX is a registered trademark in the United States and other countries licensed exclusively throughX/Open Company Limited.

Java and Hot Java are trademarks of Sun Microsystems, Inc.

Other company, product, and service names mentioned in this document may be trademarks orservicemarks of others.

NoticeReferences in this publication to Tivoli Systems or IBM products, programs, or services do not imply thatthey will be available in all countries in which Tivoli Systems or IBM operates. Any reference to theseproducts, programs, or services is not intended to imply that only Tivoli Systems or IBM products,programs, or services can be used. Subject to Tivoli Systems’ or IBM’s valid intellectual property or otherlegally protectable right, any functionally equivalent product, program, or service can be used instead ofthe referenced product, program, or service. The evaluation and verification of operation in conjunctionwith other products, except those expressly designated by Tivoli Systems or IBM, are the responsibilityof the user.

Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in thisdocument. The furnishing of this document does not give you any license to these patents. You can sendlicense inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue,Thornwood, New York 10594.

Portions copyright 1996 Shafir, Inc.

Tivoli Module Builder User’s Guide i

Tivoli Module BuilderUser’s Guide

Preface.................................................................................................................. vii

Part I—Understanding the Tivoli Module Builder

Chapter 1—OverviewApplication and Business Systems Management ...............................................1-2

Management Data.......................................................................................1-2

Defining an Application for Tivoli Enterprise Software............................1-3

Defining a Business System for Tivoli Enterprise Software......................1-4

Base Modules......................................................................................................1-5

Modules for Tivoli Partner Association Certification ........................................1-5

Plus Modules ..............................................................................................1-6

Tivoli GEM Modules .................................................................................1-6

Understanding the Tivoli Module Builder ..........................................................1-7

Workflow for Creating Modules ................................................................1-7

Tivoli Module Designer .............................................................................1-8

Tivoli Module Builder Workspace.............................................................1-8

Launching the Tivoli Module Builder ................................................................1-9

Understanding the Workspace Object Hierarchy..............................................1-10

Understanding Variables and Settings ..............................................................1-11

Editing Settings ........................................................................................1-12

Editing CDF and GDF Variables .............................................................1-13

Understanding Script Stubs and Skeleton Files ................................................1-15

ii Version 2.1

Chapter 2—Creating Base ModulesCreating the Project ............................................................................................ 2-2

Adding a Module to the Project.......................................................................... 2-3

Adding and Importing Components into a Module ............................................ 2-4

Adding an AMS Component...................................................................... 2-5

Importing a Component Description File .................................................. 2-7

Editing the Module’s Components ..................................................................... 2-9

Launching from the Module Level .......................................................... 2-10

Launching from the Component Level .................................................... 2-11

Launching from Lower-level Objects ...................................................... 2-11

Specifying Before and After Installation Scripts.............................................. 2-12

Before Install Scripts................................................................................ 2-13

After Install Scripts .................................................................................. 2-14

Generating the Module and Other Objects ....................................................... 2-14

Editing the Generated Scripts and Skeleton Files............................................. 2-16

Editing Script Stubs.................................................................................. 2-17

Editing the Default Skeleton Files ........................................................... 2-18

Creating New Skeleton Files.................................................................... 2-18

Specifying Skeletons for Generating Scripts ........................................... 2-19

Testing the Scripts ............................................................................................ 2-19

Editing Testdata Files............................................................................... 2-20

Running Tests........................................................................................... 2-21

Building the Installable Image.......................................................................... 2-21

Chapter 3—Defining the Base Module’s FeaturesPrerequisites........................................................................................................ 3-2

Defining Component Data.................................................................................. 3-3

Tivoli Module Builder User’s Guide iii

Defining File Distribution (File Lists) ................................................................3-4

Defining Installation Dependencies....................................................................3-8

Defining Operational Tasks ..............................................................................3-10

Defining Synchronous Monitors.......................................................................3-12

Using the Predefined Monitors.................................................................3-12

Specifying the Collection Name for Predefined Monitors.......................3-13

Creating a Monitor ...................................................................................3-16

Creating a Monitor Instance.....................................................................3-20

Chapter 4—Installing and Uninstalling Base ModulesSpecifying the Tivoli Installation Directory .......................................................4-1

Installing Base Modules......................................................................................4-2

Uninstalling Base Modules .................................................................................4-4

Base Modules in the Tivoli Environment ...........................................................4-4

Part II—Tivoli Partner Association Plus Modules

Chapter 5—Introduction to Plus ModulesLoading the Plus Module Template....................................................................5-2

Plus Module Component Types..........................................................................5-4

Icons for <App Name>...............................................................................5-5

Launch <App Name>.................................................................................5-5

Set Install Options for <App Name>..........................................................5-5

Plus Configuration for <App Name>.........................................................5-5

Subscribers of <App Name>......................................................................5-5

Administrative Tasks for <App Name>.....................................................5-6

Client Filepack Distribution for <App Name> ..........................................5-6

Server Filepack Distribution for <App Name>..........................................5-6

iv Version 2.1

Ancillary Filepack for <App Name> ......................................................... 5-6

Indicators for <App Name> Monitors ....................................................... 5-6

Universal Monitors..................................................................................... 5-7

Monitors for <App Name> ........................................................................ 5-7

TEC Configuration for <App Name> ........................................................ 5-7

Logfile Adapter Configuration for <App Name> ...................................... 5-7

Hidden Tasks for <App Name> ................................................................. 5-7

Component Definition Categories ...................................................................... 5-8

Location Definitions................................................................................... 5-9

File List .................................................................................................... 5-10

Installation Programs ............................................................................... 5-10

Installation Dependencies ........................................................................ 5-10

Operational Tasks..................................................................................... 5-10

Synchronous Monitors ............................................................................. 5-10

Management Tool Extensions.................................................................. 5-11

Plus Modules in the Tivoli Management Software Environment..................... 5-11

Activating the Plus Module’s Features............................................................. 5-14

Chapter 6—Application IconsPrerequisites........................................................................................................ 6-2

Editing the Application Icons Component.......................................................... 6-3

Chapter 7—Application LaunchPrerequisites........................................................................................................ 7-2

Editing the Application Launch Component ...................................................... 7-2

Tivoli Module Builder User’s Guide v

Chapter 8—Install OptionsPrerequisites........................................................................................................8-2

Editing the Install Options Component...............................................................8-2

Chapter 9—Plus ConfigurationPrerequisites........................................................................................................9-2

Editing the Plus Configuration Component ........................................................9-2

Chapter 10—Subscription ListsPrerequisites......................................................................................................10-2

Editing the Subscription List Component.........................................................10-3

Chapter 11—Administrative TasksPrerequisites......................................................................................................11-2

Editing the Administrative Tasks Component ..................................................11-3

Chapter 12—File PackagesPrerequisites......................................................................................................12-3

Editing the File Package Component................................................................12-3

Chapter 13—Indicator CollectionsPrerequisites......................................................................................................13-2

Editing the Indicator Collection Component ....................................................13-2

Chapter 14—MonitorsPrerequisites......................................................................................................14-3

Editing the Monitors Component......................................................................14-3

Creating a New Monitor .................................................................................14-14

Creating a Monitor Instance............................................................................14-20

Using Additional Predefined Monitors...........................................................14-27

vi Version 2.1

Chapter 15—TME 10 Enterprise Console ConfigurationPrerequisites...................................................................................................... 15-3

Editing the TEC Configuration Component ..................................................... 15-3

Chapter 16—Logfile Adapter ConfigurationPrerequisites...................................................................................................... 16-2

Editing the Logfile Adapter Configuration Component ................................... 16-3

Chapter 17—Hidden TasksPrerequisites...................................................................................................... 17-2

Editing the Hidden Tasks Component .............................................................. 17-2

Glossary

Preface

Tivoli Module Builder User’s Guide vii

PrefaceTheTivoli Module Builder User’s Guide describes using the TivoliModule Builder to create modules for managing an application in theTivoli Enterprise software environment. The Tivoli Module Builderprovides the base facilities and templates for defining an application’smanagement requirements and building this information, along withthe scripts, programs, and files required to implement the managementfunction, into a Tivoli installable image.

The following describes the types of management modules that can becreated with the Tivoli Module Builder.

Base ModulesA base module describes an application’s management requirementsfor the Tivoli management tools. This information, along with thescripts and programs that implement the management functions, isbuilt into a Tivoli installable image.

Plus ModulesPlus modules are required for certification by the Tivoli PartnersAssociation. A Plus module provides a high-level integration of anapplication with the Tivoli management tools. The application’smanagement information, along with the scripts and programs forintegrating the application with the Tivoli environment, is built into aTivoli installable image.

Tivoli Global Enterprise Manager ModulesTivoli Global Enterprise Manager (Tivoli GEM) modules are alsorequired for certification by the Tivoli Partners Association. Thesemodules enable an application to be managed in the context of abusiness system with the Tivoli Global Enterprise Manager (TivoliGEM). The module’s management information, along with the scriptsand programs that implement the management functions, is built intoa Tivoli installable image.

Preface

viii Version 2.1

Who Should Read This GuideDevelopers who are creating management modules are the targetaudience for this guide.

Users of this guide should have knowledge of the following:

■ The management requirements and features of the application forwhich you are building a management module. For example, youshould understand those aspects of the application that are proneto failure or whose function can be facilitated by the TivoliManagement Software tools. You should also be familiar withyour application’s administrative tasks as well as any logfiles orAPIs that your application offers for retrieving status andperformance data.

■ Shell programming.

■ Application Management Specification (AMS)

■ The Tivoli Enterprise software environment, including TME 10Framework, TME 10 Software Distribution, TME 10 DistributedMonitoring, and TME 10 Enterprise Console. (See “Prerequisiteand Related Documents” on page viii.)

Prerequisite and Related DocumentsManagement modules interact with various management tools in theTivoli Management Software environment. You may need to refer tothe documentation for these tools when creating a managementmodule.

The Tivoli Module Builder uses file types defined in the ApplicationManagement Specification (AMS). For more information on thesefiles, and on requirements for defining the management requirementsof applications and business systems, download the AMS from theTivoli Web site atwww.tivoli.com.

Preface

Tivoli Module Builder User’s Guide ix

What This Guide ContainsTheTivoli Module Builder User’s Guide contains the followingsections:

■ Part I — Understanding the Tivoli Module Builder

• Chapter 1, “Overview”Provides conceptual information for understandingapplications and business systems management and for usingthe Tivoli Module Builder to create a management module.

• Chapter 2, “Creating Base Modules”Provides a workflow of the basic tasks required to create aBase module. This chapter includes information on thegraphical user interface (GUI) features that assist you incompleting these tasks.

• Chapter 3, “Defining the Base Module’s Features”Describes how to edit a component with the Tivoli ModuleDesigner in order to define the Base module’s managementfeatures.

• Chapter 4, “Installing and Uninstalling Base Modules”Describes how to install and uninstall Base modules as wellas the objects that appear on the Tivoli Desktop after moduleinstallation.

■ Part II — Tivoli Partner Association Plus Modules

• Chapter 5, “Introduction to Plus Modules”Introduces the Plus template provided with the TivoliModule Builder. This chapter describes how to load the Plustemplate, the component types provided with the Plustemplate, and the categories of information that you specifyto complete a component definition.

• Chapter 6, “Application Icons”Describes how to specify that an application’s icon be usedfor the Plus module and the application launch task.

• Chapter 7, “Application Launch”Describes how to create a task for launching an application.

Preface

x Version 2.1

This task may specify multiple entry points for launching theapplication.

• Chapter 8, “Install Options”Describes how to specify a task that runs when installing anapplication so that the user may specify site-specificinformation, such as machine names or database types.

• Chapter 9, “Plus Configuration”Describes how to specify a Plus configuration task that canbe run during and after Plus module installation. Additionaltasks, such as for displaying information about an applicationor creating additional subscription lists may also bespecified.

• Chapter 10, “Subscription Lists”Describes how to create a subscription list of the managednodes associated with your application. For example, asubscription list can be used to run a task on or distribute afile package to multiple nodes.

• Chapter 11, “Administrative Tasks”Describes how to create administrative tasks that can be runfrom the Plus module (and incorporated into the TME 10Framework task library) to manage an application.

• Chapter 12, “File Packages”Describes how to create file packages for the centralizeddistribution of your application to multiple machines andplatforms.

• Chapter 13, “Indicator Collections”Describes how to create an indicator collection for displayingthe status of an application’s monitors.

• Chapter 14, “Monitors”Describes how to create monitors that can track the status ofan application’s crucial resources and generate events inresponse to status changes.

• Chapter 15, “TME 10 Enterprise Console Configuration”Describes how to create the configuration task required to

Preface

Tivoli Module Builder User’s Guide xi

integrate an application’s custom monitors with the TME 10Enterprise Console.

• Chapter 16, “Logfile Adapter Configuration”Describes how to create the configuration task required tointegrate an application’s logfile with the TME 10 EnterpriseConsole logfile adapter.

• Chapter 17, “Hidden Tasks”Describes how to define tasks that are run in response tospecific events. These tasks are understood by the TivoliManagement Software tools but are not visible to the user ofthe Plus module.

• “Glossary”Defines terms particular to the Application ManagementSpecification (AMS) and the Tivoli Module Builder.

Conventions Used in This GuideThe guide uses several typeface conventions for special terms andactions. These conventions have the following meaning:

Bold Commands, keywords, file names, authorization roles,URLs, or other information that you must use literallyappear inbold. Names of windows, dialogs, and othercontrols also appear inbold.

Italics Variables and values that you must provide appearinitalics. Words and phrases that are emphasized alsoappear initalics.

Bold Italics New terms appear in bold italics when they aredefined in the text.

Monospace Code examples, output, and system messages appearin a monospace font.

Preface

xii Version 2.1

Contacting Customer SupportIf you encounter difficulties with any Tivoli products, you can enterhttp://www.support.tivoli.com to view the Tivoli Support homepage. After you link to and submit the customer registration form, youwill be able to access many customer support services on the Web.

Use the following phone numbers to contact customer support in theUnited States: the Tivoli number is 1-800-848-6548 (1-800-TIVOLI8)and the IBM number is 1-800-237-5511 (press or say 8 after you reachthis number). Both of these numbers direct your call to the TivoliCustomer Support Call Center.

We are very interested in hearing from you about your experience withTivoli products and documentation. We welcome your suggestions forimprovements. If you have comments or suggestions about thisdocumentation, please send e-mail to [email protected].


Part I—Understanding theTivoli Module Builder

This section contains chapters that introduce concepts associated with application andbusiness systems management and using the Tivoli Module Builder to createmanagement modules.

Chapter 1—OverviewApplication and Business Systems Management ...............................................1-2

Base Modules......................................................................................................1-5

Modules for Tivoli Partner Association Certification ........................................1-5

Understanding the Tivoli Module Builder ..........................................................1-7

Launching the Tivoli Module Builder ................................................................1-9

Understanding the Workspace Object Hierarchy..............................................1-10

Understanding Variables and Settings ..............................................................1-11

Understanding Script Stubs and Skeleton Files ................................................1-15

Chapter 2—Creating Base ModulesCreating the Project.............................................................................................2-2

Adding a Module to the Project ..........................................................................2-3

Adding and Importing Components into a Module ............................................2-4

Editing the Module’s Components .....................................................................2-9

Specifying Before and After Installation Scripts ..............................................2-12

Generating the Module and Other Objects .......................................................2-14

Understanding the Tivoli Module Builder

Version 2.1

Editing the Generated Scripts and Skeleton Files............................................. 2-16

Testing the Scripts ............................................................................................ 2-19

Building the Installable Image.......................................................................... 2-21

Chapter 3—Defining the Base Module’s FeaturesPrerequisites........................................................................................................ 3-2

Defining Component Data.................................................................................. 3-3

Defining File Distribution (File Lists) ................................................................ 3-4

Defining Installation Dependencies.................................................................... 3-8

Defining Operational Tasks.............................................................................. 3-10

Defining Synchronous Monitors....................................................................... 3-12

Chapter 4—Installing and Uninstalling Base ModulesSpecifying the Tivoli Installation Directory ....................................................... 4-1

Installing Base Modules...................................................................................... 4-2

Uninstalling Base Modules................................................................................. 4-4

Base Modules in the Tivoli Environment ........................................................... 4-4

Tivoli Module Builder User’s Guide 1–1

Overview

1Overview

Application and business systems management is a fundamentalactivity in systems administration. Systems administration requiresmaintaining the availability of applications running on multipleplatforms and at geographically diverse locations. Systemadministrators rely on management tools, such as the TivoliManagement Software tools, to maintain an application’s availabilityfrom a central point of control.

The Tivoli Management Software tools can distribute, install,monitor, provide event correlation and security, run tasks, andprovide other management for applications and business systems.Using these tools, you can monitor the efficiency of an application’stransactions as well as build a topology view of multiple applicationsthat shows how the applications are communicating with each other.Through these functions, the Tivoli Management Software toolsprovide a view of the overall availability of an application or businesssystem as well as the ability to avoid or correct error conditions.

To provide application and business systems management, the TivoliManagement Software tools require information that describesapplications and their relationships. For example, monitoring anapplication’s availability requires information about the systemresources, such as daemons and disk space, that are crucial to theapplication’s functioning. A system administrator could provide thisinformation by manually instructing each management tool for everyapplication to be managed. It is much more efficient, however, toprovide this information in a machine-readable format. TheTivoli

1

Application and Business Systems Management

1–2 Version 2.1

Module Buildercreates the data in a format—referred to as amodule—that can be directly imported and interpreted by the Tivolimanagement tools. The Tivoli Module Builder provides a graphicaluser interface (GUI) for defining applications and business systems.

Application and Business Systems ManagementApplication management includes monitoring system resources andinitiating tasks to manage the application. Through monitoring andtasks, the Tivoli management tools can take preventive action toavoid application failure or take corrective action once a failure hasoccurred.

In addition to the management needs of an individual application,critical business functions often depend on the interaction of manydifferent applications and system resources. Maintaining an airlineticketing system, for example, may require maintaining machineswith client/server and mainframe functions, different operatingsystems, databases, middleware applications, and various end-userapplications, some of which may be Internet-based. Theinterdependencies of these applications and resources constitute abusiness system. Rather than managing the specific needs of anindividual application, it is often more useful to understand theinteractions and interdependencies of the multiple applications andresources that comprise a business system.

Management DataManagement data provides information about an application orbusiness system. This information describes the management needsof an application as well as the files associated with the applicationsuch as configuration scripts and programs that execute maintenancetasks. This information also describes the role the application playsin a business system.

Management data conveys such information as the following:

■ Name and version of the application

■ Types and versions of target platforms

■ Requirements for different platform operating systems



Overview

■ Relationship the application has to other applications

■ How the application fits into a business system

■ Paths and names of source files that make up the application

■ Paths of destination directories on targets

■ Configuration scripts that run before or after the distribution

■ Maintenance scripts and programs that perform tasks foroperational control

■ Resources that require monitoring and thresholds that indicatean error condition

The Tivoli Module Builder enables you to define your application’smanagement data.

Defining an Application for Tivoli Enterprise SoftwareThe Tivoli Module Builder uses application and business systemdescription files that conform to theApplication ManagementSpecification (AMS). The AMS is an innovation founded on theManagement Information Format (MIF). (See “Prerequisite andRelated Documents” on page viii for information on downloading theAMS.)

The MIF is an open standard developed by theDesktop ManagementTask Force (DMTF), a consortium of such industry leaders as IBM,Microsoft Corporation, Hewlett-Packard, and Intel Corporation. Thegoal of the DMTF is to define standardized syntax for data thatdescribes how to manage the hardware and software components ofdesktop computers.

The AMS describes groups of management data that can be used todefine an application or business system. These groups ofinformation are then applied to a software component to describe themanagement needs of the component. The AMS defines asoftwarecomponent as an individually deployable unit of an application thatruns on a single platform. The management information for eachsoftware component is contained in acomponent description file(CDF).


1–4 Version 2.1

The Tivoli Module Builder uses the same management informationgroups as the AMS. When generating a module, the managementinformation for a software component is also contained in a CDF.

Defining a Business System for Tivoli EnterpriseSoftware

In addition to defining the management needs of individualapplications, a business system definition organizes relatedapplications into business components and business subsystems toprovide common management at different levels.

Note: Base and Plus modules do not provide business systemsmanagement. To manage an application in the context of abusiness system, refer to theTivoli Global EnterpriseManager Instrumentation Guide for information on creatinga Tivoli GEM instrumentation module.

While the CDF is associated with an application definition, abusiness system definition generates files, known generically asbusiness description files (BDFs). The following describes the basicelements of a business system definition and the files generated foreach element.

■ Business system components. Abusiness system componentdescribes the role a particular application plays in the context ofthe business system. The information for a business systemcomponent is generated into abusiness component descriptionfile (BCDF). For example, if your business system is for anairline ticketing system, you might create a BCDF for a pricingdatabase and another BCDF for the flight schedule database.You could also have separate BCDFs for your client, server, andmiddleware applications.

■ Business system mapping. Thebusiness system mappingidentifies or “maps” the software components that are to beincluded in a business system component. This mapping is doneby referencing a software component’s CDF. For example, theCDF that defines a server component could be mapped to aBCDF for servers. The information for business system

Base Modules


Overview

mapping is generated into abusiness system mappingdescription file(BMDF).

■ Business subsystems.Business subsystems organize businesssystem components into groups based on a common function toprovide a higher level of management. The information for abusiness subsystem is generated into abusiness subsystemdescription file (BSSDF). In an airline ticketing businesssystem, for example, a flight scheduling subsystem mightinclude BCDFs for all of the client, server, database, andmiddleware applications that handle flight scheduling.

■ Business system. Information pertaining to the entire businesssystem is generated into abusiness system description file(BSDF). This is the highest level of the business systemdefinition. It identifies the overall business system, such as anairline ticketing system, that the application is related to.

Base ModulesA Base moduledescribes basic management capabilities whichallow a particular application to be managed with the TivoliManagement Software environment. Base modules use ApplicationManagement Specification (AMS) formats to describe monitors andtasks for managing an application, along with files to be distributedwith the application. This management information, including thecorresponding scripts and programs, is built into a Tivoli installableimage.

Modules for Tivoli Partner AssociationCertification

The Tivoli Partner Association places requirements on a module’smanagement features in order to achieve Tivoli certification. Thosepartners seeking Tivoli certification are required to create Plusmodules with particular features, including enablement for the TivoliGlobal Enterprise Manager (Tivoli GEM). The Tivoli GEM modulescan be created as a separate module and then linked with a Plusmodule. Plus modules provide applications management with the

Modules for Tivoli Partner Association Certification

1–6 Version 2.1

Tivoli suite of management tools, while the Tivoli GEM modulesprovide additional features for managing an application in thecontext of a business system.

Information on creating a Plus module is provided later in this book.For information on creating a Tivoli GEM module, see theTivoliGlobal Enterprise Manager Instrumentation Guide.

Plus ModulesPlus modules integrate an application with the Tivoli suite ofmanagement tools. Through this integration, a Plus modulecustomizes the Tivoli applications management capabilities for usewith a particular application. In addition to customized andcomprehensive applications management, Plus modules provide acommon interface and in some cases, enable data sharing with theTivoli management tools. The specific integration points, whichinclude tasks, monitors, file distribution, and event management, aredescribed in AMS format. This management information, along withthe corresponding scripts and programs, are built into a Tivoliinstallable image.

When installed, Plus modules create a Plus icon on the TivoliManagement Software desktop. This icon accesses the dialogs andother features for all installed Plus modules, thus avoiding the needto access the Plus management functions separately from each Tivolimanagement tool.

Tivoli GEM ModulesA Tivoli Global Enterprise Manager (Tivoli GEM) module describesthe basic management capabilities which allow a particularapplication to be managed with the Tivoli GEM product. A TivoliGEM module describes the tasks and monitors that Tivoli GEMrequires to build topology views for business systems management.These tasks and monitors are described in AMS format. Thisinformation, along with the corresponding scripts and programs, isbuilt into a Tivoli installable image. For information on creating aTivoli GEM module, refer to theTivoli Global Enterprise ManagerInstrumentation Guide. The terminstrumentation refers to the



Overview

management information, scripts, and programs used to manage anapplication with Tivoli GEM.

Because Tivoli GEM provides business systems management, aTivoli GEM module describes the role an application plays in abusiness system. For example, the Tivoli GEM module can associatean application’s CDF with a BCDF.

Understanding the Tivoli Module BuilderThe Tivoli Module Builder enables you to create a module ofinformation that, when installed in the Tivoli Management Softwareenvironment, supplies Tivoli Management Software tools withmanagement data as well as the scripts and programs forimplementing management functions.

Workflow for Creating ModulesThe basic workflow for creating a module is as follows:

■ Launch the Tivoli Module Builder. Launching the TivoliModule Builder is discussed in “Launching the Tivoli ModuleBuilder” on page 1-9.

■ Create a project. Features for creating a project are discussed in“Understanding the Workspace Object Hierarchy” on page 1-10and “Creating the Project” on page 2-2.

■ Add a module to the project. Features for creating modules arediscussed in “Adding a Module to the Project” on page 2-3.

■ Add an AMS component to or load a template into the module.Information on adding an AMS component or importing acomponent definition file (CDF) is discussed in “Adding andImporting Components into a Module” on page 2-4. Forinformation on loading the Plus module template, see “Loadingthe Plus Module Template” on page 5-2. For information onloading templates for the Tivoli GEM module, see theTivoliGlobal Enterprise Manager Instrumentation Guide.

■ Define the management information for the softwarecomponent. The utility for defining management information isdiscussed in “Tivoli Module Designer” on page 1-8.


1–8 Version 2.1

■ Generate the CDF and associated scripts and files. Features forgenerating the module are discussed in “Tivoli Module BuilderWorkspace” on page 1-8.

■ Edit the generated files and build the module. Features forbuilding the module are discussed in “Tivoli Module BuilderWorkspace” on page 1-8.

Tivoli Module DesignerThe Tivoli Module Designer is a graphical utility for definingmanagement information for applications and business systems. TheTivoli Module Designer displays categories of information withfields for entering specific details. For example, in the operationaltasks category, you can supply a name for the task, a name andlocation for the file that executes the task, arguments, and so on.

Tivoli Module Builder WorkspaceThe Tivoli Module Builder displays a workspace for organizing yourmodules and projects as well asproperty tabs with features forgenerating and building the module.

The generate process creates makefiles and lists of files that must bebuilt. If called for in the description information, the generate processalso creates management source files, such as task scripts, that willgo into the module. For example, if you specify a task for acomponent with the Tivoli Module Designer, the generate processcreates a file for a standard task script. You can then edit the scriptfiles with application-specific information.

The build environment has a directory structure that mirrors theobject hierarchy displayed in the Tivoli Module Builder workspace.Generating a project or module entails generating the CDFs andscript stubs for the scripts and programs referenced by the CDFs. Thescript stubs contain header information and code required by TivoliManagement Software tools. These scripts stubs can be edited withapplication-specific code and their functionality tested. The buildprocess builds an installable image. Because you can run the buildprocess at the different levels of the object hierarchy, the installableimage can consist of a single or multiple modules. When the image

Launching the Tivoli Module Builder


Overview

contains multiple modules, the system administrator will have thechoice of installing all modules or only selected ones.

Launching the Tivoli Module BuilderYou can launch the Tivoli Module Builder with theTivoli ModuleBuilder icon on the Windows NT desktop or with theBuilder.bat orBuilder.sh scripts. Launching the Tivoli Module Builder displays theTivoli Module Builder window, which has a workspace and menusfor creating and managing your projects. The Tivoli ModuleBuilder’s workspace is divided into left and right panes.

The left pane displays objects or icons for your projects and modules.As you add modules and other features to a project, additional iconsare displayed that represent these objects.

The right pane of the Tivoli Module Builder workspace displays thetabs for specifying the properties of the object selected in the leftpane. These tabs have fields for defining specific information for anobject.

Understanding the Workspace Object Hierarchy

1–10 Version 2.1

The following screenshot shows theTivoli Module Builder windowas it first appears before user-created projects or modules have beenadded to the workspace.

Understanding the Workspace Object HierarchyThe objects in the Tivoli Module Builder workspace have ahierarchical order. At the highest level of the hierarchy is the defaultworkspace object namedProjects, which is displayed at all times.Individual projects are the next level of the hierarchy, followed bymodules. You can add projects and modules using theCreate menu.Depending on the item that you have selected in the workspace, theCreate menu only allows you to add an object that is appropriate forthe next level of the hierarchy.

When you first add an object (for example, a project or a module) tothe Tivoli Module Builder workspace, the object will have a defaultname, such asNewProject or NewModule. Additional objects willbe numbered sequentially, for example,NewProject1, NewProject2,

Understanding Variables and Settings


Overview

and so forth. You can change these default names using a selectedobject’sGeneral tab.

As you add projects, modules, and other objects, additional icons aredisplayed representing these objects. These icons form a tree viewshowing the object hierarchy. The different levels of the hierarchy areconnected by a little box or “tree control button” that contains a plus(+) or minus (-) symbol. You click on the tree control button toexpand or contract the tree view.

The hierarchical nature of the Tivoli Module Builder workspaceenables you to organize your work. You could, for example, haverelated modules organized within the same project. You could thenbuild and test each individual module or build and test themsimultaneously at the project level. Information, such as variablesettings, that is applied at the project level is also inherited bylower-level objects in the hierarchy. Likewise, you can build atdifferent levels of the hierarchy. The resulting installable imagecontains the object that you built and all lower-level objects in thehierarchy.

The hierarchical display of objects in the Tivoli Module Builderworkspace corresponds to theProjects directory structure. (Thedefault location is/module_dev/Projects.) TheProjects directory iscreated during installation. When you add a project to the TivoliModule Builder workspace, a subdirectory with the project name youspecified is created in theProjects directory. These subdirectoriescontain the files and additional subdirectories associated with yourproject. For example, the default location for your project’s files andscript stubs generated during the build process are located in theProjects/Project_Name directory.

Understanding Variables and SettingsModules and other objects in the Tivoli Module Builder workspacehierarchy can use variables. These variables may indicateinformation defined in the component description files (CDFs) or beused for other functions, such as linking modules.


1–12 Version 2.1

Variables and their values are determined by the following sources:

1. You can supply the variable value using a selected object’sSettings tab.

2. The variable value is specified in the component description file(CDF). The values for these variables match the field values youspecify on theComponent Data tab when editing thecomponent with the Tivoli Module Designer.

3. The variable value is specified in the global description file(GDF). The values for these variables match the field valuesyou specify on theApplication Data tab when editing thecomponent with the Tivoli Module Designer.

Any variable set for an object automatically applies to all lower-levelobjects in the hierarchy, unless the variable is overridden at a lowerlevel. When generating files, the Tivoli Module Builder reads thevariable settings starting from the lowest level of the hierarchy. Thismeans that any variable you set using an object’sSettings tabautomatically overrides the same variable set at a higher level.Modified variables are applied to skeleton files at generate time.

Editing SettingsMost objects in the Tivoli Module Builder workspace hierarchy havea Settings tab that enables you to specify variables not defined by aCDF or GDF. When you use theSettings tab, specify the variable intheVariable field and the value for the variable in theValue field.

The following describes the settings that can be applied to Basemodules. These variables are used by the skeleton files for Basemodule installation.

Variable Value

USE_TLL True. (This setting tells the installation to compile.tllfiles instead of usingwcrttask.)

CPP_PATH (This setting defaults to the location of the CPPexecutable in your path. This default setting can beoverwritten.)



Overview

MODULE_TYPE(This optional setting indicates the type of module.)

PRODDIR (This setting should be the full path location of themodule binaries. The default is$BINDIR/../generic_unix/!ProdDir!/The value ofProdDir is built using the value of<MODULE_TYPE>/proddirfileformat from theProjects.state file. If theMODULE_TYPE settinghas not been specified, theProjects.state file usesMODULE as the value forMODULE_TYPE .

USE_TSUNAMI_NAMESTrue. (This setting indicates that Tivoli 3.6 productnames should be used.)

USE_SPECIAL_PRFMGR_NAMESTrue. (This setting indicates that Tivoli 3.6 namesshould be truncated for profile managers.)

REPLACE_TASK_LIBSTrue. (When set to false, this setting indicates thatwtll should augment instead of replace existing tasklibraries.)

ADMIN_TAG Default. (This setting is used to construct Tivoli 3.6names.)

If you have a Plus module, theSettings tab displays variablesassociated with the Plus module. These variables should not bechanged, although you may add additional monitor collection namesfor predefined monitors to thePREDEFINED_MONITOR_COLLECTIONS variable. Forinformation on adding additional monitor collection names, see“Specifying the Collection Name for Predefined Monitors” onpage 3-13.

Editing CDF and GDF VariablesThe CDF and GDF variables are displayed on theCDF Variables taband cannot be changed with the Tivoli Module Builder. Changingthese variables requires launching the Tivoli Module Designer and


1–14 Version 2.1

editing theComponent Data tab (for CDF variables) or theApplication Data tab (for GDF variables).

If your module has more than one component, then your module alsohas a global description file (GDF). In this case, you can edit the GDFvariables by selecting the module in the Tivoli Module Builderworkspace and clicking on theEdit AMS Definition button. Thisaction launches the Tivoli Module Designer with theApplicationData tab displayed. The field values on theApplication Data tabmatch the variable values in the module’s GDF file. Refer to theonline help for information on specifying theApplication Data tabfields.

The following graphic shows anApplication Data tab for a Plusmodule.



Overview

Note: Because Plus modules have more than one component. theyalways have a GDF file.

If your module has only one component, then your module has a CDFbut no GDF file. In this case, you can edit the CDF variables byselecting the module or component in the Tivoli Module Builderworkspace and clicking on theEdit AMS Definition or EditComponent button. This action launches the Tivoli ModuleDesigner. If the module has only one component, then the TivoliModule Designer launches with theComponent Datatab displayed.Later chapters in this guide, as well as the online help, describe howto complete the fields on theComponent Datatab when editing amodule’s components.

Understanding Script Stubs and Skeleton Files

1–16 Version 2.1

Understanding Script Stubs and Skeleton FilesWhen completing a component definition, you specify the names ofscripts or programs that implement the component’s function. Forexample, a module’s application launch component references theprogram that launches the application. When generating the CDFfiles for a module, the Tivoli Module Builder also generates scriptstubs for each script or program referenced in the CDF files. TheTivoli Module Builder has a set of skeleton scripts which it uses togenerate the script stubs. These skeletons also provide the script stubswith code required for implementing the script’s function in theTivoli Management Software environment.

For example, if you have defined a custom monitor for yourapplication, then the CDF file would reference a program forimplementing the monitor. During the generate process, the TivoliModule Builder may use an MCSL (Monitoring CapabilitySpecification Language) skeleton to create a monitor script stub withthe name you specified. The MCSL skeletons provide informationsuch as the script’s header and monitor definition code required byTivoli Management Software tools. In the case of a custom monitor,you would also have to edit the script stub with theapplication-specific code required to run the monitor program. Mostgenerated script stubs require editing with code specific to anapplication. The script stubs have “placeholders” which indicatewhere the code should be inserted.


Creating B

ase Modules

2Creating Base Modules

The following sections describe how to create a base managementmodule. When building a base module, you create a project and add amodule to the project. You then add an AMS component to the moduleand edit the component with the management information required forthe application. The management information includes theapplication’s tasks, monitors, the files to be distributed, and so forth.A base module may have one or more AMS components.

When you edit an AMS component, you provide the name of the scriptor program that implements the management function described in thecomponent. For example, a component describing a backup andrestore task would reference the name of the program that is run whenexecuting the task. After completing the component descriptions, youcreate the scripts and programs referenced in each component.

Generating the module creates a component description file (CDF) foreach component in the module. The CDFs contain the module’smanagement information and references to the scripts and programs.Building the module builds the management information and thescripts and programs into a Tivoli installable image.

Unlike modules required for certification with the Tivoli PartnerAssociation, base modules are not required to have particular features.You can design the base module with the number of components andfeatures that best suit your development style and application needs.

The following sections describe the workflow for creating a basemodule.

2

Creating the Project

2–2 Version 2.1

Creating the ProjectAll work in the Tivoli Module Builder workspace must be done in aproject. Use theCreate menu in theTivoli Module Builder windowto create a project. A project can contain a single or multiple modules.A project can also be used as a method of organizing a set of relatedmodules. For example, you can run the generate and build processes ateither the module or project level. If you build at the project level, theinstallable image will contain all of the modules. The variables set atthe project level will also be inherited by the modules, although thisinheritance can be overwritten at the module level.

Use the following steps to create a project:

1. Launch the Tivoli Module Builder using thebuilder.bat orbuilder.sh scripts.

2. Select theCreate –> Project menu option to add a project to theTivoli Module Builder workspace.

3. (Optional). Change the project’s name by editing theName fieldon the project’sGeneral tab. When ready, click on theApplybutton next to theName field.

Adding a Module to the Project


Creating B

ase Modules

Continue with “Adding a Module to the Project” on page 2-3.

Adding a Module to the ProjectYou can add one or more modules to a project. At least one module isrequired, however, as AMS components and templates must reside ina module object in the Tivoli Module Builder workspace.

Use the following steps to add a module to a project:

1. Select the project to which you are adding a module.

2. Select theCreate –> Modulemenu option to add a module to theproject.

3. (Optional). Change the module’s name by editing theNamefield on the module’sGeneral tab. When ready, click on theApply button next to theName field.

Continue with “Adding and Importing Components into a Module” onpage 2-4.

Adding and Importing Components into a Module

2–4 Version 2.1

Adding and Importing Components into a ModuleThe module’s features are defined by editing the module’scomponents. The information for each component is generated in acomponent description file (CDF). For base modules, the TivoliModule Builder provides a generic AMS component that can be addedand then edited.

You can also import a component description file (CDF) from anexisting module, modify this component, and regenerate the CDF.

Note: The Tivoli Module Builder also has templates for creating Plusand Tivoli GEM modules. For information on loading a Plustemplate, see “Loading the Plus Module Template” onpage 5-2. For information on loading the Tivoli GEMtemplates, see theTivoli Global Enterprise ManagerInstrumentation Guide.



Creating B

ase Modules

Adding an AMS ComponentYou can add one or more AMS components to a base module.

Use the following steps to add an AMS component to a module:

1. Select the module to which you are adding an AMS component.

2. Select theCreate –> AMS Componentmenu option to add anAMS component to the module.


2–6 Version 2.1

Adding an AMS component to a module automatically launchesthe Tivoli Module Designer with theComponent Data tabdisplayed. The Tivoli Module Designer enables you to edit theAMS component.

For information on editing the component, continue with“Editing the Module’s Components” on page 2-9.



Creating B

ase Modules

3. Select theFile –> Save Project and CDF menu option beforeexiting the Tivoli Module Designer.

Importing a Component Description FileYou can import a previously generated CDF into the module. Forexample, you may wish to import a CDF from a completed module inorder to reuse portions of the component description. You can alsoimport a module’s application object file (.aof). When importing an.aof file, all CDFs referenced in the.aof file are imported.

When importing CDFs (or an.aof), you can choose whether or not toimport any source files (scripts and programs) referenced by the CDFs.By default, the source files are imported unless you deselect theImport Source Files check box on the module’sGeneral tab.


2–8 Version 2.1

Use the following steps to import a CDF:

1. Select the module into which you are importing a CDF.

Note: If you do not wish to import the scripts and programsreferenced by the CDF, deselect theImport Source Filescheck box.

2. Click on theImport AMS Component Definitions button. Thisaction displays theOpen dialog for locating the files on yoursystem.

Note: Because the Tivoli Module Builder is a JAVA-basedapplication, the exact title of certain dialogs, such as the“open” dialog, may be different on different platforms.

Editing the Module’s Components


Creating B

ase Modules

3. Use theOpen dialog to locate the directory where the CDF islocated.

4. Select the CDF and click on theOpen button. The CDF isimported into your module’s directory structure under the/Module_dev/Projects directory.

If you are importing source files, aSpecify import directorydialog is displayed. This dialog enables you to specify the sourcedirectory that contains the scripts and programs referenced in theCDF that you are importing.

To specify the source directory, click on theBrowse button andthen use theOpen dialog to locate the directory.

If you choose not to import the source files, click on theSkipbutton. In this case, the Tivoli Module Builder will import onlythe CDF.

The files are imported into the <Module_Name>/src directory.

After you have imported the CDF, continue with “Editing theModule’s Components” on page 2-9.

Editing the Module’s ComponentsThe Tivoli Module Designer enables you to edit the module’scomponents. When you edit a component, you define the managementinformation required by the Tivoli Enterprise software tools toperform particular management tasks. Editing an application’scomponents is described in detail in Chapter 3, “Defining the BaseModule’s Features.” The following sections describe how to launchthe Tivoli Module Designer for component editing. After launchingthe Tivoli Module Designer, you should refer to Chapter 3, and thenreturn to this chapter and continue with “Specifying Before and AfterInstallation Scripts” on page 2-12.

You can launch the Tivoli Module Designer from different levels in theTivoli Module Builder object hierarchy. The following sectionsdescribe the launch options.


2–10 Version 2.1

Launching from the Module LevelWhen launching the Tivoli Module Designer from the module level,all components in the module are displayed in the Tivoli ModuleDesigner workspace. This enables you to access all of the module’scomponents for editing without having to exit and relaunch the TivoliModule Designer.

Use the following steps to launch from the module level:

1. Select the module in the Tivoli Module Builder workspace.

2. Click on theEdit AMS Definition button.

Continue with Chapter 3, “Defining the Base Module’s Features.”



Creating B

ase Modules

Launching from the Component LevelIf you launch the Tivoli Module Designer from the component level,only the component you have selected in the Tivoli Module Builderworkspace is displayed for editing. If you only wish to edit onecomponent, you may choose this option to facilitate navigation in theTivoli Module Designer workspace.

Use the following steps to launch from the component level:

1. Select the component you wish to edit in the Tivoli ModuleBuilder workspace.

2. Click on theEdit Component button.


Launching from Lower-level ObjectsIf you have already edited a component or imported a previouslydefined CDF, you may have specific instances defined for thecomponent definition categories. For example, if the component has a“start server” task defined in the operational tasks category, then a“start server” instance has been created for this category. These

Specifying Before and After Installation Scripts

2–12 Version 2.1

instances are displayed in the Tivoli Module Builder workspace.Launching the Tivoli Module Designer from an instance displays thespecific tab for editing the instance. You may choose this option if youhave already edited the component and only need to make changes toa particular instance.

Use the following steps to launch from the instance level:

1. Select the instance you wish to edit in the Tivoli Module Builderworkspace.

2. Click on theEdit AMS Definition button.


Specifying Before and After Installation ScriptsBase modules require that you specify an after install script. This scriptis described in “After Install Scripts” on page 2-14.

Before install scripts are optional.

Specifying Before and After Installation Scripts


Creating B

ase Modules

Before and after install scripts are specified with theBefore InstallandAfter Install fields on the module’sGeneral tab.

Before Install ScriptsYou may wish to specify a before install script for the Base module.For example, you may wish to have a before install script that verifiesthat the target node supports the managed application or whether thereis enough disk space to install the module. The generate processgenerates a script stub for the before install script. You need to edit thescript stub with the necessary code. The generated script stub islocated in the <Module>/src directory.

Generating the Module and Other Objects

2–14 Version 2.1

Use the following steps to specify the before install script:


2. Specify a simple file name in theBefore Install field.

3. Click on theApply button.

After Install ScriptsBase modules require an after install script which runs after the Basemodule’s files have been installed in the Tivoli environment. Thisscript creates and configures the module’s policy region and otherobjects displayed on the Tivoli desktop. (For a description of theseobjects, see “Base Modules in the Tivoli Environment” on page 4-4.)

You need to specify the name of this after install script. The generatedscript is complete and does not require modification. The generatedscript stub is located in the <Module>/src directory.

Use the following steps to specify the after install script:


2. Specify a simple file name in theAfter Install field on theGeneral tab.

Note: The after install section of theGeneral tab includes anImport andEdit Skeleton button. Since the generateprocess generates a complete after install script, it isgenerally not necessary to either import a script ormodify the after install script’s skeleton file.


Continue with “Generating the Module and Other Objects” onpage 2-14.

Generating the Module and Other ObjectsThe generate process generates the CDF files for each component aswell as script stubs for all programs referenced in the CDF files. Thegenerated CDF files are located in your module’s directory. Generatedscript stubs and their test cases are generated insrc andtestsubdirectories.

Generating the Module and Other Objects


Creating B

ase Modules

You can initiate the generate process using theGenerate button on anobject’sBuild/Generate tab in the Tivoli Module Builder. You cangenerate files at any level of the object hierarchy in the Tivoli ModuleBuilder workspace. If you have files that you do not wish to beoverwritten by the generate process, you can “lock” the file with theLocked check box on theBuild/Generate tab.

Note: The build process also generates those files that have beenmodified since they were last generated. For information onthe build process, see “Building the Installable Image” onpage 2-21.

Use the following steps to generate the module or other objects:

1. (Optional). If this is the first time you are generating a module,skip to step 2 on page 2-15.

Determine whether you need to protect any lower-level objects(such as modules or files) from being overwritten. For example,you may have completed a module and not wish to overwrite itwhen generating at the project level.

Use the following steps to protect an object from beingoverwritten:

a. Select the object in the Tivoli Module Builder workspace.

b. Select theBuild/Generate tab.

c. Select theLocked check box.

2. Select the module or other object in the Tivoli Module Builderworkspace that you wish to generate.

3. Select theBuild/Generate tab.

4. Click on theGenerate button.

TheBuild/Generate tab displays status messages for the generateprocess. To save these messages to a file, click on the Save Outputbutton and use theSave As dialog to specify the output file.

Editing the Generated Scripts and Skeleton Files

2–16 Version 2.1

Note: The Tivoli Module Builder is a JAVA-based application. JAVAhas certain text field size limitations which may prevent thefull text of the status message from being displayed. In thiscase, the end of the output is displayed along with a messagestating that the status message has been truncated. To view thecomplete output, you need to save the output to a file and thenview the file with an editor.

Continue with “Editing the Generated Scripts and Skeleton Files” onpage 2-16.

Editing the Generated Scripts and Skeleton FilesScripts are generated for all scripts and programs referenced in theCDF files. These scripts are located in the <Module_Name>/srcdirectory. You need to edit these scripts with the application-specificcode required to implement the desired management function. You canedit the generated script or the default skeleton file used to generate thescript stub.

Note: Files referenced in the CDF’s file distribution list are onlygenerated if they already exist. If you have specified a file inthe file distribution list but have not imported anything into thefile, the file will not be generated. For information on definingfile distribution lists, see “Defining File Distribution (FileLists)” on page 3-4.



Creating B

ase Modules

Editing a script or skeleton file requires selecting the script’s object inthe Tivoli Module Builder workspace and using theEdit or EditSkeleton buttons to open the file for editing.

When you have finished editing the scripts, continue with “Buildingthe Installable Image” on page 2-21.

Editing Script StubsUse the following steps to edit a script:

1. Select the script’s object in the Tivoli Module Builderworkspace.

2. Click on theEdit button on the script’sGeneral tab. This actionopens the script in a Bash shell for editing with vi or anothereditor.

3. Insert your application’s code into the script.

Editing a script causes theLocked check box to be automaticallyselected on the script’sBuild/Generate tab. This prevents the editedscript from being overwritten when you next generate the file.


2–18 Version 2.1

You may wish to save the edited script as a new skeleton so that yourmodifications will be present during all subsequent generations of thescript. To save the script as a skeleton, click on theSave As Skeletonbutton and then use theSave As dialog to specify the skeleton file. Forinformation on specifying which skeleton is used to generate a script,see “Specifying Skeletons for Generating Scripts” on page 2-19.

Editing the Default Skeleton FilesYou can edit the default skeleton files used to generate the script stubs.

Use the following steps to edit a skeleton file:


2. Click on theEdit Skeletonbutton on the script’sGeneral tab.This action opens the skeleton file in a Bash shell for editing.

When you edit a default skeleton file provided by the Tivoli ModuleBuilder, the Tivoli Module Builder copies the file to the<ModuleName>/skeletonsdirectory. The copied skeleton file isnamed in the format <ScriptName>.skel. For example, if you edit ascript namedtest.sh, and the default skeleton for the script isGenericBourneShell.skel, then the copied skeleton file is named:

<ModuleName>/skeletons/test.sh.skel

Your modifications are applied to the copied file so that the defaultskeleton file remains unchanged. When you edit a script’s skeleton file,the new skeleton file is selected in theSkeleton field on the script’sBuild/Generate tab.

Creating New Skeleton FilesYou can create a new skeleton file by either editing a script or thedefault skeleton file and then saving your changes in a new file:

Use the following steps to create a new skeleton file:

1. Edit the script or default skeleton file. (See “Editing Script Stubs”on page 2-17.)

2. Save the modified script using theSave As Skeleton button.

Testing the Scripts


Creating B

ase Modules

For information on specifying which skeleton is used to generate ascript, see “Specifying Skeletons for Generating Scripts” onpage 2-19.

Specifying Skeletons for Generating ScriptsBy default, the skeleton files provided with the Tivoli Module Builderare used to generate the scripts. After creating new skeleton files, youmay wish to specify that a non-default skeleton file be used to generatea script.

Use the following steps to specify a skeleton file:



3. Specify the path to the skeleton file you wish to use in theSkeleton field.


Testing the ScriptsThe Tivoli Module Builder can create testdata files for testing thescripts and programs referenced by the CDF files. You can edit thetestdata files to create the test cases. The testdata files are located in the<ModuleName>/test directory.

Testing the Scripts

2–20 Version 2.1

Features for editing the testdata files and running tests are located onthe script’sTest tab.

Editing Testdata FilesYou can open a Bash shell for editing a testdata file. The testdata filecontains an explanation of the format to be used when editing the fileto create a test case. If you have not previously generated the script orprogram, the script or program will be generated as a result of editingthe testdata file.

Building the Installable Image


Creating B

ase Modules

Use the following steps to edit a testdata file:

1. Select the script that you wish to test in the Tivoli ModuleBuilder workspace.

2. Select theTest tab.

3. Select theTestable check box on theTest tab.

4. Click on theEdit Test Data button.

Running TestsAfter generating and editing the testdata file, you can test the script orprogram. If you have not previously generated the script or program,the script or program will be generated as a result of running the test.

Use the following steps to run a test:

1. Select the script that you wish to test in the Tivoli ModuleBuilder workspace.

2. Select theTest tab.

3. Select theTestable check box on theTest tab.

4. Click on theRun Tests button.

TheTest tab displays status messages from running the test.


Building the Installable ImageYou can run the build process on projects and modules. For example,you can create an installable image for a single module or for a suiteof modules that are in the same project. Your project hierarchy isreflected in the installable image so that the system administrator hasa choice of installing an individual module or the suite of modulesincluded in a project.


2–22 Version 2.1

The build process automatically regenerates any files that have beenmodified since they were last generated. If you wish to view the statusmessages produced by the generate process during a build, save theoutput using theSave Outputbutton on theBuild/Generate tab.

Use the following steps to build a module or project:

1. Select the project or module in the Tivoli Module Builderworkspace.


3. Press theBuild button.

Status messages from the build process are displayed on theBuild/Generate tab.



Creating B

ase Modules



2–24 Version 2.1


Defining the B

aseM

odule’s Features

3Defining the Base Module’sFeatures

Defining the management requirements of an application requiresidentifying the application’s components and then specifying themanagement requirements for each component. Anapplicationcomponent is a portion of the application that performs a particularfunction and resides on a particular platform. For example, you canbreak an application into its client, server, and database functions, andthen define a component for each platform on which these functionsrun.

When you define an application component, you specify thecomponent’s management requirements. The Tivoli Module Designerdisplays these requirements as separate categories of information. Thecomponent definition categories that apply to base modules are thefollowing:

■ File Lists. This category specifies the files required by thecomponent. For example, the file list may specify the files to bedistributed to a target system.

■ Installation Dependencies. This category specifies the criteriathat must be met before a component can be installed andsuccessfully run on a target system. For example, an installationdependency can check for sufficient disk space.

3

Prerequisites

3–2 Version 2.1

■ Operational Tasks. This category specifies those tasks that arerun by the module’s user. For example, an operational task canrun a backup and restore program or generate a database report.

■ Synchronous Monitors. This category specifies the monitorsand monitor instances that will periodically check the status ofyour application’s critical resources. A monitor identifies thetype of resource to be monitored. The monitor instance identifiesthe specific resource. For example, you can specify a monitor thatchecks the amount of free space in a directory. You could thenspecify several monitor instances, each one monitoring the freespace in a different directory.

By defining the component definition categories, you determine thebase module’s management features. You do not have to define allcategories for a component. The build process uses the informationyou specify to create tasks, monitors, and file packages that execute ordistribute according to the parameters you have provided.

Defining a component also requires specifying general information,such as the component’s name, version, and manufacturer.

The following sections describe how to define file distribution (filelists), installation dependencies, operational tasks, and synchronousmonitors for a component.

PrerequisitesThe following procedures assume that you have done the following:

■ Created a project as described in “Creating the Project” onpage 2-2.

■ Added a module to the project as described in “Adding a Moduleto the Project” on page 2-3.

■ Added an AMS component to the module as described in“Adding an AMS Component” on page 2-5 or imported a CDF asdescribed in “Importing a Component Description File” onpage 2-7.

Adding an AMS component to a module automatically launches theTivoli Module Designer. If the Tivoli Module Designer is not already

Defining Component Data


Defining the B

aseM

odule’s Features

launched, then launch it now using the procedure described in“Launching from the Component Level” on page 2-11.

Defining Component DataA base module requires that general information, such as name,version, and manufacturer, be defined for all components in themodule. This information should uniquely identify each component.

This procedure assumes that you have completed the prerequisitesdescribed in “Prerequisites” on page 3-2.

Use the following steps to specify the component data:

1. Select the component in the Tivoli Module Designer to displaytheComponent Data tab.

Defining File Distribution (File Lists)

3–4 Version 2.1

2. Use theComponent Data tab to specify general informationrequired to identify the component. The combined values of theName, Version, andManufacturer fields should be unique foreach component in the module. When defining more than onecomponent, it is sufficient to change the value of just one of thesefields to ensure a unique combination.

For information on completing theComponent Data tab fields,see the online help.

Defining File Distribution (File Lists)You can define a component’s file distribution information byspecifying the file list. When specifying the file list, you have theoption of also specifying location definitions and installationprograms. The Tivoli management tools use the information youspecify to create file packages for distributing this component to targetmachines.



Defining the B

aseM

odule’s Features

The following graphic shows a component that has been expanded todisplay the component definition categories. The categories that can bespecified for file distribution are highlighted.

This procedure assumes that you have completed the prerequisitesdescribed in “Prerequisites” on page 3-2 and defined the componentdata described in “Defining Component Data” on page 3-3.

Use the following steps to specify file distribution:

1. If you have not already done so, display the component definitioncategories by clicking on the “component tree button” (boxcontaining the + symbol) next to the component you are editing.This action expands the component display.

2. (Optional). Select theLocation Definitions category. TheLocation Definitions tab enables you to define symbolic names


3–6 Version 2.1

for directories associated with this component. After completingthis tab, click on the<Add button.

Complete the following fields:

Symbolic NameUse theSymbolic Namemenu to select the symbolic name thatyou wish to define. If you wish to define a symbolic name not onthis list, select<User Defined>.

TheSymbolic Namemenu displays a list of possible symbolicdirectory names that you can define for this software component.Once you have defined a symbolic directory name, you should usethe symbolic name throughout the software component definition.The symbolic directories that you define here will appear on thesymbolic name menus of other tabs.

Source LocationEnter the symbolic name for the source directory. This is thedirectory on the target machine to which the files will bedistributed.

3. (Optional). Select theFile List category. TheFile List tabenables you to define the files (such as installation binaries) thatwill be distributed with the component.

Complete the following required fields on theFile List tab. Youcan specify these fields more than once to include different files.After completing this tab, click on the<Add button.

File NameEnter the names of those files to be distributed. You can specifya file name, a path to a file, or a directory. When using a simplefile name, use theSource Locationfields to specify thedirectories where the file is located.

Note: You may also specify a directory in theFile Name field. Ifthere are certain files in a directory that you wish toexclude, you may exclude these files by specifying them intheFile Name field with an ampersand (&) before the filename.



Defining the B

aseM

odule’s Features

Source LocationUse theSymbolic Name menu to select a symbolic name for thesource location of the file. The symbolic names that you havedefined with theLocation Definitions category appear on thismenu.

Destination LocationUse theSymbolic Name menu to select a symbolic name for thedestination location of the file. The symbolic names that you havedefined with theLocation Definitions category appear on thismenu.

Refer to the online help for additional information.

4. (Optional). Select theInstallation Programs category. TheInstallation Programs tab enables you to define programs, suchas before and after installation scripts, that run when thecomponent is installed. After completing this tab, click on the<Add button.

Complete the following required fields:

Program FunctionUse the menu in this field to select the scripts or programsassociated with installing or removing the component’s files.These programs run on each target machine during the installationprocess.

Program File NameEnter the file name of the program associated with installing orremoving the component.


Defining Installation Dependencies

3–8 Version 2.1

Defining Installation DependenciesYou can specify the criteria that must be met before the component canbe installed.

Note: The Tivoli Module Designer displays a list of predefineddependencies. The predefined dependencies are currently notsupported by the Tivoli Module Builder. You can, however,create a custom dependency and specify the program thatimplements the custom dependency.

The following graphic shows a component that has been expanded todisplay the component definition categories. The installationdependencies category is selected.


Defining Installation Dependencies


Defining the B

aseM

odule’s Features

Use the following steps to specify installation dependencies:


2. Select theInstallation Dependenciescategory. TheInstallationDependenciestab enables you to specify the criteria that must bemet before a component’s files can be installed. After completingthis tab, click on the<Add button.


Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed.

Note: The Tivoli Module Builder only supports customdependencies. For this reason, you should only select<Custom Dependency> from this menu.

Dependency NameEnter a description of the custom dependency. Examples ofdependency names areRequired_Disk_Spaceor OS_Version. Thename must be alphanumeric (a–z, A–Z, 0–9, plus underscores).Spaces are not allowed.

Program NameEnter the name of the program or script that checks for thedependency. The name must be alphanumeric (a–z, A–Z, 0–9,plus underscores). Spaces are not allowed. Generating the Basemodule produces a script stub with this name. The script stub hasa placeholder for inserting your application’s script.

Click on the<Add button when you are ready. This actiondisplays the installation dependency that you have just definedunder theInstallation Dependenciescategory. If you need toedit the installation dependency, you can simply select it toredisplay theInstallation Dependenciestab with yourdefinitions.


Defining Operational Tasks

3–10 Version 2.1

Defining Operational TasksYou can specify the operational tasks that the module’s user will run tomanage the component. For example, you can specify tasks fordatabase maintenance, resource management, starting and stoppingservers, and so forth.

The following graphic shows a component that has been expanded todisplay the component definition categories. The operational taskscategory is selected.


Defining Operational Tasks


Defining the B

aseM

odule’s Features

Use the following steps to specify operational tasks:


2. Select theOperational Task category. TheOperational Taskstab enables you to specify tasks for managing the component.Complete this tab once for each task you wish to define. TheComponent Description File (CDF) generated for this componentdefinition will reference each of the tasks you specify.

Generating the Base module produces a script stub for each scriptor program specified in the task definition. You must edit thesestubs with the scripts for running the task.


Task NameEnter a description of what the task does. Examples of task namesareStart_Servers or Print_Runtime Statistics_Report. The namemust be alphanumeric (a–z, A–Z, 0–9, plus underscores). Spacesare not allowed.

Program NameEnter the name of the program or script that is invoked by the task.The name must be alphanumeric (a–z, A–Z, 0–9, plusunderscores). Spaces are not allowed. Generating the Base moduleproduces a script stub with this name. The script stub has aplaceholder for inserting your application’s script.

Argument NameEnter any arguments expected by the program and click on the<button to add the argument to theArguments list box.

Click on the<Add button when you are ready. This actiondisplays the task you have just defined under theOperationalTasks category. If you need to edit the task, you can simply selectit to redisplay theOperational Tasks tab with your definitions.

To specify another operational task, repeat this step.


Defining Synchronous Monitors

3–12 Version 2.1

Defining Synchronous MonitorsMonitors maintain an application by monitoring those resources thatare crucial to an application’s continued operation. These resourcesmight include daemons, the application server, directory free space,and so forth. You can also specify that a task be run in response tochanges in a resource’s status. For example, you can define a monitorthat checks whether the application’s server is up or down, andinitiates a restart server task when the server fails.

Defining a monitor is a two-stage process:

1. Create the monitor. The monitor identifies the type of resourcebeing monitored. For example, you can define a file size monitor.The procedure for creating a monitor is described in “Creating aMonitor” on page 3-16.

2. Create the monitor instance. A monitor instance identifies thespecific name of the resource and its threshold levels. Forexample, an instance of a file size monitor would identify thename of the file and the size at which the file reaches a normal,severe, or critical status. The procedure for creating a monitorinstance is described in “Creating a Monitor Instance” onpage 3-20.

In addition to creating a monitor, you can use one of the predefinedmonitors provided with the Tivoli Module Builder.

Using the Predefined MonitorsThe Tivoli Module Builder provides component description files(CDFs) with predefined monitors. You can import one of these CDFsinto your module and then edit the CDF to create instances of thepredefined monitors.

Use the following steps to use the predefined monitors:

1. Import a CDF with the predefined monitors using the proceduredescribed in “Adding and Importing Components into a Module”on page 2-4. The CDFs with predefined monitors are located inthe following directory:

\module_dev\ToolKit\cdfs\monitor_collections\<CDF_Name>



Defining the B

aseM

odule’s Features

2. Select the imported component (CDF) and launch the TivoliModule Designer using the procedure described in “Launchingfrom the Component Level” on page 2-11.

3. Create instances of the predefined monitors as needed using theprocedure described in “Creating a Monitor Instance” onpage 3-20.

4. Specify the collection name for the predefined monitors using theprocedure described in “Specifying the Collection Name forPredefined Monitors” on page 3-13.

Specifying the Collection Name for Predefined MonitorsIf you are using a predefined monitor, you need to specify themonitor collection name.

Use the following steps to specify the monitor collection name:

a. Select the project, module, component, or monitor object inthe Tivoli Module Builder workspace.

Note: Settings are inherited by lower-level objects. Youcan override the inherited setting by specifying adifferent setting for a lower-level object.

b. Select theSettings tab.


3–14 Version 2.1

c. SpecifyPREDEFINED_MONITOR_COLLECTIONS intheVariable field on theSettings tab.

d. Specify the monitor collection name in theValue field on theSettings tab. If you need to specify more than one monitorcollection name, use commas to separate the names. You canidentify the correct monitor collection name from thefollowing sources:

- Select the monitor in the Tivoli Module Builderworkspace and expand its display. Select the object forthe script or program that implements the monitor. Themonitor collection name precedes the monitor programname in theName field on theGeneral tab. The monitorcollection name also precedes the name of the programobject displayed in the Tivoli Module Builder objecthierarchy.



Defining the B

aseM

odule’s Features

The following graphic identifies where a monitorcollection name is visible in the Tivoli Module Builder.The monitor collection name shown in this graphic isUniversal.

- Select the monitor in the Tivoli Module Designerworkspace. Select theProgram tab. The monitorcollection name precedes the monitor program name intheProgram Name field on theProgram tab.

The following graphic identifies where a monitorcollection name is visible in the Tivoli Module Designer.


3–16 Version 2.1

The monitor collection name shown in this graphic isUniversal.

Creating a MonitorThis procedure assumes that you have completed the prerequisitesdescribed in “Prerequisites” on page 3-2 and defined the componentdata described in “Defining Component Data” on page 3-3.



Defining the B

aseM

odule’s Features

The following graphic shows a component that has been expanded todisplay the component definition categories. The operational taskscategory is selected.

Use the following steps to create a monitor:


2. Select theSynchronous Monitorscategory. TheSynchronousMonitors tab enables you to specify a monitor for a particulartype of resource.


3–18 Version 2.1


Monitor NameEnter the name that you wish to appear in the monitor definitionlist. This name should reflect the information provided by themonitor, such as daemon status. This name needs to be uniquewithin this component, but does not need to be unique acrosscomponents. The name must be alphabetic (cannot includenumbers, spaces, underscores, or other special characters).

Event ClassIn theUser Defined field, enter the event class that applies to theevents that this monitor sends to the TME 10 Enterprise Console.The TME 10 Enterprise Console requires that event classes be inthe form of a valid BAROC class name (alphanumeric charactersstarting in upper case and including an underscore). For example,an event class may be specified asSample_TraceStatus.

3. Click on theProgram tab. This tab specifies the name of theprogram that runs the monitor. Generating the Base moduleproduces a.csl file. The.csl file contains the names of theprograms that you have specified for the monitors defined in thiscomponent. There is one.csl file for each monitor collection. Youneed to modify the generated.cslfile with the command lineinvocations for each monitor instance. Refer to the TME 10Distributed Monitoring and the Monitoring CollectionSpecification Language (MCSL) documentation for informationon modifying the.csl files. When the Base module is installed, the.csl file imports the monitor definitions into TME 10 DistributedMonitoring.

Note: When editing a.csl file, do not change the name of themonitor collection as shown in the.csl file’s Collectionfield.



Defining the B

aseM

odule’s Features


Program NameEnter the name of the program that runs the monitor. The namemust be alphabetic (cannot include numbers, spaces, underscores,or other special characters). When the module is generated, themonitor implementations are placed in the<ModuleName>/srcdirectory. You need to provide a script for each monitorimplementation.

Note: If you are using a predefined monitor, theProgramName field will have a default value that specifies both amonitoring collection and the monitor program. Thedefault value has the following format:

<CollectionName>/<ProgramName>

Argument NameEnter any arguments that the program requires in theArgumentName field and click on the< button to move the argument to theArguments list box. Do this for all arguments that the programrequires. When you create an instance of this monitor, you willspecify a value for each of these arguments. Because these valuesmay vary according to the specific resource being monitored,they are specified when creating the monitor instance and not themonitor.

Run Program EveryUse these two fields to specify the frequency with which thismonitor should check the status of the monitored resource. Whenspecifying this frequency, take into consideration how often thevalue is updated by the application, how quickly an administratorneeds to know about the situation being monitored, and theoverhead associated with running the monitor program. Forexample, you may wish to specify that the monitor run everyminute in the case of a resource, such as a daemon, whose failurewill immediately cause the application to be unavailable. You maywish to specify a longer interval for those resources that requiremore time to reach a critical status.

4. Click on theReturn Type tab. This tab has fields for specifyingthe monitor program’s return values.


3–20 Version 2.1

Return TypeSpecify whether the monitor program should write its standardoutput as numeric data or strings (character data). Thisspecification determines the type of thresholds that can be set forthis monitor. Numeric data can have thresholds set in terms of anumeric comparison. For example, this type of threshold mayindicate that a daemon count is “equal to 1” or “greater than 1.”String data can have thresholds set in terms of a charactercomparison. For example, this type of threshold may indicate thata tracing facility is “OFF” or that the value for a resource is not“UP” or contains “ERROR.”

Return Unit(Optional). Use theUser Defined field to specify the type of unitsreturned by this monitor. For example, you could specify that thereturn units be megabytes, kilobytes, or a percentage.

5. Click on theAdd button when you are finished. The new monitorthat you just created is displayed under theSynchronousMonitors category. In order to run this monitor, you need todefine an instance of this monitor for a particular resource. Forinformation on defining a monitor instance, see “Creating aMonitor Instance” on page 3-20.

Creating a Monitor InstanceA monitor instance can only be created for a monitor that has alreadybeen defined. You can either create a new monitor or use one of thepredefined monitors provided with the Tivoli Module Builder. If youdo not yet have a monitor, refer to “Creating a Monitor” on page 3-16or “Using the Predefined Monitors” on page 3-12.

The following graphic shows a component that has been expanded todisplay the component definition categories. A file size monitor has



Defining the B

aseM

odule’s Features

already been defined for the component. The file size monitor has beenselected in preparation for creating an instance of this monitor.


Use the following steps to create a monitor instance:


2. Expand theSynchronous Monitors category so that all definedmonitors are displayed.


3–22 Version 2.1

3. Select the monitor for which you are creating an instance andclick on theInstance button. This action creates an “empty”instance of the monitor you selected.

4. Select the newly created instance and click on theThresholdbutton to display theArguments tab. TheArgument Name listbox on this tab displays the arguments that you defined for themonitor program in step 3 on page 3-18.

For each argument, enter the appropriate value in theArgumentValue field. Click on theUpdate button when finished. Thisaction creates aThreshold item under the monitor instance.

5. Select the threshold item for the monitor instance to display theThresholds tab. This tab has fields for specifying the additionalinstance information.

6. Specify the following fields on theThresholds tab:

SeverityUse this menu to select the severity level of the event that is sentto the TME 10 Enterprise Console when the monitored resourcereaches the specified threshold.

ConditionUse this menu to select the relational operator for the threshold.This operator determines how the monitor uses the specifiedthreshold to determine a resource’s status. For example, themonitor may assess a resource’s status by checking whether it is“greater than” or “changes from” or “crosses above” the specifiedthreshold. The value you specify with this menu should beconsistent with the return type you specified on theReturn Typetab in step 4 on page 3-19. For example, if the return type isString, you could not specifyGreater than with this menu sinceGreater than assumes that the return type isNumeric.

Event ThresholdEnter the value for the threshold.

Send event when conditions metSelect this box if you want the monitor to send an event to the TME10 Enterprise Console when the threshold is met.



Defining the B

aseM

odule’s Features

7. Click on theResponsetab. TheResponsetab has fields forspecifying that a task be run in response to a change in amonitor’s status. (For example, you could specify that a task berun to restart a failed daemon.) Complete these fields asnecessary.

Available TasksThis menu displays the operational tasks that you have definedfor this component. If you need to define an operational task, see“Defining Operational Tasks” on page 3-10.

ArgumentAny arguments required by the task selected with theAvailableTasks menu are displayed in theArgument list box.

Argument ValueEnter the value for each argument required by the task.

8. Click on theUpdate button to set your changes.


3–24 Version 2.1


Installing and Uninstalling

Base M

odules

4Installing and Uninstalling BaseModules

You can install Base modules into the Tivoli environment using theTivoli Module Builder, the Tivoli desktop, or thewinstall command.Installing a Base module requires the TME 10 Framework. See theTME 10 Framework installation instructions for more information.

If you are installing from the Tivoli Module Builder, you need tospecify the Tivoli installation directory.

Base modules can also be uninstalled using the command lineinterface.

Specifying the Tivoli Installation DirectoryUse the following procedure to specify the path to the Tivoliinstallation directory. This procedure assumes that the TME 10Framework is already installed. See the TME 10 Frameworkinstallation instructions for more information.

4

Installing Base Modules

4–2 Version 2.1

Use the following steps to specify the path to the Tivoli installationdirectory:

1. Select theProjects object. This is the highest-level object in theTivoli Module Builder workspace.

2. Select theTME 10 tab.

3. Select theTME Install Directory variable from theVariablesList .

4. Enter the path to the Tivoli installation directory (where the TME10 Framework is installed) in theValue field.


Installing Base ModulesUse the following procedure to install the Base module from the TivoliModule Builder. For information on using the Tivoli desktop or thewinstall command to install a product, see the TME 10 Frameworkdocumentation.

Installing Base Modules



Base M

odules

The following procedure assumes that you have installed the TME 10Framework (see the TME 10 Framework documentation for moreinformation) and specified the path to the Tivoli installation directory(see “Specifying the Tivoli Installation Directory” on page 4-1.)

You can install from either the project or module level in the TivoliModule Builder object hierarchy. Installing from the project levelinstalls all modules included in the project.

Use the following steps to install one or more modules from the TivoliModule Builder:

1. Select the project or module in the Tivoli Module Builderworkspace.

2. Select theInstall tab.

3. Enter the name of the target node (machine) in theManagedNode List field. If entering more than one machine name,separate the names with spaces.


Uninstalling Base Modules

4–4 Version 2.1

5. Click on theRun Install button.

Uninstalling Base ModulesThe uninstall process removes the objects added to the Tivoli desktopas a result of installing the module. The uninstall process does notremove the module’s files.

The module’s after installation script provides the uninstall function.When invoked with the proper command line arguments, the afterinstall script uses theproduct-info.sh file to identify the module’sobjects that should be removed from the Tivoli desktop.

To uninstall a module, enter the following:

<after_install.sh> –u product-info.sh

where <after_install.sh> is the name you specified for the after installscript in “After Install Scripts” on page 2-14. This name is displayedon the module’sGeneral tab in theAfter Install field.

Base Modules in the Tivoli EnvironmentThe Base module is installed into the Tivoli Management Softwareenvironment using the standard Tivoli Management Softwareinstallation process. The installation process creates a policy region onthe Tivoli desktop. This policy region is named in the followingformat:

Applications_<MachineName>-region

This policy region contains an additional policy region for eachinstalled Base module. The module-level policy region is named in thefollowing format:

PR_<ApplicationName>_Default_<MachineName>-region

The contents of the module-level policy region vary according to thenumber of components in the Base module and the items defined ineach component. When defined in a component, the following itemsare added to the module-level policy region.

Base Modules in the Tivoli Environment



Base M

odules

■ Profile Manager. A profile manager is created for the monitorsand file lists defined in the component. The profile manager isnamed in the following format:

PM_<ProductName>_<ProductVersion>_ Default_ \<ComponentName>_<ComponentVersion>_<RegionName>

For monitors, the profile manager contains a TME 10 DistributedMonitoring profile. The profile is named in the following format:

SN_<ProductName>_<ProductVersion>_ Default_ \<ComponentName>_<ComponentVersion>_<RegionName>

For file lists, the profile manager contains a file package. The filepackage is named in the following format:

FP_<ProductName>_<ProductVersion>_ Default_ \<ComponentName>_<ComponentVersion>_<RegionName>

■ Task Library. A task library is created for all operational tasksdefined in the component. The task library is named in thefollowing format:

TL_<ProductName>_<ProductVersion>_ Default_ \<ComponentName>_<ComponentVersion>_<RegionName>

■ Dependency Task Library. A dependency task library is createdfor the tasks that check for the custom dependencies. Thedependency task library is named in the following format:

DP_<ProductName>_<ProductVersion>_ Default_ \<ComponentName>_<ComponentVersion>_<RegionName>

Base Modules in the Tivoli Environment

4–6 Version 2.1


Part II—Tivoli PartnerAssociation Plus Modules

This section contains chapters that describe how to create a Plus module for TivoliPartner Association certification. For information on creating a Tivoli GlobalEnterprise Manager instrumentation module, see theTivoli Global EnterpriseManager Instrumentation Guide.

Chapter 5—Introduction to Plus ModulesLoading the Plus Module Template....................................................................5-2

Plus Module Component Types..........................................................................5-4

Component Definition Categories ......................................................................5-8

Plus Modules in the Tivoli Management Software Environment.....................5-11

Activating the Plus Module’s Features .............................................................5-14

Chapter 6—Application IconsPrerequisites........................................................................................................6-2

Editing the Application Icons Component..........................................................6-3

Chapter 7—Application LaunchPrerequisites........................................................................................................7-2

Editing the Application Launch Component ......................................................7-2

Chapter 8—Install OptionsPrerequisites........................................................................................................8-2

Editing the Install Options Component...............................................................8-2

Tivoli Partner Association Plus Modules

Version 2.1

Chapter 9—Plus ConfigurationPrerequisites........................................................................................................ 9-2

Editing the Plus Configuration Component........................................................ 9-2

Chapter 10—Subscription ListsPrerequisites...................................................................................................... 10-2

Editing the Subscription List Component......................................................... 10-3

Chapter 11—Administrative TasksPrerequisites...................................................................................................... 11-2

Editing the Administrative Tasks Component.................................................. 11-3

Chapter 12—File PackagesPrerequisites...................................................................................................... 12-3

Editing the File Package Component................................................................ 12-3

Chapter 13—Indicator CollectionsPrerequisites...................................................................................................... 13-2

Editing the Indicator Collection Component .................................................... 13-2

Chapter 14—MonitorsPrerequisites...................................................................................................... 14-3

Editing the Monitors Component ..................................................................... 14-3

Creating a New Monitor ................................................................................. 14-14

Creating a Monitor Instance ........................................................................... 14-20

Using Additional Predefined Monitors........................................................... 14-27



Chapter 15—TME 10 Enterprise Console ConfigurationPrerequisites......................................................................................................15-3

Editing the TEC Configuration Component .....................................................15-3

Chapter 16—Logfile Adapter ConfigurationPrerequisites......................................................................................................16-2

Editing the Logfile Adapter Configuration Component ...................................16-3

Chapter 17—Hidden TasksPrerequisites......................................................................................................17-2

Editing the Hidden Tasks Component ..............................................................17-2


Version 2.1


Introduction to Plus

Modules

5Introduction to Plus Modules

Plus modules have features, such as tasks and monitors, for managingan application in the Tivoli Management Software environment. Eachof these features is defined in a component description file (CDF)which also references the scripts and programs required to implementthe feature. A Plus module can have multiple CDFs, each defining aspecific feature. Plus components do not have a single platformlimitation. In other words, the scripts and programs used to implementthe component’s function should accommodate all required platforms.

The Tivoli Module Builder provides a template to assist you indefining the Plus module’s components. The Plus template providesone or more “component types” for each of the Plus module features.Some of the component types have predefined instances of items suchas operational tasks and installation dependencies that wouldcommonly be defined for an application.

5

Loading the Plus Module Template

5–2 Version 2.1

Loading the Plus Module TemplateThe following procedure assumes that you have set up a project withthe Tivoli Module Builder and added a module to the project.

Use the following steps to load the Plus template:

1. Display the module’s property tabs by highlighting the module inthe Tivoli Module Builder workspace.

Loading the Plus Module Template



Modules

2. Click on theLoad Templatebutton. This action displays theOpen dialog for locating the files on your system.

Note: Because the Tivoli Module Builder is a JAVA-basedapplication, the exact title of certain dialogs, such as the“open” dialog, may be different on different platforms.

3. Use theOpen dialog to locate the directory where the Plustemplate is located. The default location for this template is thefollowing:

/module_dev/Toolkit/templates/Module/PlusModule.v2_1.template

4. Select thePlusModule.templatefile and click on theOpenbutton. The Plus template will be imported into your module’sdirectory structure under the/Module_dev/Projects directory.

When importing the Plus template, the Tivoli Module Builder createsa src directory,test directory, and askeletons directory. Thesrcdirectory contains the programs and scripts referenced in the Plustemplate CDF files. Thetest directory contains the test cases fortesting the program and script files. This directory is empty until youactually run the test. Theskeletons directory contains the skeletonfiles used to generate the script stubs.

Plus Module Component Types

5–4 Version 2.1

Plus Module Component TypesThe following describes the Plus component types. When you defineeach component, you give the component a specific name. Theprocedure for importing the Plus template is described in “Loading thePlus Module Template” on page 5-2.

The following graphic shows the Plus template displayed in the TivoliModule Builder workspace.




Modules

Icons for <App Name>This component defines the information required to display yourapplication’s icon in the Plus module. For information on defining thiscomponent, see Chapter 6, “Application Icons.”

Launch <App Name>This component defines the information necessary for the user tolaunch your application from the module. You can define variouslogical entry points for your application. The logical entry point is thescreen or utility that is displayed when the user launches theapplication. For information on defining this component, see Chapter7, “Application Launch.”

Set Install Options for <App Name>This component defines the installation options task. An installationoptions task prompts the user for site-specific information that isrequired in order for the Plus module to manage a particularapplication. For example, if your application has a database, the usermay need to specify the database type when installing the Plus module.For information on defining this component, see Chapter 8, “InstallOptions.”

Plus Configuration for <App Name>The component defines a configuration task that runs during the Plusmodule’s installation. The configuration task can also be run at anytime after installation on selected subscribers. For information ondefining this component, see Chapter 9, “Plus Configuration.”

Subscribers of <App Name>This component defines a subscription list that is to be included in themodule. It also identifies a script that, when run on a node duringmodule installation, determines whether that node should be added tothe subscription list. The resulting subscription list contains a list ofprofile managers and machines that are to be the recipient of aparticular activity, such as a distribution and installation. You may


5–6 Version 2.1

define multiple subscription lists for a module. For information ondefining this component, see Chapter 10, “Subscription Lists.”

Administrative Tasks for <App Name>This component identifies your application’s tasks that you want theuser to be able to run and manage with the Plus module. Forinformation on defining this component, see Chapter 11,“Administrative Tasks.”

Client Filepack Distribution for <App Name>This component defines the information necessary for using a TME 10Software Distribution file package to distribute and install yourapplication’s client onto multiple machines and platforms. Forinformation on defining this component, see Chapter 12, “FilePackages.”

Server Filepack Distribution for <App Name>This component defines the information necessary for using a TME 10Software Distribution file package to distribute and install yourapplication’s server onto multiple machines and platforms. Forinformation on defining this component, see Chapter 12, “FilePackages.”

Ancillary Filepack for <App Name>This component defines the information necessary for creating anancillary or “nested” file package. The ancillary file package is onethat is “nested” or included in another file package. For information ondefining this component, see Chapter 12, “File Packages.”

Indicators for <App Name> MonitorsThis component defines the indicator collection that reports the statusof your application’s monitored resources. For information on definingthis component, see Chapter 13, “Indicator Collections.”




Modules

Universal MonitorsThis component defines specific instances and thresholds for thepredefined universal monitors provided with the Tivoli ModuleBuilder. The universal monitors are those that run on both UNIX andWindows NT platforms. For information on defining this component,see Chapter 14, “Monitors.”

Monitors for <App Name>This component defines specific instances and thresholds for yourapplication’s custom monitors (some predefined monitors are alsoincluded with this component). For information on defining thiscomponent, see Chapter 14, “Monitors.”

TEC Configuration for <App Name>This component configures the TME 10 Enterprise Console to readand respond to events forwarded to it. For example, if you have custommonitors, the TME 10 Enterprise Console will need to be configuredto receive events forwarded by the custom monitors. For informationon defining this component, see Chapter 15, “TME 10 EnterpriseConsole Configuration.”

Logfile Adapter Configuration for <App Name>This component configures the TME 10 Enterprise Console logfileadapter to read your application’s events and forward them to the TME10 Enterprise Console. For information on defining this component,see Chapter 16, “Logfile Adapter Configuration.”

Hidden Tasks for <App Name>This component defines the hidden tasks that are to be included in themodule. Hidden tasks are automatically initiated in response tospecific conditions but are not directly initiated by the module’s user.For information on defining this component, see Chapter 17, “HiddenTasks.”

Component Definition Categories

5–8 Version 2.1

Component Definition CategoriesFor each component, the Tivoli Module Designer has tabs with fieldsfor specifying a particular category of information required for theoverall component definition. These categories are displayed in agraphical “tree” format on the left side of theTivoli Module Designer.Clicking on one of these categories displays the tabs required tocomplete the information for that category of the componentdefinition. You may define more than one instance in each category.For example, you may have a component that needs to define morethan one operational task. To do this, you define theOperationalTasks category more than once, with each definition referencing aseparate task. In this case, each task definition is an instance of theOperational Tasks category. After definition, instances of a particularcategory are displayed in the Tivoli Module Designer and can beselected for additional modification.




Modules

The following graphic shows the administrative tasks componentexpanded to display the component definition categories.

Although the full list of possible categories is displayed for eachcomponent, most components do not require that all categories bedefined.

The following sections describe the type of information specified foreach category.

Location DefinitionsSpecifies where the files required by a component are located. Forexample, when defining the file package component, you need tospecify directory information indicating the location of yourapplication’s executables.


5–10 Version 2.1

File ListSpecifies the files that may be distributed to a target system or scriptsthat are run when a component’s particular function is initiated. Forexample, your application’s.xpm files (used to display the applicationicon) are specified in the file list. Usually, only a simple file name isrequired for the file list, although a directory can also be specified.

Installation ProgramsSpecifies the programs (such as before and after installation scripts)associated with installing or removing the software component’s files.These programs run on each target machine during the installationprocess. They are loaded from a distribution server rather than aCD-ROM.

Installation DependenciesSpecifies the criteria that must be met before a component’s files canbe installed. Some of the components in the Plus template havepredefined instances of the installation dependencies.

Operational TasksSpecifies the tasks that are initiated by the Plus module’s user or Tivolisoftware. For example, an operational task may be one of yourapplication’s tasks run by the user or a hidden event correlation taskinitiated by the TME 10 Enterprise Console. The task definitionincludes the task name, script location, and any arguments that the usermust supply to run the task.

Synchronous MonitorsSpecifies the monitors and monitor instances that will periodicallycheck the status of your application’s critical resources. You need todefine the monitor type, which identifies the type of resource beingmonitored (for example, directory free space), and specific instancesof each monitor. An instance of a monitor identifies the specific nameof the resource and its threshold levels. For example, a “foo” instanceof the directory free space monitor checks the available free space inthe “foo” directory. A threshold is the point where a resource’s status

Plus Modules in the Tivoli Management Software Environment



Modules

changes from one significant level to another. In the case of theexample “foo” instance, a threshold may be set to “less than 2 MB.”You can specify that a task be run in response to changes in aresource’s status.

When you define a monitor component, you are creating a monitorcollection that contains one or more monitors (and the monitorinstances). You can create a monitor collection using the predefinedmonitors provided with the Tivoli Module Builder or create a monitorcollection containing custom monitors for your application.

Management Tool ExtensionsThe management tool extensions category specifies information abouta software component that is intended for a particular managementtool. For example, all component types in the Plus template have apredefined management tool extensions instance that associates thecomponent with the Tivoli Plus module.

Additional management tool extension instances are used to specifythe relationship that a component may have to another component. Forexample, when defining a monitor collection, you would want toidentify the indicator collection that is associated with the monitorcollection. (An indicator collection displays the status of the monitorsit is associated with.)

Plus Modules in the Tivoli Management SoftwareEnvironment

The following sections depict an example installation of a Plusmodule.

After the administrator installs the module using the standard TivoliManagement Software installation process, aTivoliPlus icon isdisplayed on the desktop. TheTivoliPlus icon is a collection for Plusmodules. When additional Plus modules are installed, they will beadded to this collection.

Double-clicking theTivoliPlus icon displays theTivoliPlus window,which has an icon for every installed Plus module. In the following


5–12 Version 2.1

example, only the<App Name> Plus for Tivoli icon is displayed intheTivoliPlus window.

To open a Plus module, double-click on the module’s icon. This actiondisplays a window containing the icons for activating the module’s




Modules

features. The icons, their menu options, and the tasks they run aredefined with the Tivoli Module Builder as described in later chapters.

Activating the Plus Module’s Features

5–14 Version 2.1

Activating the Plus Module’s FeaturesThe Plus module’s features are activated by double-clicking on theirrespective icons. In some cases, the system’s default response is to runa task without prompting for further information. In other cases, apop-up dialog prompts the user for additional information. Each iconalso has a pop-up menu with options for running or customizing thetask’s execution.


Application Icons

6Application Icons

When defining the application icons component, you define thebitmaps used to display your application’s icon in the Plus module.Your application’s icon has two functions in the Plus module:

■ Plus Module Icon. The Plus module is represented by yourapplication’s icon with the Plus symbol superimposed over it.This icon is located in the Plus module’sTivoliPlus windowalong with the icons for other modules. The module can beopened by double-clicking on this icon or selecting theOpen...option from this icon’s pop-up menu. The following is anexample of a Plus module icon. The options on the icon’s pop-upmenu are also displayed.

6

Prerequisites

6–2 Version 2.1

■ Application Launch Icon. This icon is included with the othericons in the Plus module’s collection, but does not have a Plussymbol superimposed over it. The user can double-click on thisicon or select one of the application’s logical entry points fromthe icon’s pop-up menu to launch the application. The followingis an example of an application launch icon. In this example, asample application is installed on a server namedaharrison. Thelogical entry points on this icon’s pop-up menu are alsodisplayed.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define the application icons. This procedure also assumes that youhave done the following:



■ Loaded the Plus template into the module as described in“Loading the Plus Module Template” on page 5-2.

When you have completed these activities, continue with “Editing theApplication Icons Component” on page 6-3.

Editing the Application Icons Component


Application Icons

Editing the Application Icons ComponentUse the following procedure to define the application icons. In thisprocedure, only theComponent Data andFile List categories requiredefinition. When completing this procedure, you will define twobitmap (or.xpm) files for displaying the Plus module and theapplication launch icons.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the application icons component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.

1. Select the module into which you have imported the Plustemplate in the Tivoli Module Builder workspace and click on theEdit AMS Definition button. This action launches the TivoliModule Designer for editing the Plus module’s component. Youcan also select one of the Plus template components and click ontheEdit Component button in order to launch the Tivoli ModuleDesigner.

2. Select theIcons for <App Name> component in the TivoliModule Designer workspace. This action displays theComponent Data tab.


6–4 Version 2.1

3. Use theComponent Data tab to specify general informationrequired to identify the component. This information includes thename, version, and manufacturer of the component. Thecombined values of theName, Version, andManufacturerfields form a unit (or “triplet”) of information that must be uniqueacross all components in a module. When defining more than onecomponent, it is sufficient to change the value of just one of thesefields to ensure a unique combination.

The generate and build process for Plus modules assume that thePlus components are capable of running on more than oneplatform. This means that each script referenced by thecomponent must be able to accommodate all platforms on whichthe component is to run. If the component is to run on more thanone platform, then the optionalDestination field should specifyUnknown.



Application Icons

Complete the following required fields on theComponent Datatab.

NameEnter a name for the component. For example, you might enter<ApplicationName> Icons.

VersionUse these fields to specify the version of the component. You canchange the version in these fields to keep track of changes whenupdating a component. Specify the version in the followingformat: a major version number, a minor version number, and arevision indicator. The major and minor numbers are required. Therevision indicator is optional. After MIF parsing is complete, theelements in this format appear as follows:MajorNumber.MinorNumberRevisionIndicator. For example,4.52A or 1.1.3.

ManufacturerEnter the name of the manufacturer for this software component.

Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isApplication Icons.

Note: The default values in these fields should not be changedwhen using the Plus template to define a component.

When you are ready, click on theUpdate button. The TivoliModule Designer displays the name that you have specified forthis component in the workspace.


6–6 Version 2.1

4. Click on theIcons for <App Name> component’s “tree controlbutton” (the box containing the + symbol). This action displaysall of the component definition categories.

5. Select theFile List category. TheFile List tab enables you tospecify the icon or bitmap files for your application’s icons.When defining the application icons component using the Plustemplate, two file list instances have been predefined for you. Thedefault names for these instances areTME10.xpm andTME10Plus.xpm. TheTME10.xpm instance is the file for theapplication launch icon bitmap.

TheTME10Plus.xpm instance is the file for the module’s iconbitmap. This icon is overlaid with the Plus symbol because itrepresents the Plus module for your application. The Plus symbolis provided in this file.



Application Icons

After generating the module, these files are available in yourmodule’ssrc directory. You do not need to specify a source ordestination directory for these files as long as you do not removethese files from your module’ssrc directory. You need to edit orreplace these.xpm files with the bitmaps for your application.

Complete the following required field:

File NameModify the file name if you wish. It is not required to change thedefault names of the.xpm files.

Note: Although the Tivoli Module Designer displays aSignature tab next to theFile List tab, Plus modules donot use the information specified on theSignature tab.


6–8 Version 2.1

Each Plus component type has a predefinedMgmt Tool Extensionsinstance that associates the component with the Plus module. Thedefault management tool name for this instance isTIVOLI_PLUS_3_0. Its default variable name isMODULE_TYPEwith a value ofPLUS. This predefined instance should not be deletedor its values changed.


Application Launch

7Application Launch

The Plus module displays your application launch icon using thebitmap you specified for the application icons component. (SeeChapter 6, “Application Icons” and step 5 on page 6-6 for moreinformation.) This icon has a menu with options for launching yourapplication at specificlogical entry points. A logical entry point is ascreen or utility that the user is likely to wish displayed. For example,selecting a certain logical entry point might allow you to browse thelog files created by your application. You can configure the module sothat when it is installed, an application launch icon is provided for eachserver on which your application is installed. The icon name has thefollowing format:ApplicationName@ServerName. The following isan example of a launch icon for a server namedaharrison. The logicalentry points on the icon’s pop-up menu are also displayed.

7

Prerequisites

7–2 Version 2.1

The application launch component specifies the information necessaryto create the application launch icon and to launch the application atthe specified logical entry points. This information includes thelocation of the application’s executables and the name for theapplication launch icon.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define the application launch. This procedure also assumes that youhave done the following:




When you have completed these activities, continue with “Editing theApplication Launch Component” on page 7-2.

Editing the Application Launch ComponentUse the following procedure to define the application launch icon andits menu options. In this procedure, only theComponent Data andOperational Task options require definition. When this procedure iscomplete, you will have defined the application launch icon’s name,menu items, and the programs that run when the Plus user selects theicon’s menu options.

Some applications may require that more than one application launchicon be specified. For example, an application may have functions thatare only available on a server and other functions that are onlyavailable on a client. In this case, the following procedure should becompleted twice: once for launching the application from the serverand once for launching the application from a client.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the application launch component is

Editing the Application Launch Component


Application Launch

noted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.


2. Select theLaunch <App Name> component in the TivoliModule Designer workspace. This action displays theComponent Data tab.

3. Use theComponent Data tab to specify general informationrequired to identify the component. This information includes the


7–4 Version 2.1

name, version, and manufacturer of the component. Thecombined values of theName, Version, andManufacturerfields form a unit (or “triplet”) of information that must be uniqueacross all components in a module. When defining more than onecomponent, it is sufficient to change the value of just one of thesefields to ensure a unique combination.



NameEnter a name for the component. Since the name you enter is thetitle for your application launch icon, enter a name that identifiesyour application. This name can contain any printable charactersincluding embedded spaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isApplication Launch .



Application Launch



4. Click on theLaunch <App Name> component’s “tree controlbutton” (the box containing the + symbol). This action displaysall of the component definition categories.

5. (Optional). Select theInstallation Dependenciescategorydisplayed to the left of the component’s tabs. TheInstallationDependencies tab enables you to specify the criteria that must bemet before a component can be installed. The application launchcomponent has a predefinedApplication_Server_Checkinstance and anOS Version instance in this category. You can


7–6 Version 2.1

define additional instances of an installation dependency. If youare not defining an installation dependency, continue with step 6on page 7-7.


Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. For an application launchcomponent, you would typically specify a custom dependency fordetermining whether an application launch icon should be createdfor a particular node.




Application Launch




6. Select theOperational Taskscategory displayed to the left ofthe component’s tabs. TheOperational Taskstab enables you todefine the application launch icon’s menu items. Complete thistab once for each launch item you wish to define. The component


7–8 Version 2.1

description file (CDF) generated for this component definitionwill reference each of the tasks you specify.


Task NameEnter the task name. The name that you enter will be a menu optionon the launch icon’s menu in the Plus module. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.

Program NameEnter the name of the program that launches your application. Thename must be alphanumeric (a–z, A–Z, 0–9, plus underscores).Spaces are not allowed. Generating the Plus module produces ascript stub with this name. The script stub has a placeholder forinserting your application’s script.



Application Launch



7–10 Version 2.1


Install Options

8Install Options

Some applications require that the user provide site-specificinformation before the application can be managed with the Plusmodule. Examples of such information are machine names anddatabase types. To obtain this site-specific information, you can definean install options icon for each managed node. This icon defines asingle task that allows the user to set configuration information on thenode that is represented by the icon. The user may run this task asnecessary after the Plus module’s installation. The install options taskdisplays a dialog that prompts the user for the necessary information.

8

Prerequisites

8–2 Version 2.1

The following is an example of an install options task icon. This taskicon is similar to the application launch icon.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define an installation options task. This procedure also assumes thatyou have done the following:




When you have completed these activities, continue with “Editing theInstall Options Component” on page 8-2.

Editing the Install Options ComponentUse the following procedure to define an install options task. Whendefining the install options component, only theComponent Dataelement requires specification.

Editing the Install Options Component


Install Options

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the install options component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.


2. Select theSet Install Options for <App Name> component inthe Tivoli Module Designer workspace. This action displays theComponent Data tab.


8–4 Version 2.1




NameEnter a name for the component. Since the name you enter is thetitle for the install options task icon, enter a name that identifiesyour application. This name can contain any printable charactersincluding embedded spaces.





Install Options

Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isApplication Launch .



4. Click on theSet Install Options for <App Name> component’s“tree control button” (the box containing the + symbol). Thisaction displays all of the component definition categories.

5. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteria


8–6 Version 2.1

that must be met before a component’s files can be installed. Theinstall options component has a predefinedApplication_Server_Check instance in this category whichmay be edited or replaced with a reference to your own script thatdetermines whether or not application configuration optionsshould be stored on the node. During module installation, aninstall options icon is created for every installed node that passesthis check. You can define additional instances of an installationdependency. If you are not defining an installation dependency,continue with step 6 on page 8-7.



Install Options







6. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify a task that the user can run afterinstalling the Plus module in the event that the options set duringinstallation need to be changed. The install options componenthas a predefinedProduct_Install operational task instance. Thescript stub generated for the predefinedProduct_Installoperational task instance contains special logic for savingconfiguration information on a particular node. For this reason,the Plus module only recognizes the predefinedProduct_Installoperational task instance for this component. You should notcreate additional instances, although you can modify the


8–8 Version 2.1

generated script stub for theProduct_Install instance to performadditional configuration on the node.



Plus C

onfiguration

9Plus Configuration

The Plus configuration component includes a Plus configuration taskthat can be run during the Plus module’s installation. This task can alsobe run after installation on nodes included in a subscription list.Although the Plus configuration task is similar to the install optionstask, it allows the user more flexibility in specifying the nodes onwhich the task will run.

The Plus configuration component may also be used to specifyoperational tasks that would not normally be associated with one of theother components. For example, the Plus configuration component hasa predefined operational task instance for displaying information (suchas version information) about the application.

9

Prerequisites

9–2 Version 2.1

The following is an example of a Plus configuration task icon.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define a Plus configuration task. This procedure also assumes thatyou have done the following:




When you have completed these activities, continue with “Editing thePlus Configuration Component” on page 9-2.

Editing the Plus Configuration ComponentUse the following procedure to define a Plus configuration task. Whendefining the Plus configuration component, theComponent Data andOperational Taskselements require specification.

Editing the Plus Configuration Component


Plus C

onfiguration

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the Plus configuration component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.


2. Select thePlus Configuration for <App Name> component inthe Tivoli Module Designer workspace. This action displays theComponent Data tab.


9–4 Version 2.1




NameEnter a name for the component. Since the name you enter is thetitle for the Plus configuration task icon, enter a name thatidentifies your application. This name can contain any printablecharacters including embedded spaces.





Plus C

onfiguration

Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isPlus Configuration.

Note: The default values in these fields cannot be changedwhen using the Plus template to define a component.


4. Click on thePlus Configuration for <App Name> component’s“tree control button” (the box containing the + symbol). Thisaction displays all of the component definition categories.


9–6 Version 2.1

5. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. ThePlus configuration component has predefined instances of theinstallation dependencies. You can define additional instances ofan installation dependency. If you are not defining an installationdependency, continue with step 6 on page 9-7.






Plus C

onfiguration




6. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify configuration tasks that can be runduring and after the Plus module’s installation. The Plusconfiguration component has a predefinedPlus_Configurationtask instance. The Plus configuration component also has apredefinedCreate_Subscriber_List task instance and anAbout_AppName instance. TheCreate_Subscriber_Listinstance specifies a task for creating a subscription list that canbe used by tasks, file packages and monitors in the installedmodule. TheAbout_AppName instance specifies a task thatdisplays information about the application. You can modify thesepredefined instances and create additional operational taskinstances.

Complete this tab once for each task you wish to define. Thecomponent description file (CDF) generated for this componentdefinition will reference each of the tasks you specify.


9–8 Version 2.1

Generating the Plus module produces a script stub for each scriptor program specified in the task definition. You must edit thesestubs with the scripts for running the task.


Task NameEnter a description of what the task does. The name that you enteris the title for the task icon displayed in the Plus module. Examplesof task (or task icon) names are<ApplicationName>_Setup, or<ApplicationName>_Configuration. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.



Plus C

onfiguration

Program NameEnter the name of the program that is invoked by the task. Thename must be alphanumeric (a–z, A–Z, 0–9, plus underscores).Spaces are not allowed. Generating the Plus module produces ascript stub with this name. The script stub has a placeholder forinserting your application’s script.

Note: If you want the Plus configuration task to run during themodule’s installation, the program should be namedPLUSconfig.sh.




9–10 Version 2.1

7. Select theMgmt Tools Extensions category. The Plusconfiguration component has defaultTIVOLI_PLUS_3_0instances in this category.

The default instances associate the Plus configuration componentwith the module or with another component. The followingdescribes the default management tool extension instances. Thedefault instances are identified by the value in theVariableName field.

MODULE_TYPEThis instance associates the Plus configurationcomponent with the Plus module. This defaultinstance should not be changed.

SUBSCRIPTION_LISTThis instance associates the Plus configurationcomponent with a subscription list. You should



Plus C

onfiguration

edit this instance’sVariable Value field with thecomponent name of the subscription list.

The following describes how to complete the fields on theMgmtTool Extensions tab should you need to create additionalinstances in this category.

Tool NameEnterTIVOLI_PLUS_3_0 in this field. This value is required inorder to be compatible with the Version 3.0 Plus modulesgenerated by the current version of the Tivoli Module Builder.

Data TypeSelect theString radio button.

Variable NameEnterSUBSCRIPTION_LIST in this field.

Variable ValueThis field identifies the component to which you are establishinga relationship. Enter the value displayed in theNamefield of therelated component’sComponent Data tab. For example,enteringSubscribers of <Application Name> in this fieldindicates that the Plus configuration component should bedistributed to the nodes that subscribe to the component namedSubscribers of<Application Name>.


9–12 Version 2.1


Subscription Lists

10Subscription Lists

The Plus module includes default subscription lists, each of whichcontains a list of profile managers and machines that are to be therecipient of a particular activity, such as a distribution and installationor the execution of a task. The machines included in a particulardefault subscription list have a related function. For example, themodule may have a server subscription list containing the names ofyour application’s servers and a client subscription list containing thenames of your application’s clients.

The subscription lists provide an efficient method for specifying onwhich machine a task should run, and facilitate running a task onmultiple machines at the same time. The Plus module user can modifythe execution characteristics of a task so that the task can run onnon-default subscription lists as well as on specific nodes. The Plusmodule user can also modify the default subscription list. The

10

Prerequisites

10–2 Version 2.1

following is an example of the subscription list icon for a sampleapplication. The option on the icon’s pop-up menu is also displayed.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define a subscription list. This procedure also assumes that you havedone the following:




When you have completed these activities, continue with “Editing theSubscription List Component” on page 10-3.

Editing the Subscription List Component


Subscription Lists

Editing the Subscription List ComponentUse the following procedure to define a subscription list. When thePlus module is installed in a Tivoli Management Software installation,the subscription lists will contain site-specific machine names.Because it is impossible to know these machine names in advance, youmust have a rule that defines which machines should be added to aparticular subscription list. For example, you may have a rule foridentifying the server machines that are to be added to the serversubscription list. You may also have another rule for adding machinesto a client subscription list. These rules are applied when the Plusmodule is installed on each machine by running a script specified as aninstallation dependency. Complete this procedure once for eachsubscription list you wish to define. In this procedure, theComponentData option requires definition. If you have more than onesubscription list, then theDefine New Dependencyoption alsorequires definition in order to determine which machines are added towhich list.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the subscription list component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.


10–4 Version 2.1


2. Select theSubscribers of <App Name> component in the TivoliModule Designer workspace. This action displays theComponent Data tab.

3. Use theComponent Data tab to specify general informationrequired to identify the component. This information includes thename, version, and manufacturer of the component. Thecombined values of theName, Version, andManufacturer



Subscription Lists

fields form a unit (or “triplet”) of information that must be uniqueacross all components in a module. When defining more than onecomponent, it is sufficient to change the value of just one of thesefields to ensure a unique combination.



NameEnter a name for the component. Since the name you enter is thetitle for the subscription list icon, enter a name that identifies thesubscription list. This name can contain any printable charactersincluding embedded spaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isSubscription List.



10–6 Version 2.1


4. Click on theSubscribers of <App Name> component’s “treecontrol button” (the box containing the + symbol). This actiondisplays all of the component definition categories.

5. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component can be installed. Thesubscription list component has a defaultApplication_Client_Check installation dependency instance foradding your application’s clients to the subscription list. Thisdefault instance provides an example that you may wish to use,or you can create new instances of the installation dependency. In



Subscription Lists

either case, you need to customize the generated script so that itreturns a true (0) value if the node is to be added to thesubscription list. You can, however, create new instances of theinstallation dependencies.

Note: If you wish to create a subscription list for machinesother than your application’s clients, then you need todefine a new subscription list component. Whencompleting this procedure for the new component, youcould change the default installation dependencyinstance to reflect the type of machine that should beadded to the subscription list.


10–8 Version 2.1









Adm

inistrative Tasks

11Administrative Tasks

Your application may have various tasks or jobs that you wish toexecute and manage from the Plus module. Once a subscription list hasbeen associated with a task, the module’s user can execute the task onmultiple machines and platforms by double-clicking on the task’s icon.The module’s user can also specify the execution characteristics of thetask, such as the machines on which the task will run, where the task’soutput will be displayed, and whether the tasks will run in parallel onall machines or be staged in groups of machines.

11

Prerequisites

11–2 Version 2.1

The following is an example of a task icon for a sample application.The options on the icon’s pop-up menu are also displayed.

The task collection defined by the administrative tasks componentidentifies which application tasks are to be run and managed from themodule. When defining this component, you provide the name of thetask program that is to be executed from the module and anyarguments that the module’s user must supply to run the task.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define administrative tasks. This procedure also assumes that youhave done the following:




Editing the Administrative Tasks Component


Adm

inistrative Tasks

When you have completed these activities, continue with “Editing theAdministrative Tasks Component” on page 11-3.

Editing the Administrative Tasks ComponentUse the following procedure to define a task. When completing thisprocedure, you will first define the task collection with theComponent Data tab. You will then add tasks to the task collectionwith theOperational Tasks tab. Once you have created the taskcollection, you can assign all tasks in the collection a defaultsubscription list with theMgmt Tools Extensiontab. (The Plusmodule’s user will be able to modify a task’s execution targets if theywish.)

When installing the module, a task library is created for thiscomponent. This task library is populated with the tasks defined in thiscomponent.

You may wish to have more than one task collection in your module.For example, your application may have tasks that require differentsubscription lists. These tasks would be in different task collections.To create an additional task collection, define another administrativetasks component.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the administrative tasks componentis noted in these field descriptions. General field information,including the optional fields, is provided in the online help.


11–4 Version 2.1


2. Select theAdministrative Tasks for <App Name> componentin the Tivoli Module Designer workspace. This action displaystheComponent Data tab.




Adm

inistrative Tasks




NameEnter a name for the task library. The name you enter shouldrepresent all tasks that are to be included in this library. Thisname can contain any printable characters including embeddedspaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isAdministrative Tasks.



11–6 Version 2.1


4. Click on theAdministrative Tasks for <App Name>component’s “tree control button” (the box containing the +symbol). This action displays all of the component definitioncategories.

5. (Optional). Select theInstallation Dependenciescategory. Thetab in this category enables you to specify the criteria that mustbe met before a component’s files can be installed. If you are not



Adm

inistrative Tasks

defining an installation dependency, continue with step 6 onpage 11-8.


Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. Since the administrative tasks areinstalled on a Tivoli Management Region (TMR) server, youwould specify a custom dependency for a script that returns a valueof true (0) if a node is a TMR server.



11–8 Version 2.1

Dependency NameEnter a description of the custom dependency. An example of adependency name isTMR_Server_Check.The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.



6. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify an administrative task. Complete thistab once for each task you wish to define. The componentdescription file (CDF) generated for this component definitionwill reference each of the tasks you specify. If you do not defineany tasks, the Plus module’s task library will be empty.



Adm

inistrative Tasks



Task NameEnter a description of what the task does. The information that youenter is the title for the task icon displayed in the Plus module.Examples of task (or task icon) names areStart_Servers orPrint_Runtime Statistics_Report. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.


11–10 Version 2.1

Program NameEnter the name of the program or script that is invoked by the task.The name must be alphanumeric (a–z, A–Z, 0–9, plusunderscores). Spaces are not allowed. Generating the Plus moduleproduces a script stub with this name. The script stub has aplaceholder for inserting your application’s script.






Adm

inistrative Tasks

7. Select theMgmt Tools Extensions category. The administrativetask component has defaultTIVOLI_PLUS_3_0 instances inthis category.

The default instances associate the administrative taskcomponent with the module or with another component. Thefollowing describes the default management tool extensioninstances. The default instances are identified by the value in theVariable Name field.

MODULE_TYPEThis instance associates the administrative taskcomponent with the Plus module. This defaultinstance should not be changed.

SUBSCRIPTION_LISTThis instance associates the administrative task


11–12 Version 2.1

component with a subscription list. You shouldedit this instance’sVariable Value field with thecomponent name of the subscription list.





Variable ValueThis field identifies the component to which you are establishinga relationship. Enter the value displayed in theNamefield of therelated component’sComponent Data tab. For example,enteringSubscribers of <Application Name> in this fieldindicates that the administrative tasks component should bedistributed to the nodes that subscribe to the component namedSubscribers of<Application Name>.


File P

ackages

12File Packages

File packages contain the information necessary to distribute andinstall your application on multiple machines and platforms with TME10 Software Distribution. Because the user typically has to provideinformation specific to the distribution and installation of anapplication at a particular site, the module provides a setup task forconfiguring a file package instead of complete file packages. The setuptask utilizes a “prewritten” file package that provides basicinformation required by TME 10 Software Distribution. When the userruns this task, pop-up dialogs appear prompting for the user-suppliedinformation. The following is an example of a file package setup icon

12

12–2 Version 2.1

for a sample application. The options on the icon’s pop-up menu arealso displayed.

When you define the file package component, you are specifying theinformation necessary to create a file package setup task in the module.You will specify this component for each portion of your applicationthat will be distributed and installed. For example, if you have both aclient and server application, then you may specify a file package setuptask for both of these applications.

This component also specifies the files required for your application’sinstallation as well as the default source directory for the installationbinaries and the default destination directory on the target machines.When defining this component, you specify the arguments that the usersupplies as well as the name of the program that executes when theuser runs the file package setup task.

It is not necessary to specify a setup task in a file package component.If none is specified, the file package is created when the module isinstalled, based on the information in the component description file(CDF). If a setup task is specified, the file package is not created atinstall time. Instead, it is created as a result of running the setup task.A typical example of a file package that does not have a setup task isone that is intended to be nested by other file packages. The setup taskof another file package component may refer to the nested file package.

Prerequisites


File P

ackages

An example of a nested file package is the Ancillary Filepack for<AppName> component in the template.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define file packages. This procedure also assumes that you havedone the following:




When you have completed these activities, continue with “Editing theFile Package Component” on page 12-3.

Editing the File Package ComponentUse the following procedure to define a file package. When definingthe file package component, theComponent Data, andOperationalTask options require definition.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the file package component is notedin these field descriptions. General field information, including theoptional fields, is provided in the online help.

Editing the File Package Component

12–4 Version 2.1


2. Select one of the file package components in the Tivoli ModuleDesigner workspace. This action displays theComponent Datatab for the file package you selected.




File P

ackages




NameEnter a name for the component. Since the name you enter will bethe title of the Plus module icon that distributes the file package,enter a name descriptive of the file distribution. This name cancontain any printable characters including embedded spaces.

Note: Nested file packages do not have icons in the installedPlus module.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isFile Package Definition.


12–6 Version 2.1



4. Click on the file package component’s “tree control button” (thebox containing the + symbol). This action displays all of thecomponent definition categories.

5. (Optional). Select theLocation Definitions category. TheLocation Definitions tab enables you to define symbolic names



File P

ackages

for directories associated with this component. If you are notdefining location definitions, continue with step 6 on page 12-8.


Symbolic NameUse theSymbolic Namemenu to select the symbolic name thatyou wish to define. If you wish to define a symbolic name not onthis list, select<User Defined>.

TheSymbolic Namemenu displays a list of possible symbolicdirectory names that you can define for this software component.Once you have defined a symbolic directory name, you should usethe symbolic name throughout the software component definition.The symbolic directories that you define here will appear on thesymbolic name menus of other tabs.


12–8 Version 2.1

6. (Optional). Select theFile List category. TheFile List tabenables you to define the files (such as installation binaries) thatwill be distributed and installed with the file package. Each of thefile package components provided with the Plus template havepredefined file list instances. You can modify these predefinedinstances or create new ones.

Complete the following required fields on theFile List tab. Youcan specify these fields more than once to include different files.After completing this tab, click on the<Add button.



File P

ackages

File NameEnter the names of those files (installation binaries) required fora file package to successfully distribute and initiate theapplication’s installation process. You can specify a file name, apath to a file, or a directory. When using a simple file name, usetheSource Locationfields to specify the directories where thefile is located.

Note: You may also specify a directory in theFile Name field. Ifthere are certain files in a directory that you wish toexclude, you may exclude these files by specifying them intheFile Name field with an ampersand (&) before the filename.

Source LocationUse theSymbolic Name menu to select a symbolic name for thesource location of the file. The symbolic names that you havedefined with theLocation Definitions category appear on thismenu.

Destination LocationUse theSymbolic Name menu to select a symbolic name for thedestination location of the file. The symbolic names that you havedefined with theLocation Definitions category appear on thismenu.


7. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. Thefile package components provided with the Plus template havepredefined instances of the installation dependencies. You cancreate additional installation dependencies. If you are not


12–10 Version 2.1



Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. Since the file package setup tasksand the ancillary (nested) file packages are only created when thePlus module is installed on a Tivoli Management Region (TMR)server, you would specify a custom dependency script that returnsa “true” (0) value if the node is a TMR server.




File P

ackages




8. (Optional). Select theInstallation Programs category. TheInstallation Programs tab enables you to define programs, suchas configuration scripts, that run when your application is


12–12 Version 2.1

installed. If you are not defining an installation program,continue with step 9 on page 12-12.


Program FunctionUse the menu in this field to select the scripts or programsassociated with installing or removing the software component’sfiles. These programs run on each target machine during theinstallation process.

Program File NameEnter the file name of the program associated with installing orremoving the software component.

9. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify a file package setup task with



File P

ackages

arguments that the user supplies to configure a specific instanceof the file package. You might create more than one setup task toserve different functions. For example, you might have differentsetup tasks for file packages that distribute to UNIX platformsand Windows platforms. The Plus module’s user may alsocomplete the same setup task more than once to create differentfile packages. For example, the user might complete a UNIXsetup task more than once to create file packages for the differentbrands of UNIX. The file packages generated by the setup taskare distributed with the icon specified in theComponent Namefield on theComponent Data tab.

The Plus template provides file package component types withpredefined file package setup tasks. These tasks vary dependingon which type of file package component (for example, client orserver) you are defining. A default implementation of the scriptsfor these setup tasks are also provided. You may find that thepredefined setup tasks are sufficient for your application. If youwish to create additional tasks, you can do so using the defaulttask as a model. When creating additional tasks, be sure that thescript name in theProgram Name field is unique for each task.


12–14 Version 2.1


Task NameEnter a description of what the task does. The information that youenter is the title for this task icon in the module. Examples of task(or task icon) names areSetup_UNIX_Server_Install orSetup_Windows_Client_Distribution. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.

Program NameEnter the name of the program that implements the file packageconfiguration. This name must be unique. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed. Generating the Plus module produces a script with thename specified in this field. This script contains a default header



File P

ackages

that sets up the environment for file package distribution. When theuser runs this script (by double-clicking on the icon with the namespecified in theTask Name field), the script generates a filepackage.

Argument NameEnter a descriptive name for any arguments that the programexpects the user to provide and click on the< button to move theargument to theArguments list box. You can use the predefinedoperational task instance for an example of the arguments thatshould be supplied. Examples of arguments include interpreter,source host, source staging, and so forth.

Add any additional arguments required by the program.

When the Plus user runs this task, a pop-up dialog box willprompt the user for the arguments you specify. The argumentdescriptions you provide here are the field names for this tab box.Be sure to provide a name that accurately describes the value themodule’s user must enter.

If you specify an argument, a Dialog Specification Language(ProgramName.dsl) file is created when you generate the module.This file defines the tab box that prompts the user for the argument.You may modify this file or overwrite it with a new one.


12–16 Version 2.1

10. Select theMgmt Tools Extensions category. Each file packagecomponent has one or more defaultTIVOLI_PLUS_3_0instances in this category.

The default instances associate the file package component withthe module or with another component. The following describesthe default management tool extension instances. The defaultinstances are identified by the value in theVariable Name field.

MODULE_TYPEThis instance associates the file packagecomponent with the Plus module. This defaultinstance should not be changed.

SUBSCRIPTION_LISTThis instance associates the file packagecomponent with a subscription list. You should



File P

ackages

edit this instance’sVariable Value field with thecomponent name of the subscription list. Onlyclient and server file packages have this instance.

NESTED_FILEPACKThis instance identifies the ancillary file packagethat is to be nested in a client or server filepackage. You should edit this instance’sVariableValue field with the component name of theancillary file package. Only client and server filepackages have this instance.




Variable NameEnterSUBSCRIPTION_LIST or NESTED_FILEPACK in thisfield.

Variable ValueThis field identifies the component to which you are establishinga relationship. Enter the value displayed in theNamefield of therelated component’sComponent Data tab. For example,enteringSubscribers of <Application Name> in this fieldindicates that the file package component should be distributed tothe nodes that subscribe to the component namedSubscribers of<Application Name>.


12–18 Version 2.1


Indicator Collections

13Indicator Collections

The indicator collection receives and displays the status of themonitored resources. This collection is represented in the Plus moduleby an icon that displays a group of thermometers. Opening thecollection displays individual thermometers which each indicate thestatus of a particular monitored resource. As the status of a monitoredresource becomes more urgent, the temperature on the indicatorcollection’s thermometers rises. This allows the user to see at a glancethat a monitored resource has changed to an urgent status. The user canopen the indicator collection to see the actual status of the monitoredresources. For each resource, the indicators report the most urgentstatus received within a recent time frame. The monitor reports areorganized so that the most urgent status level appears at the top of thereport.

13

Prerequisites

13–2 Version 2.1

The following is an example of an indicator collection icon for asample application. The option on the icon’s pop-up menu is alsodisplayed.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define an indicator collection. This procedure also assumes that youhave done the following:




When you have completed these activities, continue with “Editing theIndicator Collection Component” on page 13-2.

Editing the Indicator Collection ComponentUse the following procedure to define an indicator collection. In thisprocedure, only theComponent Data option requires definition.

Editing the Indicator Collection Component



This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the application icons component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.


2. Select theIndicators for <App Name> Monitors component inthe Tivoli Module Designer workspace. This action displays theComponent Data tab.


13–4 Version 2.1




NameEnter a name for the component. Since the name you enter is thetitle for the TME 10 Distributed Monitoring indicator collectionicon, enter a name that identifies the indicator collection. Thisname can contain any printable characters including embeddedspaces.






Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isIndicator Collection .



4. Click on theIndicators for <App Name> component’s “treecontrol button” (the box containing the + symbol). This actiondisplays all of the component definition categories.


13–6 Version 2.1

5. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. Theindicators component has predefined instances of the installationdependencies. You can specify additional installationdependencies.


Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. Since the indicator collection isinstalled on a Tivoli Management Region (TMR) server, youwould specify a custom dependency for a script that returns a valueof true (0) if a node is a TMR server.










13–8 Version 2.1


Monitors

14Monitors

TME 10 Distributed Monitoring has a set of predefined monitors formonitoring resources for UNIX and Windows NT applications. Eachinstance of these monitors checks the status of a specific resource andruns at a specific frequency. The status report for a monitored resourcecan be viewed with the TME 10 Distributed Monitoring indicatorcollection. When the status of a monitored resource reaches apredefined threshold, the monitor can initiate a task or forward anevent to the TME 10 Enterprise Console. For example, you may havea monitor instance that checks the size of a logfile and runs every 15minutes. When the logfile size increases above 2,000 KBytes, TME 10Distributed Monitoring sends an event to the TME 10 EnterpriseConsole.

In the module, the monitor collection is represented by an icon.Selecting theProperties... option from the icon’s pop-up menudisplays the monitors included in the collection. The following is an

14

14–2 Version 2.1

example of a monitor collection icon for a sample application. Theoptions on the icon’s pop-up menu are also displayed.

The Plus template includes a universal monitors component which hascommon monitors that run on both Windows NT and UNIX platforms.You can use the universal monitors component to defineapplication-specific instances of the universal monitors. The TivoliModule Builder provides additional predefined monitors which can beimported as a CDF into the Plus module. For information on usingthese additional predefined monitors, see “Using AdditionalPredefined Monitors” on page 14-27.

The Plus template also includes aMonitors for <App Name>component. This component enables you to specify custom monitorsfor items not included with the predefined monitors.

Defining a monitor instance includes specifying the name of theresource to be monitored, the thresholds for the monitored resource,and the frequency with which the monitor is to run. If the monitor is tosend events to the TME 10 Enterprise Console, you need to specify anevent classification.

Prerequisites


Monitors

PrerequisitesThe following procedure assumes that you are using the Plus templateto define monitors and their instances. This procedure also assumesthat you have done the following:




When you have completed these activities, continue with “Editing theMonitors Component” on page 14-3.

Editing the Monitors ComponentUse the following procedure to define a monitor. When completingthis procedure, theComponent Data, Synchronous Monitors, andComponent Relationship options require definition.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the monitors component is noted inthese field descriptions. General field information, including theoptional fields, is provided in the online help.

Editing the Monitors Component

14–4 Version 2.1


2. Select one of the monitor components in the Tivoli ModuleDesigner workspace. This action displays theComponent Datatab for the monitor component you selected.




Monitors




NameEnter a name for the monitor component. The name you enter willbe the name of the monitor collection icon in the Plus module. Thisname can contain any printable characters including embeddedspaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isSentry Monitors.



14–6 Version 2.1


4. Click on the monitor component’s “tree control button” (the boxcontaining the + symbol). This action displays all of thecomponent definition categories.

5. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. If



Monitors

you are not defining an installation dependency, continue withstep 6 on page 14-8.


Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. Since the monitor collections andmonitor instances are created when the module is installed on aTivoli Management Region (TMR) server, you would specify acustom dependency for a script that returns a value of true (0) if anode is a TMR server.



14–8 Version 2.1




6. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify a task that can be initiated by a monitorinstance in response to a change in the status of a monitoredresource. The operational tasks that you define are available toyou on theAvailable Tasksmenu on theResponse dialog whenyou define instances of the monitors. For information on defininga monitor instance, see “Creating a Monitor Instance” onpage 14-20.

Complete this tab once for each task you wish to define. Thecomponent description file (CDF) generated for this componentdefinition will reference each of the tasks you specify.



Monitors

Generating the Plus module produces a script stub for each scriptor program specified in the task definition. You must edit thesestubs in order to complete the script that is executed when thetask is run.


Task NameEnter a name for the task. Examples of task names areRestart_Server or Restart_<DaemonName>. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.


14–10 Version 2.1

Program NameEnter the name of the program that runs the task. The name mustbe alphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces arenot allowed. Generating the Plus module produces a script stubwith this name. The script stub has a placeholder for inserting yourapplication’s script for running this task.




7. Select theSynchronous Monitorscategory displayed to the leftof the component’s tabs. This action displays theSynchronoustab. The Tivoli Module Builder provides predefined monitorswith each monitor component. These predefined monitors aredisplayed under theSynchronous Monitors category.

Each monitor defines a type of resource to be monitored.Monitoring the actual resource, however, requires creating aninstance of the appropriate monitor. For example, monitoring thesize of a file requires creating an instance of theFile sizemonitorand then defining the instance to monitor the specific file. Youneed to define at least one instance for every monitor that youwish to use.

You can use theSynchronous tab to create a new monitor or youcan select a predefined monitor. The procedure for creating a newmonitor is under “Creating a New Monitor” on page 14-14. Onceyou have a monitor that you wish to use, you need to create aninstance of the monitor. The procedure for creating a monitor



Monitors

instance is under “Creating a Monitor Instance” on page 14-20.Once you have created the necessary monitors and theirinstances, return to this procedure and continue with the nextstep.


14–12 Version 2.1

8. Select theMgmt Tools Extensions category. Each monitorcomponent has defaultTIVOLI_PLUS_3_0 instances in thiscategory.

The default instances associate the monitor component with themodule or with another component. The following describes thedefault management tool extension instances. The defaultinstances are identified by the value in theVariable Name field.

MODULE_TYPEThis instance associates the monitor componentwith the Plus module. This default instance shouldnot be changed.

INDICATOR_COLLECTIONThis instance associates the monitor component



Monitors

with an indicator collection. In the Plus module,the indicator collection displays the status of themonitors that you have defined for this monitorscomponent. You should edit this instance’sVariable Value field with the component name ofthe indicator collection.

SUBSCRIPTION_LISTThis instance associates the monitor componentwith a subscription list. After the Plus module isinstalled, the user distributes the monitors. Themonitors are distributed to the subscription listspecified here. You should edit this instance’sVariable Value field with the component name ofthe subscription list.




Variable NameEnterSUBSCRIPTION_LIST or INDICATOR_COLLECTIONinthis field.

Variable ValueThis field identifies the component to which you are establishinga relationship. Enter the value displayed in theNamefield of therelated component’sComponent Data tab. For example,enteringSubscribers of <Application Name> in this fieldindicates that the monitors should be distributed to the nodes thatsubscribe to the component namedSubscribers of<ApplicationName>.

Creating a New Monitor

14–14 Version 2.1

Creating a New MonitorThis procedure describes how to create a new monitor. After you havecreated a monitor, you need to define an instance of the monitor foreach resource to be monitored.

For conceptual information on monitors and their instances, see theinformation at the beginning of this chapter as well as step 7 onpage 14-10. For procedural information on the activity required todefine the monitors component before actually creating a new monitor,see “Editing the Monitors Component” on page 14-3.



Monitors

1. Select the monitor component and display theSynchronoustabin the Tivoli Module Designer if you have not already done so.The steps for displaying theSynchronous tab are described insteps 1, 2, 4, and 7 of the procedure “Editing the MonitorsComponent” on page 14-3.


Monitor NameEnter the name that you wish to appear in the monitor definitionlist. This name should reflect the information provided by themonitor, such as daemon status. This name needs to be uniquewithin this component, but does not need to be unique acrosscomponents. The name must be alphabetic (cannot includenumbers, spaces, underscores, or other special characters).


14–16 Version 2.1

Event ClassIn theUser Defined field, enter the event class that applies to theevents that this monitor sends to the TME 10 Enterprise Console.The TME 10 Enterprise Console requires that event classes be inthe form of a valid BAROC class name (alphanumeric charactersstarting in upper case and including an underscore). For example,an event class may be specified asSample_TraceStatus.

2. Click on theProgram tab. This tab specifies the name of theprogram that runs the monitor. Generating the Plus moduleproduces a.csl file. The.csl file contains the names of theprograms that you have specified for the monitors defined in thiscomponent. There is one.csl file for each monitor collection. Youneed to modify the generated.cslfile with the command lineinvocations for each monitor instance. Refer to the TME 10Distributed Monitoring and the Monitoring CollectionSpecification Language (MCSL) documentation for informationon modifying the.csl files. When the Plus module is installed, the.csl file is compiled in order to import the monitor definitions intoTME 10 Distributed Monitoring.



Monitors

Note: When editing a.csl file, do not change the name of themonitor collection as shown in the.csl file’s Collectionfield.


Program NameEnter the name of the program that runs the monitor. The namemust be alphabetic (cannot include numbers, spaces, underscores,or other special characters). When the module is generated, themonitor implementations are placed in the<ModuleName>/srcdirectory. You need to provide a script for each monitorimplementation.


14–18 Version 2.1

Note: If you are using a predefined monitor, theProgramName field will have a default value that specifies both amonitoring collection and the monitor program. Thedefault value has the following format:

<CollectionName>/<ProgramName>

Argument NameEnter any arguments that the program requires in theArgumentName field and click on the< button to move the argument to theArguments list box. Do this for all arguments that the programrequires. When you create an instance of this monitor, you willspecify a value for each of these arguments. Because these valuesmay vary according to the specific resource being monitored,they are specified when creating the monitor instance and not themonitor.

Run Program EveryUse these two fields to specify the frequency with which thismonitor should check the status of the monitored resource. Whenspecifying this frequency, take into consideration how often thevalue is updated by the application, how quickly an administratorneeds to know about the situation being monitored, and theoverhead associated with running the monitor program. Forexample, you may wish to specify that the monitor run everyminute in the case of a resource, such as a daemon, whose failurewill immediately cause the application to be unavailable. You maywish to specify a longer interval for those resources that requiremore time to reach a critical status.



Monitors

3. Click on theReturn Type tab. This tab has fields for specifyingthe monitor program’s return values.


Return TypeSpecify whether the monitor program should write its standardoutput as numeric data or strings (character data). Thisspecification determines the type of thresholds that can be set forthis monitor. Numeric data can have thresholds set in terms of anumeric comparison. For example, this type of threshold mayindicate that a daemon count is “equal to 1” or “greater than 1.”String data can have thresholds set in terms of a charactercomparison. For example, this type of threshold may indicate thata tracing facility is “OFF” or that the value for a resource is not“UP” or contains “ERROR.”

Creating a Monitor Instance

14–20 Version 2.1

Return Unit(Optional). Use theUser Defined field to specify the type of unitsreturned by this monitor. For example, you could specify that thereturn units be megabytes, kilobytes, or a percentage.

4. Click on theAdd button when you are finished. The new monitorthat you just created is displayed under theSynchronousMonitors category. In order to run this monitor, you need todefine an instance of this monitor for a particular resource. Forinformation on defining a monitor instance, see “Creating aMonitor Instance” on page 14-20.

Creating a Monitor InstanceThis procedure describes how to define an instance of a monitor. Inorder to have a monitor instance, you must first create the monitor oruse one of the predefined monitors. The following procedure assumesthat you have theSynchronoustab displayed.

For procedural information on creating a new monitor, see “Creating aNew Monitor” on page 14-14. For conceptual information on monitorsand their instances, see the information at the beginning of this chapteras well as step 7 on page 14-10. For procedural information on theactivity required to define the monitors component before actuallydefining a monitor instance, see the procedure starting on “Editing theMonitors Component” on page 14-3.



Monitors

1. If you have not already done so, select the monitor component towhich you are adding a monitor instance and display theSynchronoustab in the Tivoli Module Designer. The steps fordisplaying theSynchronous tab are described in steps 1, 2, 4,and 7 of the procedure “Editing the Monitors Component” onpage 14-3.

2. Expand theSynchronous Monitors category so that all definedmonitors are displayed.


14–22 Version 2.1

The following graphic shows the predefined monitors for theUniversal Monitors component.

3. Select the monitor for which you are creating an instance andclick on theInstance button. This action creates an “empty”instance of the monitor you selected.



Monitors

The following graphic shows an instance that has been createdfor the file size monitor.

4. Select the newly created instance and click on theThresholdbutton to display theArguments tab. TheArgument Name listbox on this tab displays the arguments that you defined for themonitor program in step 2 on page 14-16.


14–24 Version 2.1

For each argument, enter the appropriate value in theArgumentValue field. Click on theUpdate button when finished. Thisaction creates aThreshold item under the monitor instance.



Monitors

5. Select the threshold item for the monitor instance to display theThresholds tab. This tab has fields for specifying the additionalinstance information.

6. Specify the following fields on theThresholds tab.

SeverityUse this menu to select the severity level of the event that is sentto the TME 10 Enterprise Console when the monitored resourcereaches the specified threshold.

ConditionUse this menu to select the relational operator for the threshold.This operator determines how the monitor uses the specifiedthreshold to determine a resource’s status. For example, themonitor may assess a resource’s status by checking whether it is“greater than” or “changes from” or “crosses above” the specified


14–26 Version 2.1

threshold. The value you specify with this menu should beconsistent with the return type you specified on theReturn Typetab in step 3 on page 14-19. For example, if the return type isString, you could not specifyGreater than with this menu sinceGreater than assumes that the return type isNumeric.

Event ThresholdEnter the value for the threshold.

Send event when conditions metSelect this box if you want the monitor to send an event to the TME10 Enterprise Console when the threshold is met.

7. Click on theResponsetab. TheResponsetab has fields forspecifying that a task be run in response to a change in amonitor’s status. (For example, you could specify that a task berun to restart a failed daemon.)

Using Additional Predefined Monitors


Monitors

Complete these fields as necessary.

Available TasksThis menu displays theOperational Tasks that you defined forthis monitor component. These tasks were defined in step 6 onpage 14-8.

ArgumentAny arguments required by the task selected with theAvailableTasks menu are displayed in theArgument list box.

Argument ValueEnter the value for each argument required by the task.

8. Click on theUpdate button to set your changes.

Using Additional Predefined MonitorsThe Tivoli Module Builder provides predefined monitors in addition tothe monitors provided by the universal monitors component includedin the Plus template. You can import the additional predefinedmonitors as a CDF into your Plus module. Once imported, you can usethe Tivoli Module Designer to create application-specific instances ofthe additional predefined monitors. When using the additionalpredefined monitors, you also need to specify the monitor collectionname using theSettings tab in the Tivoli Module Builder.

The following steps describe the activities required to use theadditional predefined monitors and reference the procedures thatprovide specific instruction.

1. Import a CDF with the predefined monitors using the proceduredescribed in “Adding and Importing Components into a Module”on page 2-4. The CDFs with predefined monitors are located inthe following directory:

\module_dev\ToolKit\cdfs\monitor_collections\<CDF_Name>

2. Select the imported component (CDF) and launch the TivoliModule Designer using the procedure described in “Launchingfrom the Component Level” on page 2-11. You may also launchthe Tivoli Module Designer from the module level as describedin “Launching from the Module Level” on page 2-10.

Using Additional Predefined Monitors

14–28 Version 2.1

3. Create instances of the predefined monitors as needed using theprocedure described in “Creating a Monitor Instance” onpage 14-20.

4. Specify the collection name for the predefined monitors using theprocedure described in “Specifying the Collection Name forPredefined Monitors” on page 3-13.


TM

E 10 E

nterpriseC

onsole Configuration

15TME 10 Enterprise ConsoleConfiguration

The TME 10 Enterprise Console (TEC) event server receives eventsand matches these events against a rule base in order to identify theappropriate response for handling an event. Events may be generatedby the monitors that come with TME 10 Distributed Monitoring or byan application.

The TME 10 Enterprise Console has predefined event correlation rulesfor handling events generated by the monitors that come with TME 10Distributed Monitoring. If you create custom monitors for yourapplication, however, you will need to create the class definitions andevent correlation rules required by the TME 10 Enterprise Console tohandle these events.

When using custom monitors, you need to write event class definitionsand event correlation rules in order for the TME 10 Enterprise Consoleto recognize and properly respond to the events forwarded by thecustom monitors. These class definitions and event correlation rulesare contained in.baroc files (class definitions) and.rls files (eventcorrelation rules). (For information on creating the.baroc, and.rlsfiles, refer to the TME 10 Enterprise Console documentation.)

15

15–2 Version 2.1

When integrating your application’s custom monitors with the TME10 Enterprise Console, you will do the following:

1. Create a BAROC file with the class definition for each customevent and a rules file with an event correlation rule for eachcustom event. The BAROC file’s name must end in a.barocextension and the rules file’s name must end in a.rls extension.(A .rb extension may optionally be used for the rules file.) Formore information on creating the BAROC and rules files, refer tothe TME 10 Enterprise Console documentation.

2. Complete the procedure in this section for defining the TME 10Enterprise Console configuration component. When completingthis procedure, specify an instance of theFile List element forthe .baroc file and another instance for the.rls file. The modulecan have more than one.baroc and.rls file. Be sure to specify aninstance for each file to be included in the module.

Once you generate the module after completing the componentdefinitions, the location of the.baroc and.rls files are forwarded to thesetup script.

The following is an example of an event server configuration task fora sample application. The options on the icon’s pop-up menu are alsodisplayed.

Prerequisites


TM

E 10 E

nterpriseC


PrerequisitesThe following procedure assumes that you are using the Plus templateto define the TEC configuration component. This procedure alsoassumes that you have done the following:




When you have completed these activities, continue with “Editing theTEC Configuration Component” on page 15-3.

Editing the TEC Configuration ComponentUse the following procedure to define the TME 10 Enterprise Consoleconfiguration task. When defining the TME 10 Enterprise Consoleconfiguration component, theComponent Data, File List , andOperational Task options require definition.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the TEC configuration component isnoted in these field descriptions. General field information, includingthe optional fields, is provided in the online help.

Editing the TEC Configuration Component

15–4 Version 2.1


2. Select theTEC Configuration for <App Name> component inthe Tivoli Module Designer workspace. This action displays theComponent Data tab.




TM

E 10 E

nterpriseC





NameEnter a name for the component. Since the name you enter is thetitle for the event server setup task icon, enter a name that identifiesthe TME 10 Enterprise Console configuration function of the icon.This name can contain any printable characters includingembedded spaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isTEC Configuration .


15–6 Version 2.1



4. Click on theTEC Configuration for <App Name> component’s“tree control button” (the box containing the + symbol). Thisaction displays all of the component definition categories.

5. Select theFile List tab. TheFile List tab enables you to specifythe .baroc and.rls files for your application’s event classes andrules. Specifying these files with theFile List tab ensures thatyour application’s event classes and rules are loaded into theTME 10 Enterprise Console event server when the event serveris configured for the Plus module. When you define the TEC



TM

E 10 E

nterpriseC


configuration component using the Plus template, a predefinedfile list instance for the rules (.rls) is provided for you. You needto create another instance for the.baroc file.


File NameEnter the names of those files (.baroc or .rls files) required totranslate events or provide event correlation for your application.You can specify either a full path or a simple file name. When usinga simple file name, use theSource Locationsfields to specify thedirectories where the file is located.

Source LocationUse theSymbolic Name menu to select a symbolic name for thelocation of the file. The symbolic names that you have defined withtheLocation Definitions category appear on this menu.


15–8 Version 2.1


6. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. Ifyou are not defining an installation dependency, continue withstep 7 on page 15-9.



TM

E 10 E

nterpriseC



Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. Since the TEC configuration task isinstalled on the TME 10 Enterprise Console server, you wouldspecify a custom dependency for a script that returns a value of true(0) if a node is a TEC server.





7. (Optional). Select theOperational Taskscategory. TheOperational Tasks tab enables you to define a task for loadingyour applications event classes and rules into the TME 10Enterprise Console event server. Since loading these files is astandard process, the Tivoli Module Builder provides apredefined operational task instance and a default script forimplementing this task. The default script is namedSetup_TEC_Event_Server_for_AppName. This script hasseveral default arguments. In most cases, the default script is


15–10 Version 2.1

sufficient, which means you will not have to make any changesto theOperational Taskstab or theSetup_TEC_Event_Server_for_AppNamescript. If yourapplication needs a customized script, you can review theSetup_TEC_Event_Server_for_AppNamescript as anexample.

If you need to define a custom configuration script, complete thefollowing fields:

Task NameEnter a description of what the task does. The information that youenter is the title for this task icon in the module. An example of atask (or task icon) name isSetup_TEC_EventServer_for_Sample.The name must be alphanumeric (a–z, A–Z, 0–9, plusunderscores). Spaces are not allowed.



TM

E 10 E

nterpriseC


Program NameEnter the name of the program that implements the TME 10Enterprise Console configuration. The name must bealphanumeric (a–z, A–Z, 0–9, plus underscores). Spaces are notallowed.

Argument Name(Optional).

Enter a descriptive label for any arguments (for example, the rulebase name) that the program expects the user to provide and clickon theAdd button. Do this for all arguments required by theprogram.

When the user runs this program, a pop-up dialog box willprompt the user for the arguments you specify. The argumentlabels that you provide here are the field names for this tab box.If you are using a custom script, be sure to provide argumentlabels that accurately describe the values the module’s user mustenter.

When you specify an argument, a Dialog Specification Language(ProgramName.dsl) file is created when you generate the module.This file defines the tab box that prompts the user for the argument.You may modify this file or overwrite it with a new one.



15–12 Version 2.1


Logfile Adapter

Configuration

16Logfile Adapter Configuration

Your application’s events need to be translated into a form readable bythe TME 10 Enterprise Console. If your application records its eventsin a flat ASCII logfile (with a single event per line), then these eventscan be handled by the TME 10 Enterprise Console logfile adapter.Configuring the logfile adapter to handle these events requires creatinga .fmt file (format file). The format file defines string formats that maymatch strings that are output to your application’s flat ASCII logfile.The logfile adapter uses this format file to scan the logfile for therelevant events and translates these events into a form readable by theTME 10 Enterprise Console. These events are then forwarded to theTME 10 Enterprise Console server.

Note: If your application’s events are not recorded in a flat ASCIIlogfile, you need to build a new logfile adapter to handle theseevents.

When integrating your application’s custom monitors with the TME10 Enterprise Console, you will do the following:

1. Create a format file with the rules for translating yourapplication’s events into a form readable by the event server. Theformat file’s name must end in a.fmt extension. For moreinformation on creating the format file, refer to the TME 10Enterprise Console documentation.

2. Complete the procedure in this section for defining the logfileadapter component. When completing this procedure, specify the.fmt file that you have created in theFile List tab. If your

16

Prerequisites

16–2 Version 2.1

application’s logfile does not have a default location, then specifyan argument for the logfile’s location in theOperational Tasktab.

Once you generate the module after completing the componentdefinitions, the location of the.fmt file is available to the setup script.If you specified an argument for the logfile’s location, then the userwill be prompted to specify this location by a pop-up dialog box whenrunning the setup task.

The following is an example of a configure logfile adapter icon for asample application. The options on the icon’s pop-up menu are alsodisplayed.

PrerequisitesThe following procedure assumes that you are using the Plus templateto define the logfile adapter configuration component. This procedurealso assumes that you have done the following:



Editing the Logfile Adapter Configuration Component


Logfile Adapter

Configuration


When you have completed these activities, continue with “Editing theLogfile Adapter Configuration Component” on page 16-3.

Editing the Logfile Adapter ConfigurationComponent

Use the following procedure to define theLogfile AdapterConfiguration for <App Name> component. When defining thelogfile adapter configuration component, theComponent DataandOperational Task options require definition.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the logfile adapter configurationcomponent is noted in these field descriptions. General fieldinformation, including the optional fields, is provided in the onlinehelp.


16–4 Version 2.1


2. Select theLogfile Adapter Configuration for <App Name>component in the Tivoli Module Designer workspace. Thisaction displays theComponent Data tab.




Logfile Adapter

Configuration




NameEnter a name for the component. This name can contain anyprintable characters including embedded spaces.

VersionUse these fields to specify the version of the logfile adapterconfiguration component. You can change the version in thesefields to keep track of code changes. Specify the version in thefollowing format: a major version number, a minor versionnumber, and a revision indicator. The major and minor numbersare required. The revision indicator is optional. After MIF parsingis complete, the elements in this format appear as follows:MajorNumber.MinorNumberRevisionIndicator. For example,4.52A or 1.1.3.


Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isLogfile Adapter Configuration.



16–6 Version 2.1


4. Click on theLogfile Adapter Configuration for <App Name>component’s “tree control button” (the box containing the +symbol). This action displays all of the component definitioncategories.



Logfile Adapter

Configuration

5. (Optional). Select theFile List category. TheFile List tabenables you to specify your application’s format (.fmt) file.


File NameEnter the name of your application’s format (.fmt) file.

Source LocationUse theSymbolic Name menu to select a symbolic name for thelocation of the format file. The symbolic names that you havedefined with theLocation Definitions category appear on thismenu.



16–8 Version 2.1

6. (Optional). Select theInstallation Dependenciescategory. TheInstallation Dependenciestab enables you to specify the criteriathat must be met before a component’s files can be installed. Ifyou are not defining an installation dependency, continue withstep 7 on page 16-10.






Logfile Adapter

Configuration





16–10 Version 2.1

7. Select theOperational Taskscategory. TheOperational Taskstab enables you to define the logfile adapter configuration task.


Task NameEnter a description of what the task does. The information that youenter is the title for the configure logfile adapter task in the module.An example of a task (or task icon) name isConfigure_Logfile_Adapter.The name must be alphanumeric(a–z, A–Z, 0–9, plus underscores). Spaces are not allowed.

Program NameEnter the name of the program that runs the configure logfileadapter task. The name must be alphanumeric (a–z, A–Z, 0–9,plus underscores). Spaces are not allowed.



Logfile Adapter

Configuration

8. Select theMgmt Tools Extensions category. The logfile adapterconfiguration component has defaultTIVOLI_PLUS_3_0instances in this category.

The default instances associate the logfile adapter configurationcomponent with the module or with another component. Thefollowing describes the default management tool extensioninstances. The default instances are identified by the value in theVariable Name field.

MODULE_TYPEThis instance associates the logfile adapterconfiguration component with the Plus module.This default instance should not be changed.

SUBSCRIPTION_LISTThis instance associates the logfile adapterconfiguration component with a subscription list.You should edit this instance’sVariable Value


16–12 Version 2.1

field with the component name of the subscriptionlist.





Variable ValueThis field identifies the component to which you are establishinga relationship. Enter the value displayed in theNamefield of therelated component’sComponent Data tab. For example,enteringSubscribers of <Application Name> in this fieldindicates that the logfile adapter configuration component shouldbe distributed to the nodes that subscribe to the componentnamedSubscribers of<Application Name>.


Hidden Tasks

17Hidden Tasks

A module may include hidden tasks, which are those tasks that areautomatically initiated in response to specific conditions, but are notdirectly initiated by the module’s user. Hidden tasks do not have anicon or any other visibility in the module. Hidden tasks are generallyassociated with the automated actions or event correlation provided bythe TME 10 Enterprise Console. The correlation rules for a particularevent may specify that a task be run automatically. For example, thecorrelation rule for a failed daemon may specify that the daemonprocess be reinitiated.

17

Prerequisites

17–2 Version 2.1

PrerequisitesThe following procedure assumes that you are using the Plus templateto define hidden tasks. This procedure also assumes that you have donethe following:




When you have completed these activities, continue with “Editing theHidden Tasks Component” on page 17-2.

Editing the Hidden Tasks ComponentUse the following procedure to define a hidden task. When defining thehidden tasks component, theComponent Data andOperationalTasksoptions require definition.

This procedure only discusses the required fields in the Tivoli ModuleDesigner. Information specific to the hidden tasks component is notedin these field descriptions. General field information, including theoptional fields, is provided in the online help.

Editing the Hidden Tasks Component


Hidden Tasks


2. Select theHidden Tasks for <App Name> component in theTivoli Module Designer workspace. This action displays theComponent Data tab.



17–4 Version 2.1




NameEnter a name. This name should categorize all of the hidden tasksthat you specify with the Plus template. This name can contain anyprintable characters including embedded spaces.



Component Function

This field identifies the component’s type or function. The onlyvalid value for this field isHidden Tasks.




Hidden Tasks


4. Click on theHidden Tasks for <App Name> component’s “treecontrol button” (the box containing the + symbol). This actiondisplays all of the component definition categories.

5. (Optional). Select theInstallation Dependenciescategory. Thetab in this category enables you to specify the criteria that mustbe met before a component’s files can be installed. If you are not


17–6 Version 2.1



Dependency TypeUse this menu to select the type of criteria that must be met beforea component can be installed. For a hidden tasks component, youwould typically specify a custom dependency for a script thatreturns a value of true (0) if a node is a TME 10 Enterprise Consoleserver.




Hidden Tasks




6. Select theOperational Taskscategory. TheOperational Taskstab enables you to specify a hidden task. Complete this tab oncefor each task you wish to define. The component description file(CDF) generated for this component definition will referenceeach of the tasks you specify.


17–8 Version 2.1



Task NameEnter a description of what the hidden task does. Because a hiddentask is not visible in the Plus module, the module’s user will not seethe task name.

Program NameEnter the name of the program that runs the hidden task.Generating the Plus module produces script stubs for the hiddentasks. You must modify these script stubs with the scripts forrunning the task.



Hidden Tasks



17–10 Version 2.1

Tivoli Module Builder User’s Guide Glossary –1

Glossary

This glossary defines terms associated with the Tivoli Module Builderand related technologies.

A

AMS

See “Application Management Specification (AMS).”

application

A collection of software components used to perform specific types ofuser-oriented work on a computer.

application component

See “component.”

application description file (ADF)

Application Description File (ADF) is a generic term for the ASCIItext files that contain relevant information needed to manage anapplication. The format of an ADF is common for all applications.Because each ADF describes the unique characteristics of itsaccompanying application, the specific content of the ADF will bedifferent for each application.

The ADF file format is based on the Management Information Format(MIF) as specified by the Desktop Management Task Force (DMTF).The overall organization of an ADF maps easily to the DMTF MIF. Asingle client/server application can therefore be represented by anumber of MIF files, one per component. AMS also defines the entireapplication as a MIF component. A complete application definition istherefore represented by a single global ADF (the Global DescriptionFile), plus one additional ADF (in this case, a Component DescriptionFile) for each application component. Each description file is a fullyDMTF-compliant MIF file.

Glossary–2 Version 2.1

application management

Application management is the set of activities required to maintain anapplication throughout the application life cycle, which includesdeployment, installation, daily monitoring and maintenance, andupdates.

Application Management Specification (AMS)

A specification that presents a standard for managing applications. TheApplication Management Specification was developed incollaboration with the Tivoli Partners and Tivoli customers to addressthe problems associated with multitiered applications.

application object file (AOF)

An application object file (AOF) is an ASCII text file that contains thenames of the Global Description File (GDF) and the ComponentDescription Files (CDF) that make up the application. This file is usedby the Tivoli Module Builder to keep track of which components makeup an application. See also “Global Description File” and “ComponentDescription File.”

argument

An argument is a user-supplied value that is passed to a task ormonitor. Arguments are passed in to the programs so that one programcan behave slightly differently without being rewritten. See also“argument label.”

argument label

The argument label is a field on the pop-up dialog box that prompts theuser for a value the user must supply to a program at execution time.See also “argument.”

asynchronous monitor

In TME 10 Distributed Monitoring, a monitor that receives data in anunsolicited event and interprets the data immediately. Contrast withsynchronous monitor.

Tivoli Module Builder User’s Guide Glossary–3

B

BAROC

Basic Recorder of Objects in C (BAROC) is a hierarchy of classes thatdefine how events are generated by any event generator.

Base module

A Base module uses AMS formats to describe monitors, tasks, andother management functions which allow an application to bemanaged with the Tivoli Management Software environment. A Basemodule provides an application’s management information and scriptsin a Tivoli installable image.

business component description file (BCDF)

In the context of the Application Management Specification (AMS), abusiness component description file contains information about abusiness system component. See also “business system component.”

business description file (BDF)

A business description file (BDF) refers to any of the set of files thatdefine a business system.

business subsystem

A business subsystem organizes business system components intogroups based on a common function. See also “business subsystemdescription file (BSSDF).”

business subsystem description file (BSSDF)

In the context of the Application Management Specification (AMS), abusiness subsystem description file contains information about abusiness subsystem. See also “business subsystem.”

business system

A business systems refers to the interactions and interdependencies ofmultiple applications and resources which together implement a singlebusiness function, such as electronic mail, Web banking, or airlineticketing. See also “business system description file (BSDF).”


business system description file (BSDF)

In the context of the Application Management Specification (AMS), abusiness system description file contains information pertaining to theentire business system. See also “business system.”

business system component

A business system component describes the role an application playsin a business system. See also “business component description file(BCDF).”

business system description file

In the context of the Application Management Specification (AMS), abusiness system description file contains information pertaining to theentire business system.

business system mapping

The business system mapping identifies or “maps” the softwarecomponents that are to be included in a business system component.See also “business system mapping description file (BMDF).”

business system mapping description file (BMDF)

In the context of the Application Management Specification (AMS), abusiness system mapping description file contains the business systemmapping information. See also “business system mapping.”

C

component

An application component is a part of an application that resides on aparticular platform and fulfills a particular application function. Eachcomponent is identified by a name, textual description, and versionidentifier. A component can contain any combination of executables,data files, libraries, scripts, and so forth.

Each version and supported platform type for a particular piece ofapplication functionality should be represented as a separatecomponent. See also “component function.”


component description file (CDF)

In the context of the Application Management Specification (AMS), acomponent description file contains information about a specificcomponent in a management-ready application. Eachmanagement-ready application can contain multiple components, eachof which is represented by one component description file.

component function

The component function refers to the role that the component playswithin the application, for example, client or server. See also“component.”

component version

The component version is composed of a major version number, minorversion number, and a revision indicator. The standard representationfor a component version is that the major and minor version arenumeric, and an alphabetic or numeric designation is used for therevision indicator. The major and minor numbers are required. Therevision indicator is optional. See also “component.”

connect program

The connect program points to a program that is run on a componentin order to establish or configure a connection to a related component.This program must accept the hostname where the related componentis located as its input argument. For example, if you are building theclient component of an application, you may wish to specify that theclient can be configured to talk to a particular database server byrunning program “foo” and passing it the hostname to connect to.

D

dependency

A dependency is a condition that must be met prior to attempting todistribute or install software on a target system. The inability ofadministrators to obtain accurate information about the variousdependencies of a client/server application is one of the mostfrequently heard reasons that deployment of distributed applications is


so difficult. The Tivoli Module Designer supports a number ofpredefined dependency types and also allows the user to defineadditional types.

dependency types

The following standard dependency types are predefined by the AMSDeveloper Kit:

Required memory - How many Mbytes of RAM are required to runthis component?

Required disk space - How many Mbytes of free disk space arerequired for this component?

Required swap space - How many Mbytes of swap space are requiredfor this component?

File existence - Check that a particular file is on the target system.

File version - Check that a particular version of a particular file is onthe target system.

File excluded - Check that a particular file is not on the target system.

OS version - Check that the operating system version is at the correctlevel.

.INI file entry - Check that a particular entry exists in a specified.inifile (Windows).

.INI file entry excluded - Check that an entry does not exist in a.inifile (Windows).

Registry entry - Check that an entry exists in the registry (Windows95 and NT).

Registry entry excluded - Check that an entry does not exist in theregistry (Windows 95 and NT).

Desktop Management Task Force (DMTF)

An alliance of computer and software vendors that was convened todefine streamlined management of the diverse operating systemscommonly found in an enterprise.


destination directory

When distributing software, the destination directory is the location onthe target system where the files are placed when the softwarecomponent is distributed. See also “Source Directory.”

directory

Directories must be specified in a number of places in the TivoliModule Designer. This term refers to that portion of the file name upto but not including the actual file itself. Throughout the Tivoli ModuleDesigner, directories are seen as both a symbolic name and as a path.You can define a directory or create a new user defined directory in anydialog by selecting an unassigned symbolic name from the symbolicname list. ThePath field will then be available for you to enter theactual path. See also “symbolic name.”

DMTF

See Desktop Management Task Force.

E

event classification

An event classification is a type or class of event that is triggered inresponse to a change in the status of a monitored resource. An eventclassification may be interpreted differently depending on themonitoring system being used.

F

file list

The file list is simply a list of the files that make up a softwarecomponent. It includes the file name, a source directory, and a targetdirectory. This list should include all files that are part of thecomponent.

file name

File names can be either full or relative path names to a file. A full pathname will be one that begins at the root file system (UNIX) or at the


drive specified (Windows). In general, it is more desirable to userelative path names for files in the Tivoli Module Designer and toallow the administrator to adjust the entire directory structure at runtime. Full path names should be avoided unless it is necessary for thatexact path to be used in order for the application to function.

G

global description file (GDF)

The global description file (GDF) is a Management InformationFormat (MIF) file that contains the information that identifies theapplication at the highest level. It is used primarily for reference asmost of the key management information exists at the componentlevel.

I

installation program

Installation programs are used to make a software component that hasbeen distributed to a target system operational. There are severalpoints in the software distribution/installation process where it may benecessary to run a program or script in order to successfully install asoftware component.

Before Install - These programs are executed prior to beginningdistribution of a software component after dependencies have beenchecked. A failure in the before install stops the distribution.

After Install - These programs are executed after successfuldistribution of a software component.

On Commit - In some cases, it may be desirable to have a totallyseparate offline process where installation is done separately from thedistribution. It may also be desirable to perform some sort ofverification after installation and before sending a “successfulinstallation notice” that the installation is complete. In either of thesecases, a separate commit operation allows a program to be executed.


On Error - These programs are executed if there is a non-zero returncode from any of the other installation programs. This can be used toautomatically remove an aborted installation and restore a backup.

Before Remove - These programs are executed prior to removing asoftware component from a host where it had previously beeninstalled. The removal process itself is assumed to remove all files thatare part of the software component from the target system.

After Remove - These programs are executed after removing asoftware component from a host where it had previously beeninstalled.

instrumentation

In application or system software, either (a) monitoring functions thatprovide performance and other information to a management systemor (b) the use of monitoring functions to provide performance andother information to a management system.

L

logical entry point

An application’s logical entry point is a particular utility or screen thatthe user may wish to be displayed when launching the application.

M

management data

Management data describes the specific management requirements ofapplications and business systems.

Management Information Format (MIF)

The Desktop Management Interface (DMI) specification that definesthe syntax for describing management information about the hardwareand software components that can be installed on a computer system.

maximum version

The maximum version refers to the highest version number of a relatedcomponent that will function properly with the component being


described. The maximum version number should be checked by themanagement system prior to trying to establish a connection betweenthe two related components.

MIF

See Management Information Format.

minimum version

The minimum version refers to the lowest version number of a relatedcomponent that will function properly with the component beingdescribed. The minimum version number should be checked by themanagement system prior to trying to establish a connection betweenthe two related components.

monitor

Software that monitors specific applications or the systems on whichthe applications rely. Monitors typically monitor information such asavailable disk space or application errors and compare the informationto defined thresholds. When thresholds are exceeded, either system ornetwork administrators can be notified, or an automated response canbe performed.

Monitoring Collection Specification Language (MCSL)

A proprietary programming language that belongs to Tivoli Systems,Inc. and is used to define monitoring collections for TME 10Distributed Monitoring.

P

path

The route that an operating system follows to locate a file; the storagelocation of a file. A fully qualified path lists the drive identifier, thedirectory name, the subdirectory name (if any), and the file name withits associated extension.


platform

Platform refers to the operating system that underlies a particularsoftware component. The platform can be chosen from a predefinedlist that is supported by the Tivoli Module Designer.

Plus module

A Plus module is one of the requirements for certification with theTivoli Partner Association. Plus modules are built from a Plustemplate provided with the Tivoli Module Builder and have particularfeatures, such as application launch, a minimum number of tasks andmonitors, and integration with the TME 10 Enterprise Console. ThePlus module’s management information and scripts are built into aTivoli installable image. All Plus module functions are contained in aspecial icon on the Tivoli desktop. See also “Tivoli GEM module.”

polling interval

The polling interval is the period of time that elapses betweeniterations of running a synchronous monitor. For example, the pollinginterval for a monitored resource may be every five minutes.

Q

query program

The query program points to a program that runs on a component inorder to report back on a connection to a related component. Thisprogram must return the hostname where the related component islocated as its standard output. For example, if you are building theclient component for an application, you may wish to specify that theclient can return the database server to which it is connected byrunning program “foo”.

R

relationship

A relationship expresses a connection between two components of anapplication. Most relationships can be regarded as client to serverrelationships. Typically, relationships are either statically configured


where some configuration entry needs to be made (most often on theclient side) or dynamic where the client can be queried to return thename of the server.

return type

The return type of a synchronous monitor refers to the returned valuethat the program sends back as standard output and is one of thefollowing values:

Integer - The monitor program returns an integer value as standardoutput. This integer can be checked by the administrator using anumeric comparison.

String - The monitor program returns a character string as standardoutput. This value can be checked by the administrator using stringcomparison.

Event - When the monitor program detects a condition, it sends anevent of a particular class instead of returning a value. A return type ofevent does not have a variable threshold that the administrator canconfigure.

The description and value description should correspond to the returntype so that the administrator understands the units being measured bythe monitoring program. For example, a description of “disk spaceused,” a value description of “kilobytes,” and a return type of “integer”would make sense for a disk space monitoring program. See also“synchronous monitor.”

S

script stub

A script stub is generated by the Tivoli Module Builder for allprograms referenced in a component description file (CDF). Scriptstubs contain header information and code required by the Tivolimanagement tools. Script stubs can be edited with application-specificcode.

software component

See “component.”


source directory

The source directory is used in distributing and installing softwarecomponents. Typically, software components are distributed fromsome sort of a central warehouse or software depot. The files may bestored on that central system in a completely different directorystructure than where they need to be installed in order to functionproperly. The source directory points to the directory on that centralsystem where a particular file can be located.

It is recommended that symbolic names be used for source and targetdirectories so that an administrator can configure these more readily atrun time rather than having to change absolute path names. See also“destination directory” and “symbolic name.”

symbolic name

The symbolic name for a directory is a logical location for a set ofrelated files. By using symbolic names for directories, it is possible forthe application component to be more readily reconfigured by theadministrator. The Tivoli Module Designer provides a list ofpredefined symbolic names. Additional symbolic names can bedefined by the user.

synchronous monitor

In TME 10 Distributed Monitoring, a monitor that monitors resourceson a periodic basis (most monitors are synchronous). Contrast withasynchronous monitor.

T

target platform

The target platform for a software component describes the hardwareand operating system on which the component will run.

task

In the TME 10 environment, the definition of an action that must beroutinely performed on various managed nodes throughout thenetwork. A task defines the executables to be run when the task is


executed, the authorization role required to execute the task, and theuser or group name under which the task will execute.

Task Library Language (TLL)

In the TME 10 environment, a programming language used to define atask library. The TLL definition can be used to copy a task library fromone installation to another. The TLL also allows the arguments foreach task to be described such that graphical user interface (GUI) toolscan interpret them and present an interface for operators who want tocreate the tasks.

Tivoli GEM module

A Tivoli GEM module is one of the requirements for certification withthe Tivoli Partner Association. Tivoli GEM modules are built fromtemplates provided with the Tivoli Module Builder and have featuresfor managing an application with the Tivoli Global EnterpriseManager (Tivoli GEM). Tivoli GEM modules provide tasks andmonitors for managing an application in the context of a businesssystem. The module’s management information and scripts are builtinto a Tivoli installable image. See also “Plus module.”

Tivoli Module Builder

The Tivoli Module Builder enables you to define the managementrequirements of applications and business systems and build thisinformation, along with the scripts and programs that implementmanagement functions, into a Tivoli installable image.

Tivoli Module Designer

The Tivoli Module Designer is a utility provided with the TivoliModule Builder. The Tivoli Module Designer enables you to define themanagement requirements of applications and business systems in anAMS format. See also “Application Management Specification(AMS).”

Tivoli Global Enterprise Manager

A Tivoli product that allows system administrators to graphicallymonitor, control, and configure applications residing in distributed andhost (S/390) environments and to use the concept of business systems


management to organize related components, thereby providing abusiness perspective for management decisions. Tivoli GEM givesinformation technology staff a logical view of the computingenvironment; this view shows, at a glance, the status of the multipleapplications that comprise the enterprise's business system, includingapplication components, the relationships among and betweencomponents, and the flow of data between the applications. Byproviding this view from a business perspective, Tivoli GEM enablessystem administrators to quickly make determinations about thebusiness impact of any component failure. Addressing technologyproblems from the business perspective greatly improves theeffectiveness of system administrators and provides a higher level ofservice to users.


Tivoli Module Builder User’s Guide Index–1

Index

AAdministrative Tasks

template 5-6AMS

seeApplication ManagementSpecification

Ancillary File Package Template 5-6Application Icons

defining 6-1template 5-5

Application Launch Icondefining 7-1template 5-5

Application Management Specificationdownloading viiiexplained 1-3

applications 1-2defining for Tivoli GEM 1-3

BBAROC files 15-2BCDF files 1-4BMDF files 1-4BSDF files 1-5BSSDF files 1-5business subsystems 1-5business system components 1-4business system mapping 1-4business systems

defining for Tivoli GEM 1-4description files 1-5files for 1-4managing 1-2

button, tree control 1-11

CCDF files 1-3CDF variables 1-11certification 1-5Client File Package Template 5-6component

categoriesDirectory Definition 5-9File List 5-10Installation Dependency 5-10Installation Programs 5-10Location Definitions 5-9Management Extensions 5-11Operational Task Definition 5-10Synchronous Monitors 5-10tree format 5-8

templatesAdministrative Tasks 5-6Application Icons 5-5Application Launch Icon 5-5File Package 5-6Hidden Tasks 5-7Indicator Collection 5-6list of generic names 5-4Logfile Adapter Configuration 5-7Monitors 5-7Subscription List 5-5TEC Configuration 5-7

component description files 1-3components

definingAdministrative Tasks 11-1Application Icons 6-1Application Launch Icon 7-1File Packages 12-1

Index–2 Version 2.1

Hidden Tasks 17-1Indicator Collection 13-1Install Options 8-1Logfile Adapter Configuration

16-3monitors 14-1Plus configuration 9-1Subscription Lists 10-1Tivoli Enterprise Console

Configuration 15-3configuring

File Packages 12-1Tivoli Enterprise Console 15-3

conventions, typographical xicustom monitors, integrating with the Tivoli

Enterprise Console 15-1

Ddefining

componentsAdministrative Tasks 11-1Application Icons 6-1Application Launch Icon 7-1File Packages 12-1Hidden Tasks 17-1Indicator Collection 13-1Install Options 8-1Logfile Adapter Configuration

16-3monitors 14-1Plus configuration 9-1Subscription Lists 10-1Tivoli Enterprise Console

Configuration 15-3

DMTFsee Desktop Management Task Force

downloadingApplication Management Specification

viii

FFile Packages

configuring 12-1defining 12-1template 5-6

filesBCDF 1-4BMDF 1-4BSDF 1-5BSSDF 1-5CDF 1-3, 1-4

GGDF variables 1-11graphics

Tivoli Module Builder 1-10

HHidden Tasks


Iicons

for launching the application 6-2, 7-1for Plus configuration 9-2for setting install options 8-2for setting up TEC 15-2

Tivoli Module Builder User’s Guide Index–3

for subscription lists 10-2Plus Module 6-1TivoliPlus 5-11

Indicator Collectiondefining 13-1template 5-6

Install optionsdefining 8-1

instrumentationdefined 1-7

LLogfile Adapter Configuration


Mmanagement data 1-2Management Information Format 1-3managing 1-2

applications 1-2business systems 1-2

MIFseeManagement Information Format

modulesbase 1-5certification 1-5workflow 1-7

Monitorstemplate 5-7

monitorsdefining 14-1

Oobject hierarchy 1-10

PPlus configuration

defining 9-1Plus configuration icon

defining 9-1Plus Module icon 6-1prerequisites

documentation viiifor Tivoli Module Builder users viii

proceduresbuilding a logfile adapter 16-1creating class definitions 15-2creating event correlation rules 15-2defining a subscription list 10-3defining an indicator collection 13-2defining application icons 6-3defining the application launch icon 7-2editing administrative tasks component

11-3editing file package component 12-3editing hidden tasks component 17-2editing install options component 8-2editing monitor component 14-3editing Plus configuration component

9-2

SServer File Package Template 5-6set install options icon


settings 1-11software components, defined 1-3subscription list icon


Subscription Listsdefining 10-1template 5-5

Index–4 Version 2.1

TTask Administration

defining 11-1TEC Configuration


TEC setup icondefining 15-1template 5-7

Tivoli Enterprise Consolecustom monitors

setting up class definitions 15-1setting up event rules 15-1

Tivoli Enterprise Console Configurationdefining 15-1

Tivoli Module Builderlaunching 1-9understanding 1-7– 1-9workflow 1-7

Tivoli Module Builder window 1-10Tivoli Module Designer 1-8Tivoli Partner Association 1-5TivoliPlus icon 5-11TivoliPlus window 5-12TME 10 Desktop window 5-12tree control button 1-11typographical conventions xi

UUNIX monitors

defining 14-1UNIX-NT monitors

defining 14-1

Vvariables 1-11

Wweb sites

Application Management Specificationviii

customer support xiiwindows

Tivoli Module Builder 1-10TivoliPlus 5-12TME 10 Desktop 5-12

workflow, for modules 1-7workspace 1-8

object hierarchy 1-10