3dn00801iaaadezza v1 Alcatel-Lucent 1300 XMC

HP TeMIP Software
TeMIP Tcl Scripting

TTS
User’s Guide
Edition: 5.3
for PA-RISC Unix Operating System
May 2011
© Copyright 2011 Hewlett-Packard Development Company, L.P.

Legal Notices
Warranty
The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such products and
services. Nothing herein should be construed as constituting an additional warranty. HP shall not be
liable for technical or editorial errors or omissions contained herein
A copy of the specific warranty terms applicable to your Hewlett-Packard product can be obtained
from your local Sales and Service Office.
License Requirement and U.S. Government Legend

Confidential computer software. Valid license from HP required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
Restricted Rights Legend

Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS
252.227-7013.
Hewlett-Packard Company
United States of America
Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR
52.227-19(c)(1,2).
Copyright Notices
©Copyright 2002-2011 Hewlett-Packard Development Company, L.P.
Tcl /Tk and supporting software are copyrighted by the Regents of the University of California, Sun
Microsystems, Inc., Scriptics Corporation, ActiveState Corporation and other parties.
GetLine is Copyright© 1991, 1992, 1993 by Chris Thewalt
TclXML and TclDOM is Copyright© 1998-2004 Zveno Pty Ltd
Tcl SOAP is Copyrigh © 2001 Pat Thoyts
Tcl Thread Extension is Copyright© 2005 Zoran Vasiljevic
Tix is Copyright© Ioi Lam
TclX is Copyright© Karl Lehenbauer and Mark Diekhans
Oratcl is Copyright© 2000-2004 Todd M. Helfter
CGI Tcl is made by Don Libes (libes@nist.gov)
Scotty/Tnm Copyright©1993-1996 Juergen Schoenwaelder, Technical University of Braunschweig
TLS Copyright© Matt Newman @ Novadigm
Sqlite3 Copyright© Hwaci
No part of this document may be copied, reproduced, or translated to another language without the
prior written consent of Hewlett-Packard Company. The information contained in this material is
subject to change without notice.
2
Trademark Notices
Adobe®, Acrobat® and PostScript® are trademarks of Adobe Systems Incorporated.
HP-UX Release 10.20 and later and HP-UX Release 11.00 and later (in both 32 and 64-bit
configurations) on all HP 9000 computers are Open Group UNIX 95 branded products.
Java™ is a U.S. trademark of Sun Microsystems, Inc.
Microsoft® , Windows® and Windows NT® are U.S. registered trademarks of Microsoft Corporation.
Oracle® is a registered U.S. trademark of Oracle Corporation, Redwood City, California.
UNIX® is a registered trademark of The Open Group.
X/Open® is a registered trademark, and the X device is a trademark of X/Open Company Ltd. in the
UK and other countries.
All other product names are the property of their respective trademark or service mark holders and are
hereby acknowledged.
Open Source proposals

This software is registered as HP open-source proposal number 1384 and 2923, reviewed by the OSRB.
3
Document Information
Preface
The target audience for this User’s Guide comprises system architects who need to evaluate
TeMIP Tcl Scripting for use in a project and system integrators who will use it to build
functionality. It has two parts, a primer and a reference part. For evaluation it will suffice to read
part I or some of it. For a system integrator it is recommended to read the primer to gain an
initial understanding and then use part II for reference.
Part I is structured as follows:
• Chapter 1 contains a brief introduction to the benefits of TeMIP Tcl Scripting.
• Chapter 2 gives a general description to introduce the capabilities of TTS.
• Chapter 3 briefly describes the Tcl commands that are available for a Tcl script to
interwork with the TeMIP framework and TeMIP management modules.
The descriptions given in chapters Chapter 2 and Chapter 3 are at a high level and do not cover
all details. For full details refer to part II.
• Chapter 4 contains brief descriptions of a number of suggested uses of TTS, to convey an
understanding of the range of possible applications.
• Chapter 5 contains a simplified example, with a complete set of sources, of how an access
module can be implemented, and how its information model can be accessed.
Part II is structured as follows:
• Chapter 6 gives a complete description of the TTS commands with miscellaneous related
information needed to use the commands.
• Chapter 7 gives reference information which is specific to TTS PM.
• Chapter 8 gives reference information which is specific to TTS MM.
• Chapter 9 gives reference information which is specific to corrective filters.
• Chapter 10 describes a way to do remote calls of TTS commands in a client-server setup.
• Chapter 11 gives additional reference information which does not belong in any of the
preceding chapters of Part II.
The following information is given in appendices.
• Appendix A describes the high level TTS command temip.
• Appendix B gives an introduction to Tcl as used by TTS.
• Appendix C is a Tcl syntax resume.
Font Conventions
A monospace font is used throughout this guide for code examples, command dialogues and
elements of Tcl syntax which appear within regular body text. Metasymbols representing
variables or formal arguments in Tcl code are rendered in monospace italics. Italics are also used
to indicate variable elements of TeMIP full names in other contexts, and otherwise to highlight
and delimit specific terms that are being introduced or emphasized as well as names of
referenced documents. Bold font is used only for highlighting effect to make it easier to locate
headings for tables and sections of body text.
TeMIP Integration Tools - TTS Page 5 of 136

Contents List
DOCUMENT INFORMATION ...................................................................................4
PART I TTS PRIMER..............................................................................................11
CHAPTER 1 INTRODUCTION ...............................................................................12
CHAPTER 2 CAPABILITIES OVERVIEW ..............................................................14
2.1 Common Capabilities ........................................................................................................................... 14

2.1.1 Help and Support ............................................................................................................................ 14
2.1.2 High Level Commands ................................................................................................................... 15
2.1.3 Low Level Commands.................................................................................................................... 15
2.1.4 Interpreter Contexts ........................................................................................................................ 18
2.2 Presentation Module Capabilities ....................................................................................................... 18
2.3 Management Module Capabilities ...................................................................................................... 20

2.3.1 Management Model and Configuration File ................................................................................... 20
2.3.2 Directive Scripts ............................................................................................................................. 21
2.3.3 Interpreters, Contexts and Tcl Event Processing ............................................................................ 21
2.3.4 Synchronous and Asynchronous Processing .................................................................................. 22
2.3.5 Installation and Enrollment ............................................................................................................ 23
2.4 Corrective Filter Capabilities .............................................................................................................. 23
CHAPTER 3 TTS COMMANDS..............................................................................25
3.1 High Level Commands ......................................................................................................................... 25
3.2 Low Level Commands and TTS objects ............................................................................................. 26

3.2.1 Trace Command ............................................................................................................................. 26
3.2.2 Dictionary Command ..................................................................................................................... 27
3.2.3 Data Command ............................................................................................................................... 27
3.2.4 Call Command ................................................................................................................................ 28
3.2.5 Event Command ............................................................................................................................. 30
3.2.6 ACLOC Command ......................................................................................................................... 30
3.2.7 MIR Command ............................................................................................................................... 31
3.3 High level commands v. low level command example ....................................................................... 32
CHAPTER 4 SUGGESTED USES OF TTS ............................................................33
4.1 System Configuration Scripts .............................................................................................................. 33
4.2 Information Extract and Presentation................................................................................................ 33
4.3 Simple GUI ............................................................................................................................................ 34
4.4 Web Server ............................................................................................................................................ 34
4.5 Automatic Alarm Acknowledge .......................................................................................................... 34
4.6 Northbound Integration ....................................................................................................................... 34
4.7 Alarm Mapping .................................................................................................................................... 35
Page 6 of 136 TeMIP Integration Tools - TTS

4.8 Simple AM ............................................................................................................................................ 35
4.9 Importing Data to TeMIP Entities ...................................................................................................... 35
4.10 Combined Inventory and Element Information Retrieval................................................................ 35
4.11 Director-to-Director Integration ......................................................................................................... 36
4.12 Corrective Filter ................................................................................................................................... 36
CHAPTER 5 EXAMPLE AM .................................................................................. 37
5.1 Management Module person_am ........................................................................................................ 37
5.2 Installing the example AM ................................................................................................................... 40
5.3 Viewing Person Dictionary and Data Using a TTS PM .................................................................... 41
5.4 Raising TeMIP alarms from the example AM ................................................................................... 43
PART II TTS REFERENCE MATERIAL ................................................................ 44
CHAPTER 6 TTS COMMANDS REFERENCE INFORMATION ............................ 45
6.1 TTS Module Application and Process Entities .................................................................................. 45
6.2 TTS Objects .......................................................................................................................................... 45

6.2.1 Names and scope ............................................................................................................................ 45
6.2.2 Deletion .......................................................................................................................................... 46
6.2.3 Renaming ....................................................................................................................................... 46
6.3 Data Types and Formats ...................................................................................................................... 49
6.4 Data Value Specification and Representation .................................................................................... 54

6.4.1 Data Value Arguments ................................................................................................................... 54
6.4.2 Data Value Results (returnDataSpec) .................................................................................... 55
6.5 High Level Commands ......................................................................................................................... 55
6.6 Trace Command ................................................................................................................................... 59
6.7 Dictionary Information and OIDs....................................................................................................... 61
6.8 Dictionary Command and Object ....................................................................................................... 62
6.9 Data Command and Object ................................................................................................................. 66

6.9.1 Data object...................................................................................................................................... 66
6.9.2 Data object as Tcl variable ............................................................................................................. 67
6.9.3 Data object Commands................................................................................................................... 67
6.9.4 Filtering OSI events ........................................................................................................................ 72
6.10 Call Command and Object .................................................................................................................. 73
6.11 Event Command and Object ............................................................................................................... 81
6.12 Acloc Command and Object................................................................................................................ 84
6.13 MIR Command and Object ................................................................................................................. 86

CHAPTER 7 PRESENTATION MODULES AND SHELLS ....................................91
7.1 Command Line and Script File ........................................................................................................... 91
7.2 GUI Mode .............................................................................................................................................. 92
7.3 TTS PM Initialisation........................................................................................................................... 93
7.4 Line Editing ........................................................................................................................................... 93
CHAPTER 8 MANAGEMENT MODULES ..............................................................96
8.1 Module Naming .................................................................................................................................... 96
8.2 Management Model and Configuration File ...................................................................................... 96
8.3 Self Management Model ...................................................................................................................... 98
8.4 Interpreters and Scripts ....................................................................................................................... 98

8.4.1 Directive scripts .............................................................................................................................. 99
8.5 Module Command .............................................................................................................................. 101
8.6 Context Command.............................................................................................................................. 103
8.7 Module Installation ............................................................................................................................ 105
CHAPTER 9 CORRECTIVE FILTERS .................................................................107
9.1 Corrective Filter Setup Procedure .................................................................................................... 108
9.2 Event Filter Command ....................................................................................................................... 109
9.3 Discarded events handling ................................................................................................................. 112
9.4 Adding user defined fields to the TeMIP Alarm Object ................................................................. 112
CHAPTER 10 REMOTE TTS ACCESS ................................................................113
10.1 Server................................................................................................................................................... 113
10.2 Client connect ..................................................................................................................................... 113
10.3 Client eval command .......................................................................................................................... 114
10.4 Client send command ......................................................................................................................... 114
10.5 Callbacks ............................................................................................................................................. 114
10.6 Remote file sourcing ........................................................................................................................... 115
10.7 Simple example ................................................................................................................................... 115
10.8 Advanced connections ........................................................................................................................ 116
10.9 Advanced example .............................................................................................................................. 116
10.10 Using secure socket layer connections .......................................................................................... 118

CHAPTER 11 MISCELLANEOUS ....................................................................... 119
11.1 Files ...................................................................................................................................................... 119
11.2 Using Tcl Packages ............................................................................................................................. 119
11.3 Global Tcl Variables .......................................................................................................................... 121
11.4 Environment variables and TeMIP configuration .......................................................................... 121
11.5 Debugging ........................................................................................................................................... 123
11.6 Error handling .................................................................................................................................... 124
APPENDIX A THE “TEMIP” HIGH LEVEL COMMAND ..................................... 126
APPENDIX B WHAT IS TTS TCL ........................................................................ 130
APPENDIX C THE TCL LANGUAGE SYNTAX................................................... 134
Figures
Figure 1, TeMIP Event Processing ..................................................................................................................... 17
Figure 2, Tcl Interpreters in a TTS MM ............................................................................................................. 21
Tables
Table 1, Data Values by Type ............................................................................................................................ 49
Table 2, Data value constants ............................................................................................................................. 53
Table 3, Attribute Reasons ................................................................................................................................. 54
Table 4, OIDs by Dictionary Node Type ........................................................................................................... 62
Table 5, Dictionary Definitions .......................................................................................................................... 64
Table 6, Data Object Convert to Options ........................................................................................................... 69
Table 7, Data Object Convert from Options....................................................................................................... 70
Table 8, Data Object Show Options ................................................................................................................... 70
Table 9, Data Object Set Options ....................................................................................................................... 71
Table 10, Call Command Status ......................................................................................................................... 78
Table 11, Call response options.......................................................................................................................... 79
Table 12, Call “more” options ............................................................................................................................ 80
Table 13, Standard Tcl variables reflecting command line and interactivity ..................................................... 91
Table 14, Interactive Line Edit Keys .................................................................................................................. 94
Table 15, TTS global Tcl variables .................................................................................................................. 121
References
OpenView TeMIP, System Reference Manual, V5 and V6
OpenView Visual TeMIP, Development Guide, V5 and V6
OpenView TeMIP, Customization Guide, V5 and V6
OpenView TeMIP, Event Filtering and Correlation User’s Guide, V5 and V6
OpenView TeMIP, Security Operator’s Guide, V5 and V6
A large number of Internet sites provide useful information on the standard Tcl/Tk software used
in TTS (Tcl/Tk 8.5). The official home of Tcl/Tk is http://www.tcl.tk

Abbreviations
AM TeMIP Access Module
FCL TeMIP Framework Command Line
FM TeMIP Function Module
GUI Graphical User Interface
MIR TeMIP Management Instance Repository
MM TeMIP Management Module (AM or FM)
MSL TeMIP Management Specification Language
PM TeMIP Presentation Module
Tcl Tool Command Language
TeMIP Telecommunications Management Information Platform
Tk Toolkit, Tcl commands for GUI
TTS TeMIP Tcl Scripting.

Part I
TTS Primer

Chapter 1
Introduction
The TeMIP Tcl Scripting software is a tool kit dedicated to implementing small amounts of
functionality into a TeMIP solution for integration purposes.
TeMIP is object-oriented, modular and flexible, with support for many types of interfaces. In
general the granularity of TeMIP functionality is the management module, be it presentation
module (PM), functional module (FM) or access module (AM). This allows the system
integrator to put together a solution which precisely meets the customer’s requirement by
combining just the necessary management modules.
However, sometimes a situation occurs where a small amount of functionality is needed in
addition to what an existing management module already does, even when the possibilities for
customization of the management module have been exhausted. It is then often found that
building a dedicated management module or modifying the existing one is not feasible or that
the cost is forbidding, due to the technical and logistical overhead involved.
System integrators typically use scripting languages to implement small amounts of functionality
that do not exist in the applications they integrate.
TeMIP has a native command line language, FCL, which permits any command that can be
performed by a TeMIP management module to be expressed, but FCL is lacking in features to
post process responses from TeMIP and to express control flow. It is mainly suitable for
executing single commands interactively or strictly sequential scripts.
To overcome these limitations the TeMIP Tcl Scripting (TTS) tool kit has been implemented.
This manual describes TTS and the tool kit in details.
TTS incorporates interpreters for the dynamic language Tcl (Tool Command Language) into
three modules: TTS PM (command line, GUI and applications), TTS MM (Access Modules and
Function Modules) and TTS CF (Corrective Filters). All the modules are integrated with the
TeMIP framework and have very generic properties, thus enabling a number of cases of “small
amount of missing functionality” to be solved at the cost of writing a script that does exactly the
required job, but does not include an “integration tax”.
It is easy to start using TTS. It is not necessary to set up a complex environment to build
software before it can be deployed (see Appendix B).
The following are some tasks which can be done easily and therefore quickly with TTS:
• Building and maintaining configuration scripts for a TeMIP solution.
• Extracting, filtering, arranging and formatting information that is held within a TeMIP
management model. Data from a TeMIP model can be combined with data from other
sources, say an Oracle database. Information can be presented graphically, say in a
dedicated pop up window.
• Building a TeMIP GUI application to be launched on a TeMIP director or Windows®
platform.
• Adding scripted corrective filters to TeMIP.
• Building some functions and exposing them as directive calls against a TeMIP
management model.
• Building an access module which interacts by commands and responses with a network
element without C++ programming, GAT customization, etc.

• Creating interfaces to other applications (liaisons).
• Integration testing of TeMIP management modules.
• Prototyping a part of a larger application.
• Debugging of new or existing TeMIP applications
By virtue of being scripts, solutions built with TTS are easy to debug and maintain. The logistics
of maintenance and updates are very simple. The TTS scripts are portable between all versions
of TeMIP and between all host types running TeMIP.

Chapter 2
Capabilities Overview
This chapter provides an overview description of the capabilities of TeMIP Tcl Scripting (TTS).
TTS makes Tcl scripting available in the TeMIP environment in three forms:
• TTS PM, launchable Tcl/Tk applications with ability to make TeMIP directive calls and
forward events.
• TTS MM, management modules exposing callable directives against a TeMIP
management model. TTS MM can appear either as an AM or an FM.
• TTS CF, a corrective filter library, which can execute TTS scripts in the context of an
existing management module to modify events forwarded by the module.
The basic component is the same in all the cases: a collection of new Tcl commands which make
it possible to work with TeMIP data and make TeMIP directive calls. These commands are
implemented as an extension to Tcl and integrated into the binary executable files of the
modules together with a number of Tcl language interpreters 1.
Section 2.1 describes the capabilities that are common for TTS PM, TTS MM and TTS CF, i.e.
the context that is provided for Tcl scripting, in particular the TTS Tcl commands.
Section 2.2 describes the capabilities of TTS PM over and above the common capabilities,
section 2.3 does likewise for TTS MM, and section 2.4 for TTS CF.
All TTS modules will run on the same (UNIX) operating system platforms as the TeMIP
Framework. Tcl/Tk itself will run on almost any operation system and using the TTS remote
features, TTS scripts can be executed remotely from all Tcl/Tk enabled systems.
2.1 Common Capabilities

TTS PM, TTS MM and TTS CF all include standard version 8.5 Tcl interpreters extended with
a set of commands, the TTS commands, which make it possible to access almost all TeMIP
resources and functions.
TTS commands are available at two levels, high and low. Commands at the two levels can be
freely mixed. This section briefly introduces the capabilities at each level. A description which
covers every command, but still only briefly, is given in Chapter 3 (a couple of commands
which are only available in TTS MM are introduced in section 2.3); for full information on every
command and every object refer to part II of this manual.
TTS enforces TeMIP security by ensuring that all directive calls and all access to entities made
by TTS PM or TTS MM are permitted according to the applicable access control view. This is
further discussed for TTS PM and TTS MM, respectively, in section 2.2 and section 2.3.
2.1.1 Help and Support
A short description of the TTS commands is available on-line in the TTS PM:
$ tts_pm
TTS> tts::help
Here $ is the UNIX command line prompt and TTS> is the command line prompt of the TTS
PM command line application (tts_pm).
1
The Tcl interpreter, executing the Tcl commands, is actually not an interpreter, but an on-the-fly byte code
compiler and execution engine.

To get the help text displayed, enter tts::help and press “Enter”.
To get help for standard Tcl commands, a Tcl tutorial can be found at
http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html and Tcl manual pages are available at
http://www.tcl.tk/man/tcl8.5/TclCmd/contents.htm
The complete Tcl language syntax can be found in Appendix C.
2.1.2 High Level Commands
At the high level TeMIP directives can be called by single commands. These commands are all
implemented as Tcl procedures that make use of the TTS low level commands.
One command, called simply temip, has a power and flexibility similar to the TeMIP command
line utility “manage” (mcc_fcl_pm).
This command is intended to be used interactively for testing purposes!
The other high level commands are intended to be used in scripts to implement solution
functionality where performance is not a major issue and finer control is not needed. They return
output in the form of lists of entities, arguments and attribute values. The lists may require some
subsequent extraction and processing before the information is easily legible. The following
example gives the flavor.
The command:
temip::getattr {{oper demo-oc} {alarm 10637}} "alarm type" state
may return:
{{{OPERATION_CONTEXT rose_ns:.demo-oc} {alarm_object 10637}} State
Outstanding} {{{OPERATION_CONTEXT rose_ns:.demo-oc} {alarm_object 10637}}
{Alarm Type} CommunicationsAlarm}
Note
The words oper and alarm which appear in the command line are display names (of a
global and a child entity class, respectively), which are looked up in the TeMIP dictionary.
Actually they are abbreviations of OPERATION_CONTEXT and alarm_object.
Both command arguments and results are in the form of Tcl lists. Tcl include many efficient
commands to handle lists, so extracting and using relevant information returned by TTS
commands is easy and fast.
2.1.3 Low Level Commands
The low level commands are used when there is need for close control of details or if
performance is of the essence.
Six of the low level commands can be used to create and manipulate objects, which are
themselves again dedicated commands in addition to being Tcl variables. The six types of
objects are: dictionary objects, data objects, call objects, event objects, MIR objects and ACLOC
objects. A command that creates a TTS object returns the reference name of the object.
In the manner which is common with Tcl each of the main TTS commands is in fact a command
collection, with the first argument (“subcommand”) defining the actual function to be
performed, for example the command temip::data with subcommand type:
temip::data type type-spec
returns a TTS data object which can hold a value of the TeMIP data type specified by type-
spec, whereas:
temip::data info types
would return a list of all supported TeMIP data types.

Similarly each type of TTS object (dictionary, data, call, event, MIR and ACLOC) also has
subcommands for the various operations that can be performed on objects of the type.

There is also a TTS command to control the application process entity attributes for tracing and
to produce TeMIP trace lines.
All commands are described in details in Chapter 6.
Here is a summary of the available commands.
Dictionary command
The TeMIP dictionary contains information about static aspects of the TeMIP information
model. All the dictionary information is organized as a tree, starting with the entity class
hierarchy, and then for each class there is information about attributes, events, and directives,
including directive request and response arguments.
Each node of the tree is identified by an OID and contains information about an entity class or
one if its subordinate items such as an attribute or event report.
TeMIP dictionary information can be accessed using the TTS dictionary command
temip::dict 2 which creates a TTS object associated with a dictionary node. The desired
node can be identified by its OID or entity class name, and there are navigation commands to
move the node association up or down in the dictionary tree.
Dictionary objects can be used to investigate the contents of the dictionary. All of the
information found in the TeMIP dictionary can be retrieved by means of dictionary objects. For
example a node can be located using the navigation functions, and then its OID or data type can
be retrieved.
Data command
TeMIP data values represent the dynamic information in the TeMIP information model. They
occur as attributes of TeMIP entities, as call and response arguments for directive calls, and as
event arguments. There is a rich repertoire of types for TeMIP data values. The data type for
each attribute or argument is described in the TeMIP dictionary.
TeMIP data values are manipulated in TTS using data objects. A data object holds a data value
in encoded form. Every data value also has a decoded form, i.e. a string which can be used to
specify the value or represent it as output for further processing, including reading, although the
format may not be convenient. Creation of data objects is done by means of the TTS data
command temip::data. Encoding and decoding of values for a data object is then
accomplished by means of subcommands of the object itself or by using the object as a Tcl
variable. A data object may be associated with a TeMIP dictionary node, typically if it was
created with reference to an OID. This enables the use of display names, symbols and codes
defined in the dictionary in conjunction with the object, for example names of values of an
enumeration type, field names of a record types, or names of attributes in an attribute list.
Call command
The main capability of the common TTS commands is to make TeMIP calls. A TeMIP directive
call is made using a TTS call object. The TTS call command temip::call has a
subcommand setup, which takes a specification of verb (directive), entity and optionally
partition, and creates the call object. Arguments including attribute values and options can then
be added to the call object by means of the object subcommands set, duration and
qualifier, and the actual TeMIP call is triggered by the call subcommand.
After a directive call has returned, the complete response is held on the call object, and the
various parts of the response: response status, out-entity, timestamp and reply arguments
including attribute values can be retrieved and decoded by various subcommands. Reply
arguments may either be copied to TTS data objects for further processing or decoded directly.
The “more” flag which indicates that additional responses are retrievable by repeating the call
can also be inspected.
The basic mode of making TeMIP calls is the synchronous mode, where the calling Tcl
interpreter waits for the response from the called management module, and execution then
continues with the next Tcl command in the sequence, which would typically inspect the call
response. In synchronous mode multiple responses from a single directive call are typically
processed in a loop.
2
Not to be confused with the Tcl command “dict”

An asynchronous mode of making TeMIP calls is also supported, where the interpreter does not
wait for the response, but immediately proceeds to the next Tcl command in sequence, which in
this case should not assume that it makes sense to inspect the status of the call object that was
used to make the call. Asynchronous call mode is requested by specifying a callback command
as an argument to the call subcommand which invokes the TeMIP directive call. The response
from the called management module will occur as a Tcl event which will trigger a call to the
callback command. The calling script must include a call of the wait subcommand of the TTS
call command or of one of the standard Tcl event handling commands update or vwait, to
cause the interpreter to enter the state where it waits for the event to occur (see section 2.3.4).
The callback command will typically be a call to a procedure which processes the response. The
response can be inspected, not on the original call object, but on a special reply object which
supports the same subcommands as the call object for inspection of reply information.
TTS enforcement of TeMIP security is based on the call object. Before any call is made TTS
checks that the call object conforms to the active access control view.
Event command
TeMIP events are asynchronous messages which management modules can receive as responses
to the GetEvent directive called on some entity, typically wild-carded at multiple levels. The
process to produce events is described in chapter 4.1 of the TeMIP System Reference Manual. It
involves three parties as shown in Figure 1.
Figure 1, TeMIP Event Processing
Event Requester
get_event call get_event reply
Service Provider
(generic) event pool
Event Manager
applies filtering
Event Sink
forward event
incoming message
from network
• The access module (could also be an FM) which receives and replies to the GetEvent
directive (referred to in the referenced description as the service provider). A generic
implementation of this function is included in all access modules that deliver events. It is
also included as part of a TTS MM.
• TeMIP’s event manager, a central function within the TeMIP framework which on each
TeMIP director maintains an event pool. TeMIP has a set of general “low level” filtering
mechanisms that can be applied to events as they are processed by the event manager.
• The originator of the event, known as an event sink, which posts (“forwards”) the event to
the event manager to be put into the event pool, allowing it to be matched to a call of
GetEvent requesting events from the entity specified for the event report.
The TTS event command temip::event and event object can be used to build an event sink
function and have the capability to generate any type of TeMIP event and forward it to the event
manager. According to strict TeMIP modular architecture the event sink is a part of the service
provider management module which services the GetEvent directive, but the coupling is not
enforced, and the TTS event command is available with TTS MM as well as with TTS PM. With
TTS MM it can be used to build an event sink as an integrated part of a management module.
With TTS PM it can be used to generate events on behalf of any TeMIP entity regardless of
which management module implements other functions of the entity.

The event command has a subcommand setup which takes as parameters a specification of
entity, event partition, event id and optionally the OSI event arguments Event Type, Probable
Cause and Severity, and creates the event object. Further arguments can then be added to the
event object by means of additional subcommands, and finally the event can be forwarded to the
event manager by the forward subcommand.
ACLOC command
TTS always maintains an implicit security session based on the active access control view and
enforces security of all TeMIP calls that it makes in accordance with this security session.
The temip::acloc command provides a means to explicitly create and apply additional
security sessions. This can be used to apply tighter access control than implied by the active
access control view of a management module process or to handle multiple user sessions in a
MM.
MIR command
TTS gives access to the standard MIR (TeMIP Management Information Repository) data base,
used by many TeMIP management modules.
The MIR command temip::mir can create and/or open a standard MIR. An open MIR is
represented in TTS by a MIR object that implements a number of subcommands and also holds a
“cursor” to the entity currently worked on.
Note
More than one MIR object for the same MIR may exist simultaneously in a running TTS
script, allowing multiple cursors into the same MIR.
Each entity data set can hold attributes lists for all attributes in all partitions of the entity class
plus a user defined string. The partition data is compatible with the data layout used by e.g.
visual TeMIP written management modules.
The subcommands of the MIR object allows insert, alias, lookup and delete of entities in the
MIR, and read, write and merge of associated data.
Note
TTS also includes additional Tcl packages that allow access to both Oracle and SQLite
databases. These could also be used as local repositories in a management module.
2.1.4 Interpreter Contexts

All execution of Tcl code in TTS, whether in corrective filters, PM or MM, is done by Tcl
interpreters 3. The standard Tcl and TTS commands are always available. Additional commands
implemented in the standard manner in Tcl packages can also be included. The TTS commands
are themselves a Tcl package (Tts) that must be loaded into additional interpreters when these
are created explicitly.
The TTS commands are found in the dedicated ::temip and ::tts Tcl namespaces.
2.2 Presentation Module Capabilities

The TTS PM application is a TeMIP launched application with a Tcl interpreter integrated into
the TeMIP Framework. It supports the standard TTS commands in addition to the standard
repertoire of Tcl commands. Details of the PM are given in Chapter 7.
TTS PM command line
The TTS PM command and command line arguments has the form:
tts_pm ?filename? ?arg …?
3
A Tcl interpreter executes the Tcl/TTS commands and has a variable and command context that is
independent of all other Tcl interpreters. Multiple interpreters can be created in the same process and in the
same process thread. See http://www.tcl.tk/man/tcl8.5/TclCmd/interp.htm for details.

where the arguments (arg …) will be made available in the Tcl variable ::argv when called.
Note the standard Tcl documentation syntax using (? … ?) to indicate optional arguments.
Depending on the form of the command line which invokes the TTS PM, it may execute Tcl
commands read from the standard input of the process or from a file. In the first case TTS PM
will run interactively with line edit and history facilities.
Example (Start in interactive mode):
$ tts_pm
TTS>
Example (Start in interactive mode with arguments):

$ tts_pm –argumet1 –argument2
TTS> puts $argv
-argumet1 -argument2
TTS>
Example (Execute TTS script in file)

$ tts_pm myScript.tts –arg1 –arg2
$
Script files
A Tcl script for a TTS PM can be read and executed from a file. The file may be specified on the
UNIX command line as filename (see above for command line syntax), or a UNIX
executable file may be created.
Example (TTS executable file “helloworld”):
#!/bin/sh
# the next line restarts using tts_pm \
exec /usr/opt/temip/bin/tts_pm "$0" "$@"
# This is a TTS script file
puts {Hello World}
Example (Call TTS executable file “helloworld”):

$ helloworld
Hello World
$
Interactive example
The following example shows TTS PM being invoked from a UNIX command line ($) 4 without
arguments, followed by alternating Tcl command input (TTS>) and response output lines (with
no prompt). The example uses the low level temip::call command to prepare and make a
call of a Show directive, and then to examine the response.
Example (Interactive TTS commands):
$ tts_pm
TTS> set mycall [temip::call setup show {{oper demo-oc}} char]
::_Call_00000015
TTS> $mycall call
Response
TTS> $mycall response text
{Show Success} {}
Note that all interactive examples in this guide will use this form.
TeMIP security
When a TTS PM is started a security session is created. This is done by using the same wrapper
that is also used for the standard TeMIP command line application mcc_fcl_pm. The wrapper
will set the active access control view for the session, normally the default access control view
defined for the user.
4
The PATH environment variable must include the path /usr/opt/temip/bin. This is normally the case for
TeMIP users.

The TTS PM then enforces TeMIP security by applying the active access control view to all
TeMIP calls that are made within the session.
2.3 Management Module Capabilities

A TTS MM, like a TTS PM, incorporates Tcl interpreters with support for the common TTS
commands. In addition a TTS MM is integrated into the TeMIP Framework as an access module
(AM) or function module (FM) and supports any management model in a dictionary driven
manner. The model and behavior must be customized by the system integrator. The model is
specified using MSL in the standard TeMIP way, and the directive behavior is implemented
using TTS scripting. Whether the customized module is an AM or an FM affects only the way
calls are dispatched into the module; this piece of information must therefore be supplied when
the module is enrolled. It is not visible in the scripts that implement the behavior of the module.
TTS MM uses the facilities of class groups and verb groups which are supported by Visual
TeMIP (see Visual TeMIP Development Guide, section 6.4). It exploits the Visual TeMIP group
concept to accept calls of any directive against any entity that the system integrator has defined
and further dispatch the call to a script specific to that (verb, entity class) combination. The
directive script is called with a context which allows it to access the TeMIP call arguments and
to set values for the reply arguments which will be passed back in the TeMIP call response after
the script has returned.
If the customized module is to support the GetEvent directive, the standard definition of the
directive must be included in the information model specification. TTS MM includes the
standard TeMIP implementation of the directive (the “service provider” behavior mentioned in
the explanation of event processing given under the heading Event Command in section 2.1.3).
No script is however allowed for the GetEvent directive.
TTS MM does not provide support for automatic storing of entity attribute values. It is
completely up to the customization whether to use the TTS MIR command, Tcl variables, an
Oracle® database, SQLite database, UNIX files, or any other means to maintain any required
persistent state information.
TTS MM, like TTS PM, enforces TeMIP security according to the active access control view.
The active access control view of a management module will be determined by the owner of the
process running the management module (typically temip). It does not take into account the
identity of the caller of the directive, except if specifically specified by activating the user’s
ACLOC profile. The standard TeMIP method to tighten security with respect to the functions
performed by a management module is by restricting access to the directive calls exposed by the
module through the application of appropriate TeMIP user profiles. TTS also provides another
method for explicit control made within the management module: checking of call objects
against explicitly created security sessions. The most obvious use is to create a TTS ACLOC
session based on the identity of the caller of a directive rather than on the owner of the
management module process.
2.3.1 Management Model and Configuration File
The management model to be supported by a customized version of TTS MM can be freely
specified using MSL. It may be a new independent model or an extension of one that already
exists, supported by an existing management module.
In addition to the model specification a configuration file must be prepared describing the
relationship between the specific classes, verbs and attribute partitions of the customized
management model and the groups provided by TTS MM. This information is needed to build
the TeMIP directive dispatch table during module enrollment. The concepts of groups and
configuration files are described at length in the Visual TeMIP Development Guide, but the way
they are used with TTS MM is quite simple, and it is not necessary to master all the possible
forms of the configuration file.
The TTS MM provides class groups, named TTSXCG, and 4 associated verb groups, named
TTSXEG, TTSXMG, TTSXAG and TTSXGG, for verbs of type examine (like Show), modify
(like Set), action (like Create) and event (GetEvent) 5, respectively. In each group name the X is
to be replaced with a digit.
5
The GetEvent directive must be included in the configuration if events are emitted on the class.

The configuration file must map a class in the customized TeMIP model to a class group
TTSXCG, and each directive in the class to the verb groups of the class group.
2.3.2 Directive Scripts
The behavior of each verb in the model, i.e. each (verb, entity class) combination as specified in
MSL, must be implemented in a TTS script, which must be provided in a separate file, specific
to the directive. A directive script file must define one or more Tcl procedures with predefined
names: OnInit, OnExecute, OnInitialWild, OnExecuteWild, OnCancel, and
OnDone. The Tcl procedures whose names include ‘Wild’ are only needed for directives which
support wildcarding.
For a directive which does not support wildcarding of the in-entity, the functionality of the
directive is completely implemented in the OnExecute procedure which is executed once for
every call of the TeMIP directive. OnExecute is called with a context that allows the in-entity
and all call arguments to be read and the reply arguments, status and “more” flag to be set using
TTS commands.
For a wild carded directive call TTS MM will first call OnInitialWild once and then
OnExecuteWild repeatedly, as long as the Tcl script sets the “more” flag and the calling
management module repeats the call. Again the context allows these procedures to access the
information passed by the TeMIP call and to set the out-entity and reply arguments for each call
of OnExecuteWild.
The procedure OnCancel is optional. It is called if the TeMIP call is cancelled by the caller
while it is indicated that more data is available.
The procedures OnInit and OnDone are optional. They are called when the directive context
is initialized and later deleted. The Tcl interpreter running the directive procedures is guaranteed
to be the same as long as a directive context is active.
2.3.3 Interpreters, Contexts and Tcl Event Processing
There are several active Tcl interpreters in a TTS MM including the Master interpreter, the
Module interpreter and a dedicated interpreter for each directive (verb, entity class) combination
as shown in Figure 2.
Two special TTS commands are available in the TTS MM interpreters in addition to the
common ones that are also available in TTS PM, temip::module and temip::context
Figure 2, Tcl Interpreters in a TTS MM
directive Directive
module
call interpreter start
Master
Directive interpreter eval
interpreter eval
Module
interpreter
.... callback
Directive
interpreter
module
stop
Initializations needed to define a common environment for all interpreters belonging to a TTS
MM module can be placed in a common script which is sourced (executed) by all the
interpreters.
Each directive interpreter knows only the dedicated script for its particular directive. These
interpreters are initialized on the first call of each directive after the management module is
started. As the last initialization step the interpreter executes its directive script, thus learning the
specific procedures (OnExecute etc.) for the directive in question. If a directive is called while
its interpreter is still busy with a previous call, the interpreter may be cloned. The calls made to
retrieve a sequence of replies whose availability is indicated by the “more” flag will, however,
all go to the same interpreter, i.e. the Tcl interpreter context will remain unaltered between these
calls.

There is a debug option (temip::module debug) which causes the directive interpreters to
re-execute their directive scripts for each new TeMIP call, before calling the contained
procedures. This permits the scripts to be modified on the fly, so that a debug session can
proceed after a script modification without restarting the TTS MM application. For more
debugging options see section 11.5.
The module interpreter can be used to perform general initialization and cleanup tasks for the
management module.
The Master interpreter is the only one which can handle Tcl events (see section 2.3.4 below).
Like the directive interpreters it also has a dedicated script file. Management module actions
which do not require initiation by a directive call can be started in this script, for example a
permanent monitoring operation or the execution of tasks according to a time schedule. The
script should contain code that requests the desired events and sets up callbacks to handle them
when they occur.
When a directive interpreter is called from the TTS MM to perform a function associated with a
TeMIP call it must return control to the TTS MM when it has done the requested processing to
allow the TTS MM to return the TeMIP reply. A directive interpreter must not wait for a Tcl
event by calling a wait function. It is, however, still possible to initiate an action which will
continue after the occurrence of an event, by passing the command in question to the Master
interpreter for evaluation (shown as “eval” event in Figure 2, see module command below).
Module command
The TTS temip::module command allows scripts executed by a TTS MM to set and retrieve
module information. The name, id and model ownership of the module as defined at enrollment
time can be retrieved, and the values of the informative attributes on the self management
interface can be set, determining the response TTS MM will give when it is requested to Show
these attributes.
The eval subcommand of the TTS module command can be used by directive scripts to request
that a command be executed by the Master interpreter; this may e.g. be used to access variables
defined in the Master interpreter or to perform actions which request future events that must be
handled by callbacks.
Context command
The TTS temip::context command is available in the TTS MM in the interpreters which
execute the directive scripts, not in the Master interpreter. It is used to retrieve values passed as
in-entity, call arguments and attributes by the TeMIP directive call which is being processed and
to set values to be returned as out-entity, reply arguments and attributes. It also has
subcommands to identify a reply as an exception rather than a response and to convey the
“more” flag indicating that additional response data is available from the call.
2.3.4 Synchronous and Asynchronous Processing
A Tcl interpreter may operate synchronously or asynchronously (event driven). Synchronous
operation includes processing by a TTS PM of a stream of Tcl commands as they are read from
standard input or from a file and the execution by a TTS MM of the Tcl procedures associated
with the directives supported by the modules.
Asynchronous operation occurs when the interpreter is driven by Tcl events. The Tcl framework
has a queue of outstanding events (commands) that will be evaluated/executed whenever a Tcl
interpreter is in a wait point. This is normally referred to as background execution or callbacks.
The TTM PM includes initially only a single Tcl interpreter. This interpreter will operate in
pseudo asynchronous mode allowing background events to be executed each time a prompt is
presented in interactive mode (a single event is handled just before the prompt is shown). The
interpreter will only enter a real asynchronous mode under the standard Tcl conditions: if a
standard Tcl event handler command like update or vwait is called or if the Tk package is
loaded.
In a TTS MM the Master interpreter will enter asynchronous mode upon completing its
initialization. The directive interpreters in TTS MM and filters in CF do not have the capability
to operate in asynchronous mode, but they can use the temip::module eval command to
pass commands which request asynchronous handling, to the Master interpreter for evaluation.

2.3.5 Installation and Enrollment
Every customization of the TTS MM will result in a TeMIP management module, either an
access module or a functional module. The module must be given a name and an id (code) which
is unique across the entire TeMIP system. If the module supports a new global class (or several)
the same is true for the name and id of the global class(es).
The general procedure which must be followed to ensure uniqueness on all TeMIP systems
where a module may be used is to register the names and ids with the central TeMIP support
group (see Visual TeMIP Development Guide, section 1.4.4).
The steps to install and enroll a customized module based on TTS MM on a system where TTS
MM is already installed are few and simple, making use of the standard TeMIP utilities:
• Install the configuration file and the script files in the proper locations.
• Compile the model specification into the TeMIP dictionary using the standard compiler
mcc_msl and rebuild the TeMIP parse tables from the updated dictionary using
mcc_ptb.
• Enroll the TTS binary module to update the TeMIP dispatch tables using
temip_enroll; at this point it is defined whether the module is to be callable as an AM
or as an FM.
• Create the TeMIP application entity associated with the module.
The module can then be started by calling the start directive against its application entity or any
directive it supports.
Note
The TTS script files are not needed during the installation and enrollment process, only when
directives are actually called.
For details please see Chapter 8.
2.4 Corrective Filter Capabilities

Corrective filters are a special feature in TeMIP, described in the TeMIP Event Filtering and
Correlation User’s Guide, which makes it possible to modify (“correct”) selected events as they
are put into the event pool by the event manager, without having to make changes to the event
sink function in the management module. An understanding of TeMIP event processing as
explained under the heading Event Command in section 2.1.3 is needed in order to appreciate
corrective filter functionality.
Corrective filters can be implemented as a special use of TTS, outside the categories of TTS PM
and TTS MM. They are written as TTS scripts with access to TeMIP data and directive calls
through the full set of TTS commands. The mechanism to intercept a TeMIP event as it is being
put into the event pool by the event manager is the standard one, set up using entities of class
MCC CORRECTIVE_FILTER with attributes specifying the filtering to select events to be
corrected, in terms of the application name of the module containing the event sink, and a
discriminator construct which is applied to the entity against which the event is reported.
The TTS event filter command, which is only supported within a corrective filter script, can be
used to read, modify and write arguments of an event which meets the filtering criteria. It can
also create an associated event as a copy of the filtered event. The associated event will be
inserted into the event pool after the filtered event.
The corrective filter TTS core will be loaded into each Management Module that emits events to
be filtered (controlled by the Target attribute of the corrective filter instance and by the TeMIP
filter configuration). Each filter script will run in its own interpreter within each Management
Module, allowing for the filter script to initialize own global variables, procedures, etc. when the
script is loaded.
A Master interpreter is also started within the Management Module, similar to the Master
interpreter in a management module based on TTS MM (see section 2.3.3). The filter script
interpreter can communicate with this Master interpreter (called the FilterMaster) by means of

the eval subcommand of the TTS module command in the same way as directive interpreters in
TTS MM. If the management module loading the TTS corrective filer is itself a TTS
management module it will run two separate Master interpreter threads, one for the management
module and one for the corrective filters
For details please see Chapter 9.

Chapter 3
TTS Commands
This chapter gives a brief description of all the TTS commands and objects with subcommands,
starting with the high level, and then proceeding to the low level commands which are the most
numerous. The commands at the high levels are themselves implemented as Tcl procedures
using the low level commands.
The low level commands will be needed to build management modules (TTS MM applications),
to extract dictionary information, or if detailed control is required of how TeMIP calls are made.
For applications which can be built by making wholesale TeMIP directive calls the information
in section 3.2 will not be needed.
This chapter is intended to provide an overview. Therefore it does not describe the arguments
that each command takes, nor does it describe the results returned by all commands. For this
level of detail refer to Chapter 6.
3.1 High Level Commands

One very powerful command, called simply temip (in the global Tcl namespace), is similar in
power to the standard TeMIP command line utility “manage” (mcc_fcl_pm), but less
restrictive in terms of ensuring that all arguments agree with dictionary specifications. This
command is intended to be used interactively to test TeMIP functionality; it is not intended to be
used in scripts which implement solution functionality. The command is described in details in
Appendix A.
The other high level commands, which are all named in the ::temip, namespace are intended to
be used in scripts that will run as parts of integrated solutions. They provide a means to express
TeMIP directive calls as single Tcl commands. These commands return all of the reply
information returned from the TeMIP call, including the case of multiple responses, in a single
Tcl list. There are also commands to retrieve a list of entities satisfying a wild-carded description
and to set or get attribute values, possibly also across a wild-carded range of entities.
The four commands which map directly to TeMIP directive calls and which return complex
result lists are:
examine calls a directive of the examine type, typically Show.
modify calls a directive of the modify type, typically Set.
action calls a directive of the action type, typically Create or Delete or a
directive which performs a specific action on a network element.
getevent calls the GetEvent directive.
The additional commands may need to make multiple TeMIP calls and they return less complete
and therefore more simply formatted result information, focusing on the specific attribute values
involved:
expand retrieves a list of entities matching a wild-carded entity
specification, may include global entities which are not registered
with TeMIP and only instantiated by a management module,.
getattr retrieves values of specified attributes, possibly from multiple (wild-
carded) entities. The attributes may cut across partitions.

setattr sets value for specified attributes on a single entity. Again the
attributes may belong to different partitions.
show retrieves the value of a single attribute
set sets the value of a single attribute
The Tcl code for the high level commands listed above is installed as part of TTS. The user may
inspect any of the commands and add new.
These commands should not be used where high performance or control is demanded. The low
level commands described in the next chapter should be used instead.
3.2 Low Level Commands and TTS objects

Most of the low level TTS commands create or use TTS objects. TTS objects hold information
which is characteristic of the type of object. They are Tcl commands with subcommands which
can be used to invoke functions that use or modify the information they hold. TTS objects are
also Tcl variables that can be used to set and get the information as text.
The commands which create TTS objects return the auto-generated name of the created object as
result.
TTS> temip::data type Unsigned32
::_Data_00000000
Two techniques can be used for further manipulation of the object name: either 1) hold its name
as the value of a Tcl variable or 2) move/rename the object.
Here is an example of the first technique:
set MyNumber [temip::data type Unsigned32]
This command creates a data object and saves its name in the Tcl variable MyNumber, so the
subsequent command to set the data value to 123 will be:
$MyNumber encode 123
or
set $MyNumber 123
Here is an example of the latter technique using move:

[temip::data type Unsigned32] move MyNumber
This command creates a data object and renames it to MyNumber, so the subsequent command
to set the data value to 123 will be:
MyNumber encode 123
or
set MyNumber 123
3.2.1 Trace Command

The TTS trace command (temip::trace) allows the TTS application to use the standard
TeMIP trace and monitoring log facilities to produce and manipulate trace output, primarily for
troubleshooting purposes. It has these subcommands:
file sets or retrieves name of trace file.
mask sets or retrieves trace mask.
kernel sets or retrieves trace mask for the TeMIP framework.
trace writes a line specified by an argument to the trace file and stdout
of the module (AM, FM or PM), if trace mask permits.
prefix specifies a command which will be called to return prefix for each
trace line (called from within trace subcommand).
open opens a Tcl channel to write trace information to.

variable sets or cancels the name of a variable so that each trace line will be
appended to the value of the variable in addition to being written in
the trace file. One use of this, in conjunction with the standard Tcl
trace command, would be to trigger additional actions when
traces are generated.
mtlog produces an entry in the SystemMate monitoring log.
3.2.2 Dictionary Command
The TTS dictionary command (temip::dict) controls the use of the TeMIP dictionary and
creates TTS dictionary objects. It has these subcommands:
oid creates a dictionary object associated with a dictionary node
specified by an OID.
class creates a dictionary object associated with the dictionary node for an
entity class specified by code(s) or name(s).
reload controls whether to refresh the TTS copy of the TeMIP dictionary
when the latter changes.
onreload sets or cancels the name of a command to be executed when the
TeMIP dictionary changes.
deleteall deletes all dictionary object currently created.
info objects list names of current dictionary objects
Dictionary objects have these subcommands:
children returns a list of children - of a specified type - of the dictionary node
associated with the object.
down navigates association of the object one level down in the dictionary
tree, to a specified child node.
up navigates association of the object one level up in the dictionary
tree.
check checks that the object is associated with a valid dictionary node.
type retrieves the type of the dictionary node associated with the object.
oid retrieves OID of associated dictionary node or modifies the
association according to specified OID value.
definitions retrieves the definitions contained in the associated dictionary node.
datatype retrieves the data type of the item described by associated dictionary
node, only applicable for some types of nodes (attributes and
arguments).
private retrieves private text from associated dictionary node.
snmp retrieves SNMP OID from associated dictionary node.
cmip retrieves CMIP OID from associated dictionary node.
sql retrieves SQL information from associated dictionary node.
dependson retrieves “depends on” information from associated dictionary node.
move rename the object.
delete delete the object.
3.2.3 Data Command

The TTS data command (temip::data) serves primarily to create TTS data objects which are
used to hold and manipulate TeMIP data values. It has these subcommands:
type creates a data object of a specified data type; the object may
optionally be associated with a dictionary node to provide a frame of

reference for interpreting values given in terms of presentation
names, say values of enumeration types.
from creates a data object based on an OID, i.e. a reference to a dictionary
node. The data object will be capable of holding data values
appropriate for the data item (attribute or argument) described by
the node.
info types lists all supported TeMIP data types.
deleteall deletes all data object currently created.
info objects list names of current data objects
Data objects have these subcommands:
clone produces a clone of the object.
encode reads a data value provided in string format, encodes it and stores
the encoded form as the value of the data object.
decode decodes the data value of the object and returns it in string format
meta decodes and adds information about component types.
convert for some data types, provides an alternative to the standard encoding
and decoding, e.g. ILV dump.
show retrieves information from the data object other than its data value,
e.g. from associated dictionary node.
set modifies options of the data object other than its data value.
prune for entity data value: removes one or more levels of (class, instance)
pair from end of value.
clear discards data value but retains other information such as type and
association with dictionary node.
compare compares data object value to another data value or object.
3.2.4 Call Command

The TTS call command (temip::call) serves primarily to create TTS call objects which are
used to build and trigger TeMIP directive calls and to retrieve TeMIP call reply information. It
has these subcommands:
setup creates a call object with specified verb, in-entity and optionally
partition.
wait causes the Tcl interpreter to wait for a TeMIP call reply event. This
can be used when calls are made in the asynchronous mode.
alert alerts an outstanding call waiting in another TTS thread.
sigint disable external alerts.
deleteall deletes all call object currently created.
info objects list names of current call objects
A TTS call object interpreted as a command has facilities to set call arguments and other call
options, trigger an actual TeMIP call and retrieve response information. The subcommands for
call objects fall in four groups.
These subcommands do not belong to a specific phase of the call process:
list retrieves dictionary definitions for request arguments that have been
set on the call object, or reply arguments that have been returned
from the call, or attributes that have been set or returned.

type retrieves the type of the verb associated with the object: examine,
modify, action or event.
directive retrieves the name of the verb of the object.
partition retrieves the partition of the object.
dump shows debug information about the call object.
These subcommands build the call:
set sets values for request arguments and of attributes to be passed in an
attribute list argument.
default sets default flag for request arguments and of attributes to be passed
in an attribute list argument.
duration sets the duration for the call, typically used with the GetEvent
directive.
qualifier sets a qualifier for the call.
retry sets retry mode which determines handling of “Retry” exception.
There is one key subcommand to trigger the actual TeMIP call:
call causes TTS to make a TeMIP directive call based on the information
held in the call object.
A callback command may be specified for the call subcommand,
typically a call of a procedure dedicated to reply processing. If this
is the case the call will be made asynchronously, i.e. TTS will not
wait for the called module to respond before allowing the Tcl
interpreter to execute the next command in sequence. The callback
command will then be executed when the call reply event occurs,
provided the Tcl interpreter has entered the state where it where it
waits for the event.
If no callback command is specified the call will be synchronous,
i.e. TTS will not permit the interpreter to proceed with the next
command in sequence until the call reply has been received and the
information it contains been stored in the call object for further
processing.
A call may return multiple replies, the typical example being a wild-
carded Show. When this happens for a synchronous call, the call
subcommand must be executed repeatedly to retrieve each reply in
turn. If the call is asynchronous this is not necessary: the callback
command will automatically be called once for each reply event.
Post processing of call reply information uses either the original call object updated with reply
information or, for asynchronous call reply processing, a reply object which is a separate call
object, created as a copy of the original object and then updated with the reply information. The
reply object name is passed to the specified callback command as an appended argument.
There are six subcommands to retrieve reply information and perform other call post processing.
For synchronous calls post processing will typically happen in commands which follow the
call subcommand in line, for asynchronous calls it will typically be done in a reply processing
procedure.
response retrieves response status, to distinguish exceptions, successful and
unsuccessful responses.
timestamp retrieves the timestamp of the response.
entity retrieves the out-entity of the response; this is used for responses to
wild-carded calls where multiple responses are returned, for
different entities.
director retrieves the out-director of the response.
get retrieves the value of a specified attribute or reply argument.

more retrieves the more flag of the response, indicating whether
additional replies are available.
cancel cancels any further activity associated with the call and discards any
replies that have not been processed.
This subcommands change the call object scope:
3.2.5 Event Command

The TTS event command (temip::event) serves to create TTS event objects which are used
to build and send TeMIP events. It has this initial subcommand:
setup creates an event object with specified entity, event partition, event id
and optionally event type, probable cause and severity. If an event
type is specified the event is created as an OSI event. The event will
be subject to low-level filtering when forwarded.
nofiltersetup creates an event object as with the setup subcommand, but the
event will not be subject to low-level filtering when forwarded.
deleteall deletes all event object currently created.
info objects list names of current event objects
Event objects have these subcommands:
entity updates the out-entity specified for the event.
set sets values for optional event arguments.
timestamp sets a fixed timestamp on the event. If not set, the time stamp of an
emitted event will be set to the time it is emitted.
targetentity sets the target entity value.
targetseverity sets the target severity value.
forward forwards the event to the TeMIP event manager to be put into the
event pool from where it is emitted to TeMIP management modules
which have called the GetEvent directive to listen for it.
Event filter
The subcommand filter of the TTS event command can be seen as a command in its own
right. It is available only for corrective filter processing and always applies to the event which is
been filtered for corrective processing. It has the following subcommands:
entity retrieves or updates the out-entity of the filtered event.
get retrieves the value of an argument of the filtered event.
set updates the value of an argument of the filtered event.
alarm determines whether the filtered event is an alarm.
event retrieves the dictionary information about the filtered event.
associated creates an associated event for the filtered event.
targetentity retrieves or updates the target entity of the filtered event.
3.2.6 ACLOC Command

The TTS ACLOC command (temip::acloc) serves primarily to create TTS ACLOC objects
which can be used to perform security checks over and above those which TTS performs

implicitly. It can also be used to authenticate a user before an ACLOC object is created for that
user. It has these subcommands:
password authenticates a user by checking password.
session creates an ACLOC object for a specified user.
deleteall deletes all ACLOC object currently created.
info objects list names of current ACLOC objects
A TTS ACLCO object represents a TeMIP security session and has subcommands to validate
TeMIP directive calls against the security and to log violations.
info retrieves the information contents of the security session.
activate use the session object as the active ACLOC session for future
directive calls.
check validates a call object, directive, attribute or argument against the
security session.
log performs a validation like check and logs denial in the central and
user session logs. There is also a variant of the log subcommand to
explicitly log any string;
logall like log, but also logs valid checks. This can be used to log the
directive calls that are actually made.
3.2.7 MIR Command

The TTS MIR command (temip::mir) is used to check, create and open a collection of C-
ISAM files in the standard format used by TeMIP.
check check if the MIR exists.
open open a (new) MIR and creates a TTS MIR object for the specified
name
deleteall deletes all MIR object currently created.
info objects list names of current MIR objects
A TTS MIR object represents a connection with the MIR. The object holds the entity in the MIR
currently being worked on (the cursor).
insert inserts a new entity in the MIR.
alias inserts a new entity in the MIR that references the same data as the
current entity.
remove removes an entity or alias from the MIR.
entity returns the current entity.
key returns or sets the current entity.
lookup find one or more entities by iterating through the MIR.
write writes a user defined string to the current entity associated data.
read read the user defined string from the current entity associated data.
set sets a list of attribute values in the specified partition in the current
entity associated data.
show returns a list of attribute values from the specified partition in the
current entity associated data.

3.3 High level commands v. low level command example

The following example show the same functionality implemented using high level TTS
commands respectively low level TTS command.
# Stop a TeMIP management module for sure

# The stop directive may return before application is fully stopped
# So retry until no PIDs are returned in response
Using high-level TTS procedures.

proc stopMM {appl {restart false}} {
while {true} {
# Call stop directive
set r [temip::action stop "{mcc 0} {appl $appl}"]
if {[lindex $r 0 0 1] ne "Response"} {
# Bad response
if {[lindex $r 0 0 2 0] == "No Such Entity"} {
# Bad application name
return false
}
# Try again
after 1000
continue
}
# Get PIDs from reply
set p [lindex $r 0 1 0 1 0 1][lindex $r 0 1 0 1 1 1]
if {$p ne ""} {
# Not stopped. Wait 1 sec.
after 1000
} else {
# Stopped
break
}
}
if {$restart} {
# Start again
temip::action start "{mcc 0} {appl $appl}"
}
return true
}
Using low-level TTS commands.

proc stopMM {appl {restart false}} {
[temip::call setup stop "{mcc 0} {appl $appl}"] move callStop
while {true} {
# Call stop directive
if {[callStop call] ne "Response"} {
# Bad response
if {[callStop response code] == 3} {
# Bad application name
return false
}
# Try again
after 1000
continue
}
# Get PIDs from reply
array set p [join [callStop get reply "Process list"]]
if {$p(self_stopped) ne "" || $p(forced_to_stop) ne ""} {
# Not stopped. Wait 1 sec.
after 1000
} else {
# Stopped
break
}
}
if {$restart} {
# Start again
temip::action start "{mcc 0} {appl $appl}"
}
return true
}

Chapter 4
Suggested Uses of TTS
This chapter gives brief descriptions of a number of suggested uses of TTS with small figures
illustrating how the scripted function is positioned relative to and inter-works with other solution
components, notably the TeMIP Framework. The first six suggestions can be built with TTS PM
as indicated by blue circles; the remaining ones will require TTS MM indicated by blue
rectangles.
4.1 System Configuration Scripts

Many aspects of TeMIP systems can be configured by creating TeMIP entities
with appropriate values. Such configurations are typically implemented by means
of configuration scripts written in FCL. The scripts will then be stored as
documentation, allowing the configuration setup to be rerun, in particular after
modification. Version control can be applied to configuration scripts.
Similarly data representing the managed network can be loaded by means of FCL
scripts. The demarcation line between system configuration and data loading may not always be
sharp, and as the same tool can be used for both purposes this does not matter.
TeMIP Tcl Scripting is an attractive alternative for these kinds of configuration and data loading.
Advantages over FCL include the ability to read relevant data from sources such as databases or
the existing configuration of the network elements into the process and the use of control
structures such as conditional commands and looping which is an obvious advantage when many
similar entities must be created or have attribute values set.
4.2 Information Extract and Presentation

The example above (4.1) was about creating entities and setting
their attribute values. This example is about retrieving entities
and their attribute values. Many meaningful reports can be
created based on data available in TeMIP’s management model
by means of scripts which extract the data by Show operations
and then perform various calculations, for example to select or categorize entities which satisfy
some filter criteria, to compare attribute values for different entities, and/or to summarize the
information. Finally the resulting information can be presented in a printable report.
For reports based on massive amounts of data the appropriate method may be to extract the
information to a data warehouse and use database reporting tools. For smaller scale and ad hoc
type tasks TTS scripts will do the job.
It will also be simple to combine data extracted from TeMIP with data available from other
sources, such as an inventory database.
The description above is rather abstract, as a concrete example considers the following: Given a
network comprising network elements of several types, suppose there is a suspicion of high
failure rates on cards manufactured during a certain period. Now extract from the relevant
Operation Context recent alarms of relevant types (probable cause), for each alarm retrieve
information about the network element card child entity on which the fault occurred and list all
of these cards with purchase date and manufacturer’s serial number fetched from an inventory
database. The report can then be scrutinized to confirm or reject the suspicion.

4.3 Simple GUI
In the above example (4.2) suppose a graphical display would be more
appropriate than a printed report, then the script can be modified to use
the Tk GUI toolkit to create the appropriate table or other form of
presentation.
Small dedicated GUIs can also be written easily to allow actions to be
invoked, for example across several entity classes, including data entry
fields and action buttons. Each action may include calling of multiple
directives on different entity classes, some of them conditionally. Such a GUI can be a great
simplification over procedures with multiple steps to invoke directives using TeMIP’s generic
Map Viewer.
4.4 Web Server

This is a variant of the previous case (4.3). If a GUI needs to be
available to end customers or dispersed management staff without
access to TeMIP workstations it can be web enabled by using CGI
scripting. This can be built using a Tcl CGI package instead of Tk.
4.5 Automatic Alarm Acknowledge

There are a several cases where automatic acknowledgement of certain alarms
would be a great convenience for operators:
• Alarms arrive from a network element management system, which forwards
an acknowledgement message when an operator acknowledges an alarm on
that system’s GUI. These messages are emitted by the AM as events.
• An operator wishes to acknowledge all alarms which share a specific property which can
be specified, say, in terms of the occurrence of a specific substring within the additional
text.
• The TeMIP Service Monitor is deployed to correlate alarms, and the operator wishes to
acknowledge all alarms which affect the same monitored target entities as a specific root
problem alarm.
In each of these cases it will be simple to implement a TTS script which accesses data in the
appropriate TeMIP models, including alarm objects in one or more operation contexts, identifies
the relevant alarms and acknowledges them. The specific algorithms will differ from case to
case.
4.6 Northbound Integration

A TeMIP system must to be integrated with a client application which runs on
a different hardware and OS platform. The client needs to be able to forward
requests to the TeMIP system. These requests may map to directive calls
against an existing management module, or some limited functionality must
be implemented around the directive calls, possibly mapping each request to a
small number of directive calls, some of them conditional.
This can be achieved by implementing the functionality of each request in a
Tcl procedure using TTS PM to make the TeMIP calls. The procedures can be
called remotely from a small Tcl script on the client system which forms the
interface into the client applications. Secure sockets can be used for the remote call interface.

4.7 Alarm Mapping
Many available AMs do not properly map received alarms to TeMIP entities
representing the appropriate physical or functional parts of a given
equipment. To compensate for this without re-implementing the entire AM a
TTS script can be written which receives each alarm event from the AM,
analyses the contents – typically all batched together in the Additional Text
argument, and reemits the alarm event against the proper entity with proper values for event
type, probable cause and specific problem, to allow further processing by applications which
rely on a detailed modeling using the OSI fields. To ensure that the mapping is automatically
kept running at all times, it can be implemented in the Master interpreter of TTS MM, but would
in itself not require any directives to be implemented. Directives could be added, if needed, to
provide dynamic control of the mapping.
4.8 Simple AM
For simple management interfaces where no network element state information or
only a very small amount needs to be stored by the AM a complete AM can be
constructed using TTS MM. If the network element or element management
system to which the AM must interface provides fast responses, command
dialogues can be implemented in directive scripts for Set and action directives as
well as the Show directive. Event processing can be done in callbacks executed in
the Master interpreter.
4.9 Importing Data to TeMIP Entities

Consider a device which produces performance data at regular intervals
in the form of comma separated flat files. It is desirable to access the data
in the form of attribute values on TeMIP entities, because tools already
exist to process the data when they take this form, e.g. Acanthis TeMIP
Warehouse.
This can be implemented with a management model which represents every line in the file as a
TeMIP entity, with the identifier based on a timestamp or serial number of the reading, and
every item in the line as an attribute. The important directive to implement in a script for TTS
MM is Show which must read the file and retrieve the line which is indicated, or all lines when
wild-carded.
4.10 Combined Inventory and Element

Information Retrieval
Consider some network elements for which an AM is already available
and has the ability to retrieve information about a number of
configuration parameters on the equipment, say on different cards.
Suppose there is also an inventory system with asset management information about the same
equipment: serial numbers, date of purchase, etc. Now it becomes desirable to access the
combined information as a single model. This could be done at the GUI level as described in 4.2
and 4.3. Alternatively an FM can be built using TTS MM against a combined model to fetch the
attributes from the different sources available, the equipment attributes from the existing AM,
the business attributes from the inventory database. One way to model the combined information
would be for each child class of the existing model to add a new class with the combined set of
attributes, and then implement the directives, Show being the important one, for the new classes
as a customization of TTS MM. A simpler alternative, which might be satisfactory, would be
just to extend the model of the existing AM with new attribute partitions for inventory
information.

4.11 Director-to-Director Integration
There are cases where a service provider can have several
TeMIP systems, but it is impossible or undesirable to integrate
them into a single distributed system. For example, one system
could be an element management system supplied on OEM
terms by an equipment vendor, and also supported by that
vendor. Or, the systems could be for a number of regions, and
possibly a single national or international overview system, run
by different organizations, each responsible for the operation
within one region.
In both of these cases there will be one Master system and one
or more subordinate systems, either local/regional systems, or a
management system for a vendor-specific subnetwork or network element type. The amount of
interaction and information exchange that will be needed between the systems will be limited. In
one example, it could be that a part of the information model used for network monitoring on the
regional systems and some important alarms mapped occurring against that part of the model,
should also be visible on the inter-regional system. In the other example, it must be possible for
the overall management system to issue commands to control the vendor-specific network
elements, possibly at the subnetwork level.
One approach to this type of integration could be to produce a TMN management model
expressed in GDMO for the functions required on the interface between subordinate (agent) and
client (manager) system. The TeMIP OSI toolkits could then be used to build an AM and a PM,
respectively that could be used as interfacing modules. But this approach is likely to be quite
cumbersome.
Another approach is to use TTS. As far as the subordinate systems are concerned, this case is the
same as 4.6. On the client system, to make the capabilities of the subordinate systems generally
available as TeMIP callable functionality, a management model can be defined which captures
all the relevant interactions, such as entities against which alarms must be received, Show
directives to retrieve information, and modify/action type directives to perform network element
or subnetwork configuration tasks. The management model is then implemented as a
customization of TTS MM, with all calls to the subordinate systems being made as remote Tcl
procedure calls through secure sockets.
4.12 Corrective Filter

Some existing access modules do not map all the information which is available in
alarm reports received from network elements or element managers to the relevant
OSI alarm arguments, but just dump the information in raw unanalyzed form into
the Additional Text event argument. In order, for example, to monitor alarms
using TSM, a mapping is needed which allows the precise point within a network
element where a problem occurs to be identified by the Managed Object event
argument. Provided the necessary information is available in the event, the object
mapping can be refined by a corrective filter.
With TTS a corrective filter can be implemented very simply in a few lines of script. All event
information can be inspected and corrected from within the script.

Chapter 5
Example AM
Section 5.1 contains a complete example of a TeMIP access module, called person_am, built
using the TTS MM application. Section 5.2 shows how to install the example in the TeMIP
environment and section 5.3 includes some scripts that can be run using a TTS PM to retrieve
dictionary information about person_am and the data it makes showable.
5.1 Management Module person_am

The access module (AM) which is presented in this section, person_am, reads data from a
comma-separated file (CSV) and presents it as a TeMIP management model. The problem to be
solved is the same as described in section 4.9, except that for the sake of simplification the data
considered here is not network element performance data, but a set of simple attributes
describing a person: age, gender, number of children and mood.
The data file from which data is imported could look like:
File /var/opt/temip/person_am/data
Peter,30,M,1,Happy
Miranda,8,F,0,Thrilled
Arthur,65,M,5,Depressed
The first task in the customization process is to decide the TeMIP management model. The
model chosen in this example has only a single class, which is therefore a global class, where
each person described in the data file is represented as an entity. The name of the person is the
identifier attribute (making it impossible to distinguish between multiple persons with the same
name, but that is not important for the example). The other four attributes are all implemented in
the characteristic partition. The only directive supported in this example is Show.
The model must be specified in MSL as shown below 6.
Note that a globally unique code must be assigned to the global class. In this example the code is
180651.
File person_am_srvc_if.ms
MANAGEMENT SPECIFICATION tts_person_am_info_model;

VERSION = V1.0.0;
SYMBOL-PREFIX = TTS_;
GLOBAL ENTITY Person = 180651 :

IDENTIFIER = ( Name ),
IDENTIFIER ATTRIBUTES
ATTRIBUTE Name = 1 : FullName

DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETTABLE,
DISPLAY = TRUE
6
A template is available in /usr/opt/temip/tts/mm/models/tts_mm_srvc_if_template.ms

END ATTRIBUTE Name;
END ATTRIBUTES; (* IDENTIFIER *)
CHARACTERISTIC ATTRIBUTES
ATTRIBUTE Age = 2 : Unsigned32

DISPLAY = TRUE
END ATTRIBUTE Age;
ATTRIBUTE Gender = 3 : Latin1String

DISPLAY = TRUE
END ATTRIBUTE Gender;
ATTRIBUTE Children = 4 : Unsigned32

DISPLAY = TRUE
END ATTRIBUTE Children;
ATTRIBUTE Mood = 5 : Latin1String

DISPLAY = TRUE
END ATTRIBUTE Mood;
END ATTRIBUTES; (* CHARACTERISTIC *)
(* Include standard definition of Show directive *)

INCLUDE mcc_show_directive.ms;
END ENTITY Person;
END SPECIFICATION tts_person_am_info_model.
It is also necessary to describe the self-management model for the module. TTS includes a
template file for this 7. The module name (person_am) and module id must be edited into the
template. The beginning of the self-management MSL file for person_am is shown below with
module name and id appearing in the CHILD ENTITY line. Note that the code for the global
class is reused as module id. This is customary for management modules which support a single
global class.
File person_am_mgmt_if.ms
MANAGEMENT SPECIFICATION tts_person_am_self_model;

VERSION = V1.0.0;
SYMBOL-PREFIX = TTS_MM_;
CHILD ENTITY person_am = 180651 :

PARENT = ( MCC ),
IDENTIFIER = ( ),
...
END ENTITY person_am;

END SPECIFICATION tts_person_am_self_model.
The next is the configuration file which binds the person_am module to the class group
implementation in TTS MM. It has two lines, one that establishes the attribute partition binding
for class Person (IDENTIFIER and CHARACTERISTIC), and one subordinate line that does the
same for the verb SHOW.
File /var/opt/temip/conf/person_am.cfg
ClassGroup= TTSCG, Class= (Person), ClassPartitionIds= (1, 4)

VerbGroup = TTSEG, VerbIds = (1)
7
/usr/opt/temip/tts/mm/models/tts_mm_mgmt_if_template.ms

Finally the functional behavior of module person_am is implemented in Tcl scripts. There is no
need for functionality to be implemented in the files Common.tts or Master.tts, so they are left
empty. To enable TTS MM to respond sensibly to a request to show the standard self
management attributes, the OnInit procedure in the module script Module.tts provides values
for the attributes using subcommands of temip::module. It also writes a line to the trace log
to indicate that person_am is being restarted and it sets the debug mode on. When the debug
mode is on, you may make changes to the TTS directive scripts and test them without restarting
the AM.
File /usr/opt/temip/tts/mm/scripts/person_am/Module.tts
temip::trace trace 0 "Evaluating person_am/Module.tts"
proc OnInit {} {
temip::trace trace 0 "Initializing module person_am"
temip::module debug on
temip::module description "Person AM, retrieves person data from file"

temip::module version set V1.0.0
}
The core functionality is that of the Show directive on entity class Person, implemented in the
directive script file TTSCG/Show.tts. It reads the person data file from the location shown in the
example at the beginning of this section. The file location is “hard coded” into the script.
Due to the simple nature of the task at hand the only TTS command which is needed is
temip::context. It is used to retrieve the in-entity and partition that the directive call
concerns and to pass out-entity, attribute values and exceptions as replies. The script is
commented to be self-explanatory.
It should be noted that to keep the example simple there is no checking that the data file is
present and correctly formatted, and no handling of partial wildcarding and no handling of
instance value upper/lower case conversion.
In a real implementation some error handling, etc. would most likely be needed.
File /usr/opt/temip/tts/mm/scripts/person_am/TTSCG/Show.tts
# Management module person_am

# Directive script for Show directive on (global) class person
# First part: Private utility procedures
# Read file with person data into global array ::data

# indexed by name
proc readdata {} {
# Clean up any old data (from prev. calls)
catch {unset ::data}
# Read file into array
set ch [open /var/opt/temip/person_am/data]
while true {
set line [split [gets $ch] ,]
if {![chan eof $ch]} {
set ::data([lindex $line 0]) [lrange $line 1 4]
} else {
break
}
}
chan close $ch
}
# Sets attributes in reply using values in ::data

proc setReplyAttrs {name} {
if {[temip::context partition] eq "Identifiers"} {
temip::context set attribute Name $name
} else {
temip::context set attribute Age [lindex $::data($name) 0]
temip::context set attribute Gender [lindex $::data($name) 1]
temip::context set attribute Children [lindex $::data($name) 2]
temip::context set attribute Mood [lindex $::data($name) 3]

}
}
# Builds "No Such Entity" reply

proc noEntity {} {
temip::context replycode "No Such Entity" CommonException
}
# Second part: Entry points called by TTS MM framework
# Entry point for specified in-entity (not wild carded)

proc OnExecute {} {
# Get data from file
readdata
# Get in-entity instance name without namespace prefix
set inName [temip::context instance -last -nonamespace]
# Set attributes for name if it exists
if [info exists ::data($inName)] {
# Set attribute values
setReplyAttrs $inName
} else {
noEntity
}
# Return reply
}
# Entry point for opening of wildcard processing

proc OnInitialWild {} {
# Get data from file
readdata
}
# Entry point to get next reply during wildcard processing

proc OnExecuteWild {} {
if {[array size ::data] > 0} {
# Use name from first entry in ::data
set name [lindex [array get ::data] 0]
# Set as out entity (overwriting the *)
temip::context outentity [list [list person $name]]
# Set attribute values for name
setReplyAttrs $name
# Remove it from ::data
unset ::data($name)
# Check if more names in ::data
if {[array size ::data] > 0} {
# Tell caller that we have more
temip::context more
}
} else {
noEntity
}
# Return reply
}
5.2 Installing the example AM

The installation of the example AM may be done using the following UNIX shell commands.
The more complete description of the configuration and installation process can be fund in
Chapter 8.
Run as root.
$ su – root
Check that we have all files.

$ ls *.ms
person_am_mgmt_if.ms person_am_srvc_if.ms
$ ls /usr/opt/temip/tts/mm/scripts/person_am
Module.tts TTSCG
$ ls /usr/opt/temip/tts/mm/scripts/person_am/TTSCG
Show.tts
$ ls /var/opt/temip/conf/person_am.cfg
/var/opt/temip/conf/person_am.cfg
$ ls /var/opt/temip/person_am/data
/var/opt/temip/person_am/data

Install TeMIP dictionary for AM.
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl -I/usr/opt/temip/mmtoolkit/msl
person_am_mgmt_if.ms
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl -I/usr/opt/temip/mmtoolkit/msl
person_am_srvc_if.ms
$ /usr/opt/temip/mmtoolkit/bin/mcc_ptb
$ reloaddictionary mcc 0
Enroll the AM.

$ TTS_MM_TYPE=AM temip_enroll -m person_am -f /usr/opt/temip/bin/tts_mm -i
180651
$ manage create mcc 0 application person_am application type = MM, filename
= /usr/opt/temip/bin/tts_mm
Now the AM is installed. Let’s try it.

$ manage show person Peter all attrib
TeMIP Framework (V6.0.0)
Person rap_ns:.Peter
On director: rap_ns:.temip.rap_director
AT Thu, Apr 2, 2009 10:22:31 AM All Attributes
Name = rap_ns:.Peter
Age = 30
Gender = "M"
Children = 1
Mood = "Happy"
As no global entities are registered for the class Person, the FCL/manage utility are not able to
show wild carded instances. We can use the TTS examine command to show them anyway.
$ tts_pm
TTS> temip::examine show {{person *}} char
{{{{Person Peter}} Response {SHOW_SUCCESS {Examination of attributes
shows}} 2009-04-02-10:19:58} {{Age 30} {Gender M} {Children 1} {Mood
Happy}}} {{{{Person Miranda}} Response {SHOW_SUCCESS {Examination of
attributes shows}} 2009-04-02-10:19:58} {{Age 8} {Gender F} {Children 0}
{Mood Thrilled}}} {{{{Person Arthur}} Response {SHOW_SUCCESS {Examination
of attributes shows}} 2009-04-02-10:19:58} {{Age 65} {Gender M} {Children
5} {Mood Depressed}}}
Or
TTS> temip show {{person *}} {expand no}
Show Identifiers @ 2009-04-03-10:22:22.686 on rap_ns:.temip.rap_director
Response @ 2009-04-03-10:22:23.714 from {{Person rap_ns:.Miranda}}
SHOW_SUCCESS :: Examination of attributes shows
Name = rap_ns:.Miranda
Response @ 2009-04-03-10:22:23.715 from {{Person rap_ns:.Peter}}
Name = rap_ns:.Peter
Response @ 2009-04-03-10:22:23.716 from {{Person rap_ns:.Arthur}}
Name = rap_ns:.Arthur
The example AM can be un-installed again using the following UNIX shell commands.
$ su – root
$ manage stop MCC 0 application person_am
$ manage delete MCC 0 application person_am
$ temip_enroll -r person_am
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl -r1.3.12.2.1011.2.22.1.180651
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl -r1.3.12.2.1011.2.22.1.7.180651
$ reloaddictionary mcc 0
$ rm person_am_mgmt_if.ms person_am_srvc_if.ms
/usr/opt/temip/tts/mm/scripts/person_am/ Module.tts
/usr/opt/temip/tts/mm/scripts/person_am/TTSCG/Show.tts
/var/opt/temip/conf/person_am.cfg /var/opt/temip/person_am/data
5.3 Viewing Person Dictionary and Data Using a TTS PM

This section shows a TTS PM dialogue which examines the dictionary information for class
Person and uses the different commands to extract Person data from person_am. First a look into
the dictionary:

$ tts_pm
TTS> [temip::dict class Person] move di
::di
TTS> di children Attribute
{1 Name 1.3.12.2.1011.2.22.2.180651.126.1} {2 Age
1.3.12.2.1011.2.22.2.180651.126.2} {3 Gender
1.3.12.2.1011.2.22.2.180651.126.3} {4 Children
1.3.12.2.1011.2.22.2.180651.126.4} {5 Mood
1.3.12.2.1011.2.22.2.180651.126.5}
TTS> di definitions
180651 Person {} NotDynamic Required
TTS> di down Attribute 3
::di
TTS> di oid
1.3.12.2.1011.2.22.2.180651.126.3
TTS> di definitions
3 Gender {} Display {3 Latin1String} NoDefault {} {} Predictable
NonSettable 4 All NotUsed
These commands (not specifically related to person_am) show how to create and encode a value
for a data object of a simple type:
TTS> [temip::data type Latin1String] move s
::s
TTS> s encode Hello
::s
TTS> set s
Hello
The following low level commands make a Show call to retrieve the data for Miranda, get the
entire attribute list from the call as a single data object and inspect the association of this object
to the dictionary:
TTS> [temip::call setup Show {{Person Miranda}} char] move c
::c
TTS> c call
Response
TTS> [c get reply 1 -object] move attrs
::attrs
TTS> attrs decode
{Age 8 Available} {Gender F Available} {Children 0 Available} {Mood
Thrilled Available}
TTS> attrs show association
1.3.12.2.1011.2.22.6.180651.126.1.1.1 0
TTS> c get attribute Age -object
::_Data_00000007
TTS> c get attribute Age
8
TTS> c more
0
Finally a procedure to rebuild the comma separated file from the result of a wild-carded call:
proc writeData {res} {
foreach entRes $res {
set outEntity [lindex $entRes 0 0]
set line [lindex [split [lindex $outEntity 0 1] .] 1]
foreach attr [lindex $entRes 1] {
append line , [lindex $attr 1]
}
puts $line
}
}
and a call of the procedure using a high level TTS call to do the wild-carded show:
TTS> writeData [temip::examine Show {{Person *}} char]
Peter,30,M,1,Happy
Miranda,8,F,0,Thrilled
Arthur,65,M,5,Depressed

5.4 Raising TeMIP alarms from the example AM
As any management module in TeMIP, a TTS AM can also emit events that can be monitored
by Operation Contexts (OCs) and handled as alarms. The following code example will run in the
Master thread of the person_am created and installed in the previous sections of this chapter.
The code will listen for changes to the data file used by the AM directives
(/var/opt/temip/person_am/data) and emit an event if it is updated. This has no real
life use and is just used here as an example of the functionality available in a TTS management
module.
The code is implemented in the Master.tts file located in
/usr/opt/temip/tts/mm/scripts/person_am
please refer to chapter 8.4 for a description of the use of the Master.tts file.
File /usr/opt/temip/tts/mm/scripts/person_am/Master.tts
# Management module person_am

# Master script
# Listen for changes to file and emit event to notify.
proc sendEvent {file} {

set MO {{mcc 0} person_am}
set part {NOTIFICATION EVENTS}
set id {Operational Violation}
set type IntegrityViolation
set cause AuthenticationFailure
set severity Minor
[temip::event setup $MO $part $id $type $cause $severity] move ev
ev set "additional text" "File $file modified"
ev forward
}
proc listenForFileChange {file} {

set mtime [file mtime $file]
if {$::lastmtime != $mtime} {
# File was changed
set ::lastmtime $mtime
sendEvent $file
}
# Check again after 1 minute
after 60000 listenForFileChange $file
}
proc startFileMonitor {file} {

set ::lastmtime [file mtime $file]
listenForFileChange $file
}
startFileMonitor /var/opt/temip/person_am/data
Note that the files mcc_getevent_directive.ms, osi_types.ms and osi_alarms.ms must be included
in the person_am self management model (person_am_mgmt_if.ms), if the event is emitted on
that class, as in this example.
INCLUDE osi_types.ms;
INCLUDE osi_alarms.ms;
INCLUDE mcc_getevent_directive.ms;
In general; the used event model definitions and the GetEvent directive must be defined for the
class that an event is submitted on.

Part II
TTS Reference Material

Chapter 6
TTS Commands Reference Information
This chapter is the core of the present manual in that it provides the detailed descriptions of all
of the commands that are available in TTS together with associated reference documentation.
Section 6.1describes how TTS applications, whether MM or PM, are described and controlled in
TeMIP using application and application process entities on the TeMIP self-management
interface. One function that can be controlled through the application process entity is tracing.
With TTS this is done by means of the trace command which is described in section 6.6.
Section 6.2 describes properties which are common to all TTS objects (dictionary, data, call,
mir, event and acloc).
An important issue that cuts across all TTS commands is how to represent TeMIP data values in
Tcl, i.e. how to specify values for data that must be encoded for use within TeMIP. The subject
of representation of data values is covered in section 6.3, and section 6.4 then briefly
summarizes how TeMIP data values can be specified in TTS commands.
Descriptions of the TTS high level commands are given in section 6.4.2.
Section 6.7 contains background information on the structure and codes used in the TeMIP
dictionary. Section 6.8 then describes the TTS dictionary command and dictionary object which
can be used to inspect the contents of the dictionary.
The last five sections (6.9, 6.10, 6.11, 6.12 and 6.13) describe, respectively, the TTS data, call,
event, acloc and mir commands and the corresponding TTS objects.
6.1 TTS Module Application and Process Entities

In TeMIP every management module is described by an application entity on the TeMIP self
management interface named ‘MCC director APPLICATION module-name’. Information held
on this entity includes identification of the executable for the module and default values for trace
mask and trace file name.
For TTS PM the application entity with module name tts_pm is created during installation of the
TTS kit. For customized TTS PM and MM modules the application entity must be created as
part of module installation (see section 8.7).
For every running instance of a management module an application process entity named ‘MCC
director APPLICATION module-name PROCESS pid’ is created (as a child of the application
entity) automatically by the TeMIP framework along with the UNIX process. The actual trace
mask and trace file name used by a running module process are attributes of this entity.
6.2 TTS Objects

Most of the TTS commands create or use TTS objects. TTS objects hold information which is
characteristic of the type of object. TTS objects are Tcl commands with subcommands that may
be used to invoke functions which retrieve, use or modify the information they hold. TTS data,
MIR and dictionary objects can also be used as Tcl variables to manipulate the information they
hold (see sections 6.8, 6.9 and 6.13).
6.2.1 Names and scope
The commands which create TTS objects return the name of the created object as result. The
name will act as the name of both the Tcl command and the Tcl variable (when relevant), and so
it cannot be used as the name of another Tcl command (procedure) or variable.

Example (Create data object that hold unsigned 32 bit values):
TTS> temip::data type Unsigned32
::_Data_00000001
Here the command temip::data creates a new TeMIP data object with the name
::_Data_00000001
The name that is given to a TTS object is auto-generated within the current namespace when the
object is created. To enable the code which creates the object to control the naming, the move
command (described below) is supported for all TTS objects. The standard Tcl rename
command can also be used for a simple control of the name of an object.
An object is visible in a Tcl script according to the following rules:
Variable As a Tcl variables (using Tcl command upvar etc,)
Command In the Tcl namespace where the object is created or moved to.
Reference Same as a command.
If an object is global (in any namespace), then it is always available using fully qualified name.
Important
The lifetime of a TTS object is determined by its scope according to the same rules that apply
for Tcl variables, unless it is explicitly deleted.
6.2.2 Deletion
TTSObj delete
TTSObj deleteall
All TTS objects support the delete subcommand, which will delete the object it is called on.
For each kind of TTS object the deleteall subcommand of the main TTS commands dict,
data, call, event, mir and acloc can be used to delete all objects of that kind in all namespaces
within a the Tcl interpreter. This may be useful in a situation where a general cleanup is needed,
for example when an error situation occurs during the processing of a directive call in a TTS
MM application.
TTSCommand info object
Each of the six TTS low-level commands also supports a subcommand info object which
returns a list of the names of all the current TTS objects of the kind in question.
6.2.3 Renaming
TTSObj move newname ?level?
The move sub-command changes the name of an object TTSObj to newname and returns the
new name including the complete namespace path. The specified new name may optionally
include a namespace; if it does not, the current namespace is used. If newname is empty or only
a namespace ("" or "MySpace:: ") the object name is auto generated to be unique within the
specified namespace.
When the namespace of an object is changed then its scope changes accordingly.
A Tcl array element can also be given as newname, allowing arrays of TTS objects.
If newname is the name of an existing Tcl variable that variable is overwritten. It is not possible
to overwrite a Tcl command in this way.
The scope of the object can be controlled by the optional level argument (interpreted in the
same way as with the standard Tcl commands upvar and uplevel), e.g. a value of 1 will
move the object to the scope of the caller of the procedure in which move is called.
When TTS objects are created their names are auto-generated. These names will be
unpredictable and cumbersome. It will often be convenient to use move to control the name of a
TTS object, as in this example:
[temip::data type Unsigned32] move MyNumber

Here the command in [] creates the object and returns it auto generated name. This name is then
used as a Tcl command and its subcommand move is used to rename it.
The new data object can now be manipulated using the name that was assigned:
MyNumber encode 123
Or
set MyNumber 123
The following TTS PM command-response dialog show a number of examples of the use of the
move subcommand :
Create the data object in the Tcl namespace NS.
TTS> [temip::data type Unsigned32] move NS::
::NS::_Data_00000001
The data objects are array elements.

TTS> [temip::data type Unsigned64] move MyArray(first)
::MyArray(first)
TTS> [temip::data type Unsigned32] move MyArray(second)
::MyArray(second)
Assign a value to a data object.

TTS> set ::MyArray(second) 12345678
12345678
Show all data objects and data values in array.

TTS> array get MyArray
first 0x0000000000000000 second 12345678
Define procedure that creates a data object in the scope of the caller.
TTS> proc GetIntObj {name} {
[temip::data type Unsigned32] move $name 1
}
Call procedure to create new Unsigned32 data object in current scope.

TTS> GetIntObj myInt
::myInt
TTS> myInt show type
Unsigned32
And this continued TTS PM command-response dialog shows further use of the object
subcommands and the object used as a variable:
Create data object and assign its name to variable “int32”
TTS> set int32 [temip::data type Unsigned32]
::_Data_00000004
Set value in data object. Returns name of object

TTS> $int32 encode 76543
::_Data_00000004
Set value in data object. Returns value set

TTS> set $int32 9876
9876
Return value type of data object

TTS> $int32 show type
Unsigned32
Assign variable the value of data object using “decode”

TTS> set a [$int32 decode]
12345678
Assign variable the value of data object using double reference (variable holds the name of data
object variable):

TTS> eval set a $$int32
12345678
TTS> set a [set $int32]
12345678
TTS> set a [set [set int32]]
12345678

6.3 Data Types and Formats
Some TTS commands accept values for TTS data objects in the form of strings or Tcl lists and
encode them to the representation that is used internally by TeMIP. Other commands retrieve
values from data objects and return them in decoded form as results for further processing or
display. The formats that are accepted for encoding and those resulting from decoding are
generally the same or quite similar, and in the case of numeric or string data also quite similar to
the formats that are used on other TeMIP interfaces, such as (FCL) command line input and
output. All data representations are easily manipulated with standard Tcl commands.
TTS supports all commonly used TeMIP data types. The basic reference description of TeMIP
data types is found in chapter 11 of the TeMIP System Reference Manual (SYSREF in the
following). Consult SYSREF if more detailed information is needed about the data types
described below.
Table 1 list all the supported TeMIP data types in the same grouping and order in which they
occur in SYSREF and describes the formats that are accepted as arguments for encoding and
returned as results from decoding.
Types described in SYSREF but currently not supported by TTS include: Phase 4 Address, Bit
Set, Phase 4 Name, Subrange, Time24, Transport Selector, Set, Variant Record, MCC Reply,
Operating System Error, String Set.
The names in the Type column of Table 1 are those used in TTS commands. It is generally
obvious how they relate to the names used in SYSREF and the symbol names used in Visual
TeMIP. The value in the Code column is the numeric code used to represent the type in the
TeMIP dictionary.
The third column describes the format of values that are accepted as arguments for encoding.
Note the specific meaning of some terms used in this column:
• Encodeable value: a properly formatted value as defined by the appropriate entry in this
same column
• list: Tcl list
• pair: a list of exactly two elements
The fourth column describes the formats of decoded values. In general these are very similar to
the formats described in the second column; in many cases it is indicated by ‘Same’ that the
same description applies. A decoded value can generally be re-encoded, i.e. passed as argument
to an encode function.
A number of TTS commands take an optional argument –decode. This argument always
requests that the command must return as its result a data value in decoded form. It may
optionally be followed by an additional argument which may take two values: -names (default)
or –codes, specifying, where the choice applies, whether to extract the display name or the
numeric code from the TeMIP dictionary. If there is no association to a TeMIP dictionary node
to allow the name to be looked up the code will always be returned regardless of whether this is
specified by argument.
Table 1, Data Values by Type
Type Code Encodeable values (input/source) Decoded value (output)
Numeric types
Boolean 1 Valid Tcl boolean value. 0 / False or 1 / True
Enumeration 10 Code or name. Name can only be used if Same
data object is associated with a dictionary
node.
FloatF 63 Valid Tcl float value. Float value in Tcl format
containing . and/or e.
Integer8 29 Valid Tcl integer value. Signed or unsigned integer
Integer16 30
Integer32 31 For Integer8, Integer16, Integer32 the value

Integer64 32 may be wrapped and/or sign
extended/truncated.
Unsigned8 33
Unsigned16 34
Unsigned32 35 Note: the maximum value for Unsigned64 Unsigned64 is always decoded to
Unsigned64 36 cannot be assigned using a positive decimal hexadecimal representation.
number.
Counter16 37 Valid Tcl integer value. Unsigned integer
Counter32 38
Counter64 40
MCCError 44 Valid Tcl integer value. Message text (-names) or
Error codes are defined in the include file integer value (-codes).
mcc_msg.h (MCC_S_*).
Real 72 Valid Tcl real value. Real value in Tcl format
containing . and/or e.
String types
Attrib 83 List of two elements: an EntityClass Same
Identifier encodeable value and name or code of an
attribute belonging to the class.
BinAbsTime 47 Date with six formats accepted: TeMIP time out format according
1. TeMIP format according to environment to environment variables
variable MCC_TIME_IN_MODE, by MCC_TIME_OUT_MODE and
default: MCC_TIME_ABS_TRUNC, by
default:
CCYY-MM-DD-hh:mm:ss.ffff
CCYY-MM-DD-hh:mm:ss
or a subpart of this format. The encoding is
using the current time zone as set in or
::env(TZ) Infinity (literally).
2.Relative time to now The decoding is using the current

(sign must be included): time zone as set in ::env(TZ)
[+|-]hh:mmIsss.fff
3. UNIX time, a positive integer denoting

seconds since 1 Jan 1970.
4. Now (literally), denoting the time the

value is encoded
5. Infinity (literally).
6. A reference (&) to a BinAbsTime or

BinRelTime data object.
The date is following the Gregorian calendar

standard with the initial value of
1582-10-15-00:00:00.000
BinRelTime 49 Relative time with three formats accepted: [+|-]dddd-hh:mm:ss.fffIss.fff
1. [+|-]dddd-hh:mm:ss.fffIss.fff
2. The MCC_TIME_IN_MODE format for

BinAbsTime as listed above, meaning the
difference from Now to the specified time

3. A reference (&) to a BinAbsTime or
BinRelTime data object.
Dictionary 61 String of characters restricted to Same
Spec alphanumeric and the following characters:
-$_.[]<>\/*%?
EntityClass 60 List of class names or codes, starting with Same
global entity class.
FullEntity 55 List of elements, one for each level of Same,
containment to reach the entity, starting with the instance identifiers are those
global entity. Each element is a list of one or present in the encoded value.
two elements: the class name or code and the
instance identifier. The instance identifier is
omitted if the class does not have any
instances; otherwise it must be a valid value
for an identifier attribute of the class. It may
be wild-carded, partially or fully.
If the environment variable TTS_FCL is set,
FCL entity format is also supported.
Note: TeMIP synonyms are currently not
supported.
LocalEntity 56 Same form as FullEntity. Same
FileSpec 6 String of characters restricted to Same
alphanumeric and the following characters:
-$_.[]<>\/*%?:;
FullName 5 Optional prefix consisting of TeMIP Same,
namespace followed by :. followed by a namespace is always included.
sequence of simple names separated by dots.
HexString 46 %X or %x followed by a string of Same (X and A-F in upper case)
hexadecimal digits.
InternetName 74 Sequence of labels separated by dots; a label Same
consists of alphanumeric and dashes.
IPAddress 73 List of four single byte unsigned integers Same,
(0..255) or string consisting of four single -codes: list representation.
byte unsigned integers separated by dots.
Latin1String 3 Any string of ISO Latin 1 characters 8. Same
Octet 45 Single byte unsigned integer (0..255). Same
OctetString 2 %X or %x followed by an even number of Same (X and A-F in upper case)
hexadecimal digits.
Expression 26 Any character string enclosed in Same
parentheses. The string is intended to
represent a boolean expression consisting of
attributes, values and logical operators, but
this is not enforced by TTS.
SimpleName 4 String restricted to contain alphanumeric and Same
certain punctuation characters which must
then appear between quotes, e.g. “a+b”.
Version 9 List of four elements: <level> <maj> <min> Same,
<eco> or string: <level> -codes: list representation.
<maj>.<min>.<eco>. <maj>, <min> and
<eco> may be omitted and default to zero.
UID 8 List of 16 single byte unsigned integers -names:
(0..255). list of four values: time, version,
clock, node id
8
Unicode character are also supported by TTS, using the \u construct.

-codes:
list of 16 single byte values
Constructor
types
Range 54 Pair of encodeable values of the base type, Same
defining the lower and upper bound of the
range.
Record 13 List of (fieldId, fieldValue) pairs, where List of (fieldId, fieldValue) pairs,
fieldId may be name or code, and fieldValue where fieldId is name or code,
is an encodeable value of the type specified and fieldValue is the decoded
for the field. value of the field.
Sequence 15 List of encodeable values of types specified List of decoded element values.
for the elements.
SequenceOf 53 List of encodeable values of the sequence List of decoded element values.
element type.
SetOf 52 List of encodeable values of the set element List of decoded element values.
type.
Constructed
Data Types
AttribList 66 List of (attrId, attrValue) pairs, where attrId List of (attrId, attrValue, reason )
is name or code of an attribute and attrValue triplets, where attrId is name or
is an encodeable value of the type of the code of an attribute, attrValue is
attribute. the decoded value of the attribute,
Note: the decoded form with triplets and reason is its reason code (see
including reason code is also acceptable. Table 3).
AttribIdList 67 Lists of attribute ids, where each id is the Same
name or code of the attribute.
EventIDList 81 Lists of event ids, where each id is the name Same
or code of the event.
EventReport 80 A pair whose first element is event id (name A pair whose first element is
or code) and whose second element is a list event id (name or code) and
of (argId, argValue) pairs, where argId is whose second element is a list of
name or code of an event argument and (argId, argValue, reason) triplets,
argValue is an encodeable value of the type where argId is name or code of an
of the argument. event argument, argValue is the
Note: the decoded form with triplets decoded value of the argument,
including reason code is also acceptable. and reason is its reason code. See
Table 3 for names and codes of
reasons.
Attrib 82 A pair whose first element is an encodeable A pair whose first element is the
value of type AttribIdentifier (described in decoded value of an
string type group above) and the second AttribIdentifier and the second
element is an encodeable value of the type of element is the decoded value of
the attribute. the attribute.
MCCMessage 75 Non A list of 3 elements:
0. Entity of originator
1. OID of originator
2. Reply
The Reply is a list of:
0. Response status
1. Reply text
2. Reply argument list
Each argument in the list is a pair
of argument name and value.

Examples of Encodeable data values
The values shown in the following list are all valid constants for each of the TeMIP data types.
A data value may be constructed using any Tcl string and list functions.
Example of a FullEntity value construction:
TTS> set GlobalClass company
TTS> set GlobalInstance "my small business"
9
TTS> set Entity [list [list $GlobalClass $GlobalInstance]]
{company {my small business}}
Note that a constant value used as a command argument must be enclosed in “” or {} to separate
if from other arguments. The value itself is the string within the delimiters.
Value: {company {my small business}}
Argument: "{company {my small business}}"
or {{company {my small business}}}
Table 2, Data value constants
Type Example of constant value
BinAbsTime 2004-09-14-16:55
BinRelTime +13-19:24:52.333
EntityClass company employee
FullEntity {company mermaid_ns:.hp} {employee hgo}
Range -5 27
Record {checksum 4037} {number_blocks 1298} {last_update 05:08:04}
Sequence 193.143.145.27 {Remote host} 2004-09-15-05:08:04 V5.0.0
SequenceOf Major Critical Warning
AttribIdentifier {MCC APPLICATION} {Trace File}
Attrib {{MCC APPLICATION} {Trace File}} /tmp/log
AttribIdList 1 {Application Type} 10 11 Filename
AttribList {Filename /usr/opt/temip/tts/bin/tts_pm} {Arguments {-geo 10x20}}
EventIDList {Communications Alarm} {Equipment Alarm} 1710 {Physical Violation}
EventReport {Equipment Alarm} {

{{Event Time} 2004-09-01-12:00:00}
{{Event Type} ProcessingErrorAlarm}
{{Managed Object} {{MCC 0}}}
{{Perceived Severity} Critical}
}
A TTS record data value (r) may be converted to or from a Tcl array (a) where array index is the
field name:
array set a [tts::recordToArray $r];
set r [tts::recordFromArray [array get a]]
Or it may be used directly with a Tcl dictionary variable (d) where the key is the field name:
set d [tts::recordToDict $r]
set r [tts::recordFromDict $d]
A TTS event report data value may be converted similar to a record using the commands:
tts::eventReportToArray,
9
A common mistake is to forget the “list” command and just write:
set Entity "{$GlobalClass $GlobalInstance}"
This would result in the invalid entity value:
{company my small business}

tts::eventReportFromArray,
tts::eventReportToDict
tts::eventReportFromDict.
The report event id will be assigned to the index/key “event”.

Example (Get data from the event report in a corrective filter):
array set ea [tts::eventReportToArray $::event]
set MO $ea(Managed Object)
set eventTime $ea(Event Time)
set eventId $ea(event)
Table 3, Attribute Reasons

Name Code Description
Available 0 Successful operation
NoSuchAttribute 1 No such attribute
NotGettable 2 Cannot get attribute
NotAvailable 3 Attribute not available
NotSetValAttribute 4 Value cannot be set for this attribute
InvalidValue 5 Invalid value
AttributeNotSet 6 No value in attribute
PartATM 7 Part of failed atomic update
AccessDenied 8 Access denied
ConstraintViolation 9 Constrain violation
DuplicatedValue 10 Duplicated value
AttributeOperationFailed 255 Operation failed on attribute
AttributeUnused 999 Attribute not used / not set
UnknownReason-XXX XXX Unknown reason code XXX
6.4 Data Value Specification and Representation
6.4.1 Data Value Arguments

Many of the commands require data value specifications as arguments or parts of arguments.
A data value can be specified in three ways:
• As an encodeable data value (Tcl list or text) as described in section 6.3, in the third
column of Table 1. The value can be used as TeMIP data value, but does not itself include
any data type information, only the value.
Example: {{mcc 0} {appl *}}

• As the encoded value of a TTS data object referenced by the name of the data object pre-
pended by the & (ampersand) character. A data value specified in this way has a TeMIP
data type and may be associated with a dictionary node. Depending on the context, this
information may be applied in the processing of the value.
Example: &myDataObject
• As the decoded value of a data object, denoted in the standard Tcl manner by the name of
the object (considered as a variable) prepended by the $ (dollar) character.
Example: $myDataObject
For complex objects the use of the second form represents an optimization over the third form
when used as arguments to TTS commands.

6.4.2 Data Value Results (returnDataSpec)
Many TTS commands, which return a data value as result, takes arguments to specify the
representation of the value to be returned. These arguments are generally described in command
line syntax specifications by the metasymbol returnDataSpec, which may represent one of
the 3 forms below, or nothing:
-decode ?-names | -codes?
-object ?objName?
-available
When –decode is specified in a TTS command, the data value is returned in decoded form (per
the fourth column of Table 1 in section 6.3). This is also the default when returnDataSpec
is omitted. Where applicable, if –names is specified (this is the default) components of the
value will be represented by their dictionary display names, if –codes is specified they will be
represented by the dictionary numeric codes, which will generally speed up processing by 10-
15%. Some special interpretations of –names and –codes are explicitly listed in Table 1.
When –object is specified, the data value is returned as a TTS data object. If objName is
present, it must be the name of an existing data object whose type agrees with the value of the
data value; the value is then assigned to this object. Otherwise a new data object is created to
hold the value, and its name is returned.
When –available is specified, the command returns 1 (true) if data is available and 0 (false)
if not. No actual data is returned.
Example (Return attribute value as reference to data object):
set attributeObj [callObj get attribute "my attribute" –object]
Example (Check if attribute exists in reply):

if [callObj get attribute "my attribute" –available] {puts exists}
6.5 High Level Commands

The high level commands are Tcl procedures written using the TTS low level commands. They
are automatically loaded into the interpreter when they are called first time.
This section does not provide information about the special temip high level command,
intended to be used for interactive testing; see Appendix A.
TeMIP errors or exceptions which occur during processing of the directive calls implied by calls
to the high level commands are returned as part of the results. Tcl errors will occur only if there
is an internal error in the Tcl procedure which implements the high level command or in the
arguments.
All of the commands described below are synchronous and return when the complete result has
been collected.
The first four commands make TeMIP directive calls of the four verb types: examine, modify,
action and event, respectively. These commands may use wild-carded entity specifications, and
multiple TeMIP replies may be returned in the result, each one for a single specific entity. The
result generally includes all the information returned from the TeMIP call.
The last four commands are less general, they serve to show and set attributes only.
temip::examine verb entity partition ?form?
calls a TeMIP directive of type examine. The arguments are as follows:
verb is the name or code of the directive.
entity specifies the entity on which the call is to be made; it is a data value
of type FullEntity (see section 6.4).
partition is the name or code of the attribute partition; the command cannot
be applied across multiple partitions.

form is –codes or –names, specifying whether the result shall be
shown using codes or names of items defined in the dictionary (see
section 6.3).
The same form of reply is used for all the four directive call commands. It is a list of single
entity replies. If the call is not wild-carded, there is normally only a single reply, hence only a
single element in the list. A single entity reply is again a list, of two elements: response status
and argument list. The response status is again a list, of four elements:
1. entity as decoded value of type FullEntity (see section 6.3).
2. reply status: Response, CommonException or SpecializedException.
3. a list of two elements: response name and textual description of response or exception.
4. response timestamp.
The argument list is a list of argument or attribute (name, value) pairs. The examine and
modify commands return attributes, the action and event commands return reply
arguments. In the case of an exception response the list will contain exception arguments.
Attribute and argument values are given in the form of decoded values of their respective types
(see section 6.3). When an attribute has a reason (see Table 3 in section 6.3) different from
Available, the value is a pair of dashes followed by the reason.
The complex list structure of the directive call result can be summarized as follows, where white
space separates list elements:
<<<entity reply-status <response-name response-text> timestamp> argument-list>...>
response status
single entity reply
Example, saving result of Show call in variable r:

TTS> set r [temip::examine show "{MCC 0} {appl tts_pm}" ident]
{{{{MCC host_ns:.temip.host_director} {APPLICATION tts_pm}} Response {{Show

Success} {Examination of Attributes Shows:}} 2002-11-08-10:59:52}
{{Application Id} {-- AttributeUnused}} {{Application Name} tts_pm}}
This result contains at the outer level of a list of a single element, as there is only one entity. To
pick out the list of attribute values, use the standard Tcl lindex command to extract first this
single element (index 0), then its second element (index 1) to skip the response status:
TTS> lindex $r 0 1
{{Application Id} {-- AttributeUnused}} {{Application Name} tts_pm}
temip::modify verb entity partition ?attr-spec ...?

calls a directive which must be of type modify. The arguments are as follows:
of type FullEntity (see section 6.4.1); it must not be wild-
carded.
partition is the name or code of the attribute partition.
attr-spec specifies the value to be set for one attribute; it is a (name, value)
pair, i.e. a list of two elements, where the first element is the name
or code of the attribute, and the second element is a data value of the
type of the attribute (see section 6.4.1). Additional values, including
a reason code, are ignored.
The result has the same form as for temip::examine (described above). Since there is only a
single reply the list will have only a single element.
Example (Set attribute):

temip::modify set {{company hp}} Reference {{Responsible Person} {Not me!}}
temip::action verb entity ?arg-spec ...?

calls a directive which must be of type action. The arguments are as follows:
of type FullEntity (see section 6.4.1).
arg-spec specifies an argument value; it is a (name, value) pair, i.e. a list of
two elements, where the first element is the name or code of the
argument, and the second element is a data value of the type of the
argument (see section 6.4.1). Additional values, including a reason
code, are ignored.
The result has the same form as for temip::examine (described above).
Example (Create a new alarm object (2) in an OC (oc1) clearing an existing alarm object (1)):
temip::action create {{oper oc1} {alarm 2}} {ref {{oper oc1}
{alarm 1}}} {perceived clear}
temip::getevent entity partition ?duration? ?arg-spec ...?

calls the GetEvent directive. The arguments are as follows:
partition is the name or code of the event partition.
duration must be present if arguments follow. It specifies the duration of the
call and is a data value of type BinAbsTime or BinRelTime
(see section 6.4.1). The default is to wait for first event.
arg-spec specifies an argument value; it is a (name, value) pair, i.e. a list of
two elements, where the first element is the name or code of the
argument, and the second element is a data value of the type of the
argument (see section 6.4.1). Additional values, including a reason
code, are ignored.
The result has the same form as for temip::examine (described above).
Eaxmple (Wait for a notification event (for max. 45 seconds)):
temip::getevent {{company hp}} notification +00:00:45
temip::expand entity ?form? ?useDirectory? ?parents?

retrieves all entities matching a specification which will typically be wild carded. The arguments
are as follows:
entity specifies the (wild-carded) entity to be retrieved; it is a data value of
type FullEntity (see section 6.4.1).
form is –codes or –names (default), specifying whether the result
shall be shown using codes or names of items defined in the
dictionary (see section 6.3).
useDirectory must be a Tcl boolean value; if true (default), it causes the
command to look for global entities registered with TeMIP using the
Directory directive. Otherwise global entities are looked up using
Show. When supported by the management module in question this
can be used to look up unregistered global entities, which is not
possible with TeMIP “manage”.
parents must be a Tcl boolean value; if true, all parent entities are also
included in list. If false (default) then only the child entities are
returned.

Any errors returned from TeMIP calls made by the command are ignored. Only valid, existing
entities are returned. The result takes the form of a list of decoded values of type FullEntity (see
section 6.3).
Example (Get list of all alarm object entities on the system)
temip::expand {{oper *} {alarm *}} -names true false
Example (Print status attributes of all alarms from oc1)

foreach alarm [temip::expand {{oper oc1} {alarm *}}] {
puts [temip::examine show $alarm status]
}
temip::getattr entity ?form? ?attr-id...?

retrieves values for the specified attributes on the specified entity/entities (wildcarding may be
used). The arguments are as follows:
entity specifies the (possibly wild carded) entity on which the call is to be
made; it is a data value of type FullEntity (see section 6.4.1).
form is –codes or –names, specifying whether the result shall be
shown using codes or names of items defined in the dictionary (see
section 6.3).
attr-id is the name or code of an attribute on the specified entity. Multiple
attributes can be listed and need not belong to the same partition.
Any errors returned from TeMIP calls made by the command are ignored. Only values of
available attributes on existing entities are returned.
The result takes the form of a list of triplets, one for each valid attribute value retrieved. If there
are none, the result list will be empty. Each triplet is a list of three elements:
5. entity as decoded value of type FullEntity (see section 6.3).
6. attribute id as name or code.
7. decoded attribute value.
It is not guaranteed that the triplets are ordered by entity or attribute.
Example (Get all file and application names):
TTS> temip::getattr {{mcc 0} {appl *}} -names filename {application name}
{{{MCC rap_ns:.temip.rap_director} {APPLICATION osi_system_am}}
{Application Name} osi_system_am} {{{MCC rap_ns:.temip.rap_director}
{APPLICATION hds_fm}} Filename /usr/opt/temip/mmexe/temip_hds_fm} ……
Example (Save file names in array indexed by application names):

foreach entry [temip::getattr {{mcc 0} {appl *}} -names filename] {
set attr([lindex $entry 0 1 1]) [lindex $entry 2]
}
temip::setattr entity ?attr-spec ...?

sets values for specified attributes on the specified entity. This command does not support
wildcarding. The arguments are as follows:
attr-spec specifies the value to be set for one attribute; it is a (name, value)
pair, i.e. a list of two elements, where the first element is the name
or code of the attribute, and the second element is a data value of the
type of the attribute (see section 6.4.1). Multiple attributes can be set
and do not need to belong to the same partition.
The result returned by the setattr command is a list of updated attributes. Attributes which
are not updated, whatever the reason, are not returned. The list element for each attribute is a
(name, value) pair.
Example (Set the values of the 3 attributes for entity):

temip::setattr $entity {Name NoBody} {Address Here} "Town $city"
temip::show entity attr-id

returns as result the value of a single attribute as specified by the argument. If the attribute is not
available an empty value is returned. Other errors are returned as Tcl errors. The entity
cannot be wild-carded.
Example (Get the value of the Name attribute from entity)
temip::show $entity Name
temip::set entity attr-id value

sets the value of the specified attribute to value, which must be a data value of the type of the
attribute. The value is also returned as result. Errors are returned as Tcl errors.
Example (Set the value of the Name attribute for entity)
temip::set $entity Name AnyBody
6.6 Trace Command

The temip::trace command enables a TTS script to produce TeMIP traces using the
standard TeMIP trace mask and trace file name which are available as attributes on the
application process entity.
Producing a trace means building a trace line and writing it in up to three places:
• on the standard output of the module, if available; this will be the case if the module
was started by explicit command from a UNIX shell running in a terminal window.
• appended to the current TeMIP trace file, as defined by the trace file name attribute.
• appended to the current TTS trace variable.
The trace file and/or trace variable may be undefined, in which case no appending takes place.
The trace header will include a timestamp (in BinAbsTime format), the process id and the thread
id or name.
Note
Traces created by corrective filter scripts are written to the trace file of the AM emitting the
filtered event.
temip::trace file ?file?

sets the trace file name of the application process entity to file, if it is present, then returns as
result its current value. This is a system configuration action and would normally only be done
from TTS PM. The file name can only be set for current process if not already set. If the trace
file name needs to be changed, set the attribute “trace file” on the” MCC APPLICATION
PROCESS” class instead.
Example (Set local trace file):
temip::trace file /tmp/debugging.log
Eaxmple (Set trace file on process instance via TeMIP call)

temip::set "{mcc 0} {appl myApplication} {proc [pid]}" {trace file} \
/tmp/debugging.log
temip::trace mask ?mask?

sets the trace mask of the application process entity to the value of mask, if it is present, then
returns as result its current value (before setting the new value). This is a system configuration
action and would normally only be done from TTS PM.
The mask value is specified as a Tcl integer/octet/hex value (64 bits), e.g.
0x0ff0a034000ff000. The returned value is always an integer.
Example (Set trace mask):

temip::trace mask 0x0ff0a034000ff000
temip::trace kernel ?mask?

same as for the mask subcommand, except that it sets the kernel (TeMIP framework) trace mask
instead. This may be used for low-level debugging.
Example (Set kernel trace mask):
temip::trace kernel 0xff
temip::trace trace mask ?text?

produces a trace line if mask is 0 or has at least one bit set which matches the trace mask of the
application process entity. The trace line will consist of the text, preceded by the standard
TeMIP trace header and optionally a prefix specified by means of the prefix subcommand.
If text is not specified, no trace line is produced.
The command returns 1 (true) if tracing is enabled by the specified mask, 0 (false) otherwise.
Example (Trace unconditionally):
TTS> temip::trace trace 0 "test of trace"
2008-11-24-15:32:22.152[5821][Master] test of trace
Here the trace line shows the timestamp, the process id (5821) and the thread name
(Master), followed by the trace text “test of trace”
Example (Check that trace is on):
If [temip::trace trace 0x5] {
# Bit 1 or 3 (or both) is set in trace mask
…
}
temip::trace prefix ?command?

specifies the command thet is called when the trace subcommand is executed, to produce a
prefix for each trace line to be written. If no command is present, prefixing is switched off.
The following use of the standard Tcl info command will produce a prefix containing the name
of the Tcl procedure and arguments within which a trace is produced.
temip::trace prefix {info level 0}
Example (Use formatted trace prefix):

TTS> temip::trace prefix {format "%10s: " [info level 0]}
TTS>
TTS> proc traceTest {a} {
temip::trace trace 0 {My Trace}
}
TTS>
TTS> traceTest [expr 25+2]
2009-05-04-09:36:01.530[21271][Master] traceTest 27: My Trace
temip::trace open ?mask?

opens and returns as result a standard Tcl channel which can be used to write traces to the trace
file. Writing of a trace line takes place when the channel is flushed or closed. This makes it e.g.
possible to write partial trace lines, without inserting a trace line header for each part.
Writing to the channel has effect only if mask is 0 (default) or has at least one bit set which
matches the trace mask of the application process entity at the time of the write.
Example (Use puts command to write to trace):
set t [temip::trace open 0x0047]
puts $t {test trace text } nonewline
puts $t {will continue on same line}
…
chan flush $t
…
chan close $t

Note
Multiple channels can be open simultaneously allowing a channel per trace mask.
temip::trace variable ?varName?

sets the name of the current TTS trace variable to varName. If varName is not present, tracing
to a variable is switched off.
The command returns as result the name of the trace variable which was in effect prior to the
call.
Normal tracing is not impacted by this command. The trace is done to the variable in addition to
the trace to the log.
Errors which occur while writing to the trace variable are ignored.
The Tcl trace command can be used in conjunction with the TTS trace variable to monitor
traces and implement further functionality triggered by enabling standard Tcl tracing on the
variable.
Example (Print “Tracing” on stdout, each time a TeMIP trace is produced):
TTS> proc traceHelp {args} {
puts Tracing
}
TTS> trace add variable tracevar write traceHelp
TTS>
TTS> temip::trace trace 0 test
Tracing
temip::trace mtlog text ?component? ?severity? ?category? ?code?

forwards a log message to the SystemMate Monitoring Logs (see TeMIP System Administration
Console User’s Guide) for the director on which the application runs. The arguments are the
components of the log message. Their values are as follows:
text any text to be shown as main part of message.
component any text (defaults to “TTS”).
severity one of: Critical, Major, Minor, Warning (default) or
Clear.
category one of: Errors, QoS, AccessViolation or Information
(default).
code integer (defaults to 1).
6.7 Dictionary Information and OIDs

The TeMIP dictionary has a tree structure, the first level below the root being nodes
corresponding to the global entity classes, and subsequent levels reflecting the containment
hierarchy of child classes. Every class node - whether or not it has child classes - has child nodes
corresponding to the attributes, attribute partitions, attribute groups, events, event partitions,
event groups and directives of the class, and some of these have further child nodes
corresponding to arguments, responses and exceptions.
The entire dictionary on a TeMIP system can be inspected using the TTS instance and model
browser GUI (tts_mb) which can expand the desired part of the tree and for every node show
the definitions which are directly contained within the node.
Every node has a numeric code, a symbol and a name (a string known as the display name)
which are unique among nodes within the same parent, for example all attributes of a class have
a unique attribute code. (For definition of new classes beware that there are some stronger
naming uniqueness rules). In general any item associated with a dictionary node can be
identified in TTS commands either by code, symbol or name. Abbreviated names are accepted,
provided enough characters are provided to uniquely distinguish the referenced item in the
relevant context, for example among attributes or directives of a given class. Dictionary names

are case insensitive. A Symbol may be used, if available in the dictionary, by specifying
+symbol+ in any place where the code can be used.
Example: Representations for a directive of a class.
Code is: 1
Symbol is: +VERB_SHOW+
Name is: Show
The key which uniquely identifies each dictionary node is its OID. An OID is a sequence of
numeric codes separated by dots. All TeMIP OIDs include two subsequences, the prefix and the
class-sequence. The prefix, which is always 1.3.12.2.1011.2.22, positions the world of TeMIP
systems within a standardized universe of management objects identified by OIDs. The class
sequence is the sequence of codes for the classes encountered from the root of the dictionary to
the node in question. Between the prefix and the class sequence is a type code which identifies
the type of the target node. For nodes other than class nodes, i.e. below the class node sub-tree,
the OID ends with a tail, which begins with 126 and continues with the sequence of codes for
the nodes encountered from the class node to the target node. To summarize, the general OID
format is:
Prefix.TypeCode.ClassSequence.Tail
where the type codes and tails are as shown in Table 4:
Table 4, OIDs by Dictionary Node Type
Node type Type Tail
code
Class 1 not present
Attribute 2 126.attribute code
AttributePartition 11 126.attribute partition code
AttributeGroup 12 126.attribute group code
Event 9 126.event code
EventArg 10 126.event code.argument code
EventPartition 2020202 126.event partition code
EventGroup 27 126.event group code
Directive 3 126.directive code
DirectiveRequestArg 4 126.directive code.request argument code
DirectiveResponse 5 126.directive code.response code
DirectiveResponseArg 6 126.directive code.response code.argument code
DirectiveException 7 126.directive code.exception code
DirectiveExceptionArg 8 126.directive code.exception code.argument code
The names of dictionary node types as shown in the left hand column are those used with the
TTS dictionary command (see next section).
6.8 Dictionary Command and Object

Access to the TeMIP dictionary is provided by the TTS dictionary command (temip::dict).
It has two subcommands to control how to handle the situation when the TeMIP dictionary is
updated while the application is running and other subcommands which create and delete
dictionary objects, which are themselves commands (see section 6.2 for a description of general
properties of TTS objects). Most of the functions to navigate within the dictionary and extract
information from the dictionary are subcommands on dictionary objects. The subcommands of
temip::dict are described first; the subcommands of the dictionary object command follow.
In these descriptions dictObj stands for the name of a dictionary object.
Every dictionary object has an OID value whereby it is associated with a node in the dictionary.
See section 6.7 for an explanation of OIDs.

Note
The value of a TTS dictionary object considered as a Tcl variable is the OID.
temip::dict reload ?control?

controls how TTS handles its local dictionary copy when the TeMIP dictionary is updated using
the reloaddictionary directive on the MCC class.
The command sets the new reload action and returns the previous setting.
The control parameter can take one of three values:
on Reload the internal dictionary when TeMIP reloads the global
dictionary.
off Do not reload the internal dictionary (default).
exit Exit when the global dictionary is reloaded.
The result returned is the value which was in effect prior to the call.
temip::dict onreload ?command?
specifies that command shall be executed as the event handler for the dictionary reload event,
provided the reload control is on (see above) and TTS accepts events (see section 2.3.4). If
command is not present, no event handler command will be called.
The result returned is the value which was in effect prior to the call.
Example (Notify when model is updated):
TTS> proc modelUpdate {} {puts "Model updated"}
TTS> temip::dict onreload modelUpdate
TTS> temip::dict reload on
TTS> temip reloaddictionary {{mcc 0}}

RELOADDICTIONARY Null @ 2009-05-04-10:17:31.387 on
rap_ns:.temip.rap_director
Response @ 2009-05-04-10:17:31.834 from {{MCC rap_ns:.temip.rap_director}}
ReloadDictionary Success :: Dictionary reload in Framework_am successful
TTS> update; # Execute background Tcl events
Model updated
temip::dict deleteall
See section 6.2.
temip::dict oid ?oidVal?
creates a dictionary object associated with the dictionary node identified by oidVal interpreted
as an OID (see section 6.7). If no value is present, the object is associated with the root node of
the dictionary as if the value had been the OID of this node: 1.3.12.2.1011.2.1.
It is not checked if the specified OID is valid. That can be done using the check subcommand
of the dictionary object.
The name of the new dictionary object is returned as result.
Example (Create dict object referencing a specific oid):
TTS> temip::dict oid 1.3.12.2.1011.2.22.1.7
::_Dict_00000000
temip::dict class ?classSpec?

creates a dictionary object associated with the dictionary node for the entity class specified by
classSpec, which must be a data value of one of the types EntityClass, LocalEntity
or FullEntity. In the latter cases, the specified class is the class of the named entity.
The name of the new dictionary object is returned as result.

This subcommand makes it possible to associate an object with a node in the dictionary without
knowing any OID to start with. The object can then navigate the tree using dictionary object
subcommands children, up and down.
Example (Create dict object referencing a specific class):
TTS> temip::dict class {{mcc}}
::_Dict_00000001
dictObj delete
See section 6.2.
dictObj children type
retrieves a list of the nodes which are children of the node associated with the dictionary object
and whose type agrees with the value of type (see Table 4).
Each element in the returned list is itself a list of three elements: the code, the display name and
the OID of the child node.
Example (Get list of child classes):
TTS> ::_Dict_00000001 children Class
{202 APPLICATION 1.3.12.2.1011.2.22.1.7.202} ……
dictObj down type id ...

moves the association of the dictionary object down one level in the dictionary tree to the node
whose type is type and whose code or name is id. The two arguments type and id can be
repeated to move the association down by multiple levels.
If the node (id) is specified by code, it is not checked that the object exists in the dictionary.
Example (Let dict object reference a child class):
TTS> ::_Dict_00000001 down Class APPLICATION
dictObj up
moves the association of the dictionary object up one level in the dictionary tree.
dictObj check
checks that the dictionary object has a valid association to a dictionary node as defined by its
OID and returns 1 (true) if this is the case, otherwise 0 (false).
dictObj type
returns as result the type of the dictionary node associated with the dictionary object (see Table
4).
dictObj oid ?oidVal?
returns as result the OID value of the dictionary object (same as the value of the object
considered as a Tcl variable), and, if oidVal is present, sets it as the new value. Setting the
OID redefines the association of the object with a dictionary node. It is not checked that the OID
is valid.
Example (Get referenced oid):
TTS> ::_Dict_00000001 oid
1.3.12.2.1011.2.22.1.7.202
dictObj definitions ?index?

retrieves a list of definitions contained within the dictionary node associated with the dictionary
object, where the values of the definitions are decoded in accordance with the type of each item.
The contents of the list depend on the node type as shown below:
Table 5, Dictionary Definitions
Node type Items in definitions list
Class Code, Name, Symbol, IsDynamic, IsRequired
Attribute Code, Name, Symbol, IsDisplayed, DataType,

DefaultAllowed, DefaultValue, Units, Predictable,
AccessMode, Partition, Categories, IdentifierProperty
EventArg Code, Name, Symbol, IsDisplayed, DataType,
DirectiveRequestArg DefaultAllowed, DefaultValue, Units, IsEchoed,
DirectiveResponseArg IsRequired
DirectiveExceptionArg
AttributePartition Code, Name, Symbol, Access Mode, MemberOIDs
EventPartition
AttributeGroup Code, Name, Symbol, Categories, MemberOIDs
EventGroup
Event Code, Name, Symbol, IsDisplayed, ReplyText, PartitionId,
Categories
Directive Code, Name, Symbol, IsDisplayed, DirectiveType,
Categories
DirectiveResponse Code, Name, Symbol, ReplyText
DirectiveException
If index is specified, it must be the name of one of the definition items as mentioned in Table
5. In this case only the indicated item is returned.
Example (Get definitions for referenced object):
TTS> ::_Dict_00000001 definitions
202 APPLICATION CLASS_APPLICATION Dynamic Required
TTS> ::_Dict_00000001 def Symbol
CLASS_APPLICATION
dictObj datatype ?code?

retrieves information describing the data type defined by the dictionary node associated with the
dictionary object. This subcommand applies only when the node is for an attribute or an
argument, as no data type is defined by nodes of other types.
Constructor data types (record, set of, sequence of) include fields or elements of subordinate
data types. Data type construction may be several level deeps. The form of result returned is a
list of a recursive form which allows constructor data types to be described.
The code argument can be used to specify a type occurring within a nested structure; then only
the list describing that type will be returned, not its nest.
The list describing a data type has five elements; the fifth element will again be a list:
8. The code of the data type; this code may be user defined (in MSL).
9. The presentation name of the data type; this may also be user defined.
10. The standard predefined code of the data type; if the type does not have a user defined
code, this is the same as the first element (0).
11. The standard predefined name of the data type in the form shown in the left hand column
of Table 1. If the type does not have a user defined name this is the same as the second
element (1).
12. For enumerations and structured types, further description of the types of its elements.
For other types this element is empty. The form depends on the type as follows:
Enumeration List of pairs containing code and name for each
possible value of the enumeration type.
Record List of triplets, each one containing field code, field
name and description of field data type (recursive).
SetOf / SequenceOf Description of element data type (recursive).
Range Description of base data type (recursive).
Sequence List of descriptions of element data types (recursive).

Example (Get data type definition for referenced object):
TTS> ::_Dict_00000002 datatype
35 Unsigned32 35 Unsigned32 {}
dictObj private
returns as value the “private” text from the dictionary entry.
dictObj snmp
returns the SNMP OID, if defined, from the dictionary entry.
dictObj cmip
returns the CMIP OID, if defined, from the dictionary entry.
dictObj sql
returns a list with two elements, if they are defined, from the dictionary entry: the SQL column
size and storage mask.
dictObj dependson
returns a list with three elements, if Depends On is defined, from the dictionary entry:
characteristic attribute name, operator and values. Values are again a list of enumeration values.
6.9 Data Command and Object

TeMIP data values can be accessed and manipulated by means of the TTS data command
(temip::data) and the TTS data objects which it can create. This section first gives some
information about data objects (see section 6.2 for a description of general properties of TTS
objects), then describes the subcommands of the temip::data command, and finally
discusses the Tcl variable properties of the data object.
6.9.1 Data object
Essential reference information about data types and the way data values are specified and
decoded is found in sections 6.3 and 6.4. A data object will contain a data value of a specific
data type from the repertoire listed in Table 1 (in section 6.3), and data values can be encoded
and decoded from and to the forms described in the same table.
A data object contains several items of information, the data value being the principal one.
Others include type, dictionary association, attribute id, reason. The latter two are automatically
set when a value is loaded from an attribute value list returned from a TeMIP call into the object.
They are also settable. See the description of the show subcommand of the data object for a list
of valid values for reason. The next paragraph explains the dictionary association.
Record types have fields and enumeration types have values, both of which have display names
defined in the TeMIP dictionary. These fields or values can be specified either by code or by
name. This is also true for attributes, arguments and events occurring in constructed data types
(see end of Table 1).
The use of display names requires an association between the data object and a dictionary node
in order to allow TTS to interpret the names (when encoding) or to look them up (when
decoding). For objects of constructed data types which are created by call and event handling
(see sections 6.10 and 6.11) the association will be established automatically. For data objects
created explicitly by the temip::data command (type and from subcommands) it can be
specified by arguments. In addition to the types mentioned previously in this paragraph
dictionary node association is important for all SetOf and SequenceOf types, when their element
types include named items.
Subcommands that apply to a data object return, when no other result is specified, the name of
the object. This allows multiple subcommands to be nested on a single command line.
Example (Create Integer32 data object, call it MyObj and set value 42 in it):
[[temip::data type Integer32] move MyObj] encode 42

6.9.2 Data object as Tcl variable
The TTS data object can in general be used as a Tcl variable whose name is the name of the data
object and whose value is only the data value of the data object; the other information items are
not impacted.
If myObj is the name of a data object, then $myObj can be used in Tcl commands to represent
its decoded data value (see section 6.3, decoding is by names), for example:
puts $myObj
This is an alternative to explicit use of the decode subcommand:

puts [myObj decode]
but cannot express

puts [myObj decode –codes]
Similarly, myObj may be used as a command argument wherever a variable name is accepted,
for example as the first argument of the Tcl set command. Such use will typically imply both
encoding and decoding of the data value to take place, for example evaluation of:
set myObj dataVal
causes dataVal to be encoded according to the type of myObj, whose newly assigned value is
then again decoded to yield the result of the set command. Unless the latter result is actually
used for a purpose, this is less efficient than:
myObj encode dataVal
When the decoded value of an object is a Tcl list it is also possible to use Tcl commands that
insert, modify or append elements to a list, as in the following examples:
TTS> [[temip::data type FullEntity] move entity] encode {{mcc 0} {appl *}}
TTS> set entity
{MCC mermaid_ns:.temip.mermaid_director} {APPLICATION *}
TTS> lset entity 1 1 tts_pm
{MCC mermaid_ns:.temip.mermaid_director} {APPLICATION tts_pm}
TTS> lset entity 1 0 NewClass
can't set "entity": unknown class NewClass
TTS> lindex $entity 0 1
mermaid_ns:.temip.mermaid_director
6.9.3 Data object Commands

In the descriptions below dataObj stands for the name of a data object.
temip::data deleteall
See section 6.2.
temip::data type typeSpec ?oidSpec? ?code?
creates a data object and returns its name as result. The type of the data object is as specified by
typeSpec which must be one of the names occurring in the left hand column of Table 1 or one
of the corresponding codes which are predefined in TeMIP. Initially the object will have a
default (unspecified, but generally intuitive) data value.
If oidSpec is present it must be an OID (see section 6.7); the new data object is then
associated with the dictionary node identified by this OID.
When an attribute or argument defined by a dictionary node is of a composite type, there is no
separate dictionary node defining the element type or field types. It is still possible to associate a
data object with one of these types by using the code argument in addition to oidSpec to
identify the element or field type within the node.
For data objects of the constructed data types AttribList, AttribIdList,
EventIdList and EventReport, the dictionary association which is effectively required is
with the entity class to which the structure belongs. The oidSpec may be the class OID; it may
be followed by any tail (see section 6.7), but the tail will not affect the behavior of the data
object.
Example:

temip::data type Integer32
To save the new object name in a variable (dataObjVar) use:

set dataObjVar [temip::data type Integer32]
and to rename it to a known name (MyObj) use:

[temip::data type Integer32] move MyObj
temip::data from oidSpec

creates a data object and returns its name as result. The data object will be associated with the
dictionary node identified by oidSpec which must be an OID (see section 6.7). The type of
this node must be one that has a data type; the new data object will have this type. Initially the
object will have a default data value.
Example:
temip::data from [$dicObjectVar oid]
temip::data info types

returns as result a list describing all TeMIP data types and whether they supported by TTS. Each
element in the list is a list of three elements: the name of a type as it appears in the left hand
column of Table 1, its code (column 2), and a boolean value which is 1 (true) if the type is
supported by TTS, otherwise 0 (false).
dataObj delete
See section 6.2.
dataObj clone
creates a new data object by making a clone of the existing object whose name is dataObj and
returns the name of the new object as result.
Example (Copy the data):
set newDataObjectVar [$dataObjVar clone]
Note that this is different from:

set newDataObjectVar $dataObjVar
as the later will just set the name of the data object into another variable.
dataObj encode dataVal
sets the value of the data object to dataVal which must be a data value (see section 6.4.1) of
the same type as the object.
Example (Set data value):
TTS> $dataObjVar encode "{MCC $temip_director}"
::_Data_00000005
This is the same as:

TTS> set $dataObjVar "{MCC $temip_director}"
{MCC rap_ns:.temip.rap_director}
except that the first form returns the name of the data object and the second form returns the
(decoded) value assigned.
dataObj decode ?form?
returns as result the decoded value (see section 6.3) of the data object. Dictionary information is
represented as codes (if form is -codes) or as display names (if form is -names or omitted).
Example (Get data value):
set value [$dataObjVar decode]
This is the same as:

eval set value $$dataObjVar

while:
set value $dataObjVar
will set the name of the object into value!

Example (Return value using codes for dictionary objects):
TTS> set codeValue [$dataObj decode -codes]
{7 rap_ns:.temip.rap_director}
Example (Convert TeMIP error code to text):

TTS> [[temip::data type MCCError] encode 52860163] decode
attribute not settable
dataObj meta ?form?

like decode, retrieves the value of the data object, but returns its decoded value adorned with
identification of the data type of every element of the value. This is applied recursively from the
entire, possibly complex, value down to its constituent parts. Each type is represented as code (if
form is -codes) or as display names (if form is -names or omitted). Each element of the
decoded value which has a data type is rendered as a list of two elements: the data type and the
value.
Example (Get meta data for managed object):
TTS> set MO {{mcc 0} {appl tts_pm}}
TTS> [[temip::data type FullEntity] encode $MO] meta
FullEntity {{MCC {FullName a_ns:.temip.a_director}} {APPLICATION
{Latin1String tts_pm}}}
dataObj convert to option

performs a data format conversion and returns the value of the data object according to the
specified conversion option. This provides a number of alternatives to the standard decoding
described in section 6.3. The supported options, the types of data they apply to, and the resulting
data representations are described in Table 6.
Table 6, Data Object Convert to Options
Option Data types Description
string all Standard TeMIP string representation of the data value.
simple all Simple representation of the data value:
FullName – With no namespace.
entity LocalEntity, Standard TeMIP string representation of the entity name
FullEntity obtained with suppression of synonym conversion.
oid LocalEntity, OID for the entity class as defined in the TeMIP dictionary
FullEntity, (see section 6.7).
EntityClass
unixtime BinAbsTime Standard UNIX representation (seconds since 01-01-1970-
00:00:00 UTC)
dump all Standard TeMIP descriptor dump (multi line text)
ilv all Standard TeMIP ILV dump (multi line text).
raw all TeMIP descriptor as a hexadecimal string.
Example (Get FullEntity data value in FCL format):

TTS> dataObj convert to entity
MCC rap_ns:.temip.rap_director APPLICATION "tts_pm"
Example (Convert date ( BinAbsTime data object) to Julian days):

clock format [dataObj convert to unixtime] -format %J

dataObj convert from option value
encodes value and assigns it as the value of the data object using data formats different from
the standard one described in section 6.3. The supported options, the types of data they apply to,
and the forms in which data can be supplied are described in Table 7.
Table 7, Data Object Convert from Options
Option Data types Accepted data format
entity LocalEntity, Standard TeMIP string representation of an entity name:
FullEntity, class instance class instance ...
EntityClass
oid EntityClass OID for the entity class as defined in the TeMIP dictionary
(see section 6.7).
unixtime BinAbsTime Standard UNIX representation (seconds since 01-01-1970-
00:00:00 UTC)
Example (Convert FullEntity from FCL format to TTS format):

TTS> [dataObj convert from entity "mcc 0 appl tts_pm"] decode
{MCC rap_ns:.temip.rap_director} {APPLICATION tts_pm}
dataObj show option ?form?

returns information held on the data object other than the data value, as specified by option.
The form argument can take the values -name (default) or -code. It can be used with some of
the options, as described below, to specify the form in which the information is given. The
supported options, and the data returned for each one, are listed in Table 8.
Table 8, Data Object Show Options
option Description
id Attribute id associated with the data.
type Data type code.
size For constructor types: number of elements.
For Entity and EntityClass types: the number of class levels.
Otherwise: length (number of bytes) of the data value string.
reason Associated reason (see Table 3) code or reason text, depending on form
specified.
association OID of associated dictionary node and data type code (if available).
datatype Description of data type in the same form as retrieved by the datatype
subcommand of a dictionary object (see section 6.8), provided the data
object is associated with a dictionary node for an attribute or argument.
wildtype For an entity name (FullEntity or LocalEntity) a list of elements
describing the wildcarding used at each level, each element being Class,
Full, Partial, Non (no wildcarding at level) or empty (no instance at
level).
For other data types an empty result is returned.
scope For an entity name (FullEntity or LocalEntity) a list of scope type
and level.
Scope type is one of:
• BaseObject
• OneLevelDown
• WholeSubTree
• SubLevel
• ToSubLevel

option Description
For other data types a empty result is returned. The scope is e.g. used by the
GetEvent directive implementation to determine the instance scope of
interest.
Example (Show wild-carding on all levels) :

TTS> [dataObj encode {{mcc 0} {appl *}}] show wildtype
Non Full
Example (Create dict object to point to data definition) :

TTS> temip::dict oid [dataObj show association]
dataObj set option setVal

sets the information value of the data object to setVal.
Table 9, Data Object Set Options
Option Description
id Attribute id associated with the data.
reason Associated reason (see Table 3) code.
scope For an entity name (FullEntity or LocalEntity) a list of scope type
and level.
Scope type is one of:
• BaseObject
• OneLevelDown
• WholeSubTree
• SubLevel
• ToSubLevel
Defaults to BaseObject if not set. The scope is e.g. used by the GetEvent
directive implementation to determine the instance scope of interest.
Example (Set scope of a managed object to be the full class tree):

TTS> dataObj set scope WholeSubTree
::dataObj
TTS> dataObj show scope
WholeSubTree 0
dataObj prune ?level?

for data objects of type EntityClass, FullEntity or LocalEntity removes the tail end
of the data value until the number of classes remaining is level, which must be an unsigned
number. If level is not present, one element is removed.
Example (Truncate managed object to global level):
TTS> dataObj encode {{mcc 0} {appl tts_pm} {proc 1234}}
TTS> dataObj prune 1
TTS> dataObj decode
{MCC rap_ns:.temip.rap_director}
dataObj clear
resets the data value of the data object to default value whilst other information items such as
dictionary node association are retained.
dataObj compare value
compares value of dataObj with value and returns one of the following:
0 the values are equal.
1 the value of dataObj is greater than the value specified (or different from if
greater/less than does not make sense).

-1 the value of dataObj is less than value.
value must be a valid TeMIP data value (see section 6.4.1). If it is not a data object reference
(beginning with &) it will be interpreted (encoded) as a value of the type of dataObj. When
value references a data object a comparison is made even in cases where the type of the value
data object is not the same as the type of dataObj.
The way the comparison is done depends on the data types of the two values:
both are numeric Numerical comparison
both are FullEntity/ LocalEntity Deeper value (more classes) is greater. For same
depth class codes are compared starting from
global class. If all class codes equal, instance
identifiers are compared starting from global
instance. If one instance identifier is wild-carded
and the other is not, they are equal if the specific
value matches the wild-carded one 10; otherwise
the wild-carded value is greater.
dataObj is time If both values are absolute or both relative, later is
greater. If one is absolute, one is relative, the latter
is taken to be relative to ‘Now’ (then the time
comparison is made).
dataObj is Range value is also Range: -1 is returned only if
value is fully inside but not equal to dataObj.
value is base type of Range: 1 if below lower
bound, 0 if inside, -1 if above upper bound.
dataObj is Boolean If the text representation of value can be
encoded as a Boolean (for example the string
“false”), this is done and Boolean comparison is
applied. Two different Boolean values yield 1,
otherwise the result is 0.
dataObj is CMISfilter If value is a reference to an EventReport, then
the OSI event in the report is applied to the
Discriminator Constructor filter (see “Filtering
OSI events” below). If the event parses the filter 0
is returned, else 1.
any other dataObj and value are both decoded with all
dictionary information converted to codes, and
string comparison is applied to the decoded values.
The following examples show different values compared to an object of type Unsigned32.
Note in particular the difference between referencing the data object of type Integer32 and using
it as a variable. The latter means it is decoded as the value -5 then re-encoded as an Unsigned32
(left side data type), which yields the value 4294967291, which is greater than 20.
TTS> [[temip::data type Integer32] move int32] encode -5
::int32
TTS> [[temip::data type Unsigned32] move unsig32] encode 20
::unsig32
TTS> unsig32 compare &int32
1
TTS> unsig32 compare $int32
-1
TTS> unsig32 compare 0x14
0
6.9.4 Filtering OSI events

The compare sub-command of a data object allows for a standard filtering of OSI events using a
Discriminator Construct (DC) filter.
10
This can be used check if instance matches wild-carding.

The data object must be a CMISFilter type created indirectly from an attribute or argument of
a directive call or context (using the –object option when retrieving the value) or created
directly using the sub-command from of the temip::data command. The OID used for
reference must “point” to an attribute or argument of the constructed datatype CMISFilter (e.g.
1.3.12.2.1011.2.22.2.27.126.3, the “Discriminator Construct” attribute of class
“OPERATION_CONTEXT”).
The value must be a reference (using &) to a data object of type EventReport. The object must
be associated with a dictionary node and may be created indirectly or directly, just as the
CMISFilter object. Event reports are returned from e.g. the GetEvent directive and are also
available directly in a TTS corrective filter script.
The following example script shows an event report returned from a GetEvent directive call
being filtered by a local created and initialized DC filter:
set dc [temip::data from 1.3.12.2.1011.2.22.2.27.126.3]
$dc encode {{{LogicalOp And}} {{LogicalOp Item} {Item {{FType substring}
{stringAssertion {{{initialstring {{{OSI_SYSTEM LOG LOG_RECORD} {Additional
Text}} {TTS Test}}}}}}}}} {{LogicalOp End}}}
set cl [temip::call setup getevent {{oper xx}} "NOTIF"]
$cl call
set evrp [$cl get reply "event data" –obj]
if {[$dc compare &$evrp] == 0} {puts Passed} else {puts Blocked}
DC filters can be hard to encode, so using the TeMIP client DC editor to initialize a CMISFilter
attribute and then copy its value to the TTS script, is recommended. Use e.g. the tts_mb
application to get the instance DC attribute value in TTS format.
For further description of DC filters, refer to “TeMIP Fault Management Reference Guide”,
Chapter 3.1.
6.10 Call Command and Object

TeMIP directive calls are made from TTS Tcl scripts using TTS call objects. Call objects are
used in all phases of the directive call process: before, during and after. This section first
describes the subcommands of the TTS call command, including the key one, setup, which
creates a TTS call object and then the subcommands of the call object (see section 6.2 for a
description of general properties of TTS objects). In these descriptions callObj stands for the
name of a call object. For an introduction to call objects, refer to the description under the
heading Call Command in section 2.1.3.
A call object can be explicitly deleted, like any other TTS object. If the object is active in a
synchronous call when it is deleted, then the call will be cancelled. It is not necessary to
explicitly cancel it before deleting it. Deleting a call object which was used to start an
asynchronous call does not have any effect on the call processing.
temip::call deleteall
See section 6.2 and the paragraph above.
temip::call setup directive entity ?partition?
creates a call object and returns its name as result. The entity to which the directive applies is
specified by entity, which must be a data value (see section 6.4.1) of type FullEntity or
LocalEntity; directive is the name or code of the directive (verb) to call; partition
is the name or code of the event or attribute partition to which the call shall apply. The default, if
partition is not present, is the null partition.
Once a call object has been created, call arguments can be added by use of the set, duration,
qualifier and default subcommands, an actual TeMIP directive call can be triggered by
means of the call subcommand, and the response, timestamp, entity, get and
director subcommands may then be used to retrieve different parts of the TeMIP reply. A
call object may be used repeatedly to make directive calls. All the subcommands of the call
object are described below.
Example (Create call object for a show directive):
set callObj [temip::call setup show {{mcc 0}} ident]

temip::call wait ?timeout?
causes the Tcl interpreter to enter its event dispatch loop where it will handle any Tcl events up
to the first call completion event from an asynchronous call, including the execution of the
callback command specified for that asynchronous calls. The timeout argument specifies the
maximum time, in milliseconds, that the interpreter will wait for a call completion event. If it is
omitted there is no maximum waiting time.
The command returns 1 (true), if a reply event was received or 0 (false), if it timed out.
The standard Tcl commands vwait and update can also be used to wait for replies. They will
handle all events until the specified variable is modified (refer to Tcl documentation).
Note
The wait commands cannot be interrupted, so a temip::call wait command with no
timeout will “hang forever” if no call completion event or other Tcl event is generated.
Example (Wait for asynchronous show call response for max. 10 seconds):
TTS> proc callback {resp} {puts {Got Response}}
TTS> [temip::call setup show {{mcc 0}} ident] call access callback
Asynchronous
TTS> temip::call wait 10000
Got Response
temip::call alert thread

alerts an executing TeMIP call command in another Tcl thread. The argument thread is the
handle returned by the thread::create command from the Tcl Thread package.
Example (Listen for events in another thread; Then alert it)
TTS> package require Thread
TTS> set threadId [thread::create {
package require Tts
temip getevent {{company *}} {any notif} {duration infinity}
}]
TTS> temip::call alert $threadId
Error from thread tid0000000000000007
Alerted …
temip::call sigint bool

Control if the Unix SIGINT signal shall generate a TeMIP alert signal. The default is “on”,
meaning that SIGINT (e.g. ctrl-C) will alert a waiting call or a running Tcl command, make it
fail with the Tcl error “alerted”. This command does not control the alerts send by the alert
subcommand.
Example (Ignore Ctrl-C):
temip::call sigint off
callObj delete
See section 6.2 and the remark on call object deletion at the beginning of this section.
callObj type
returns the verb type of the call object. It will be one of the following: Examine, Modify,
Action, Event, Presentation.
Example (Inspect type of directive “Show”):
TTS> set cl [temip::call setup Show {{mcc 0} {appl tts_pm}} ident]
TTS> $cl type
Examine
callObj dump
returns a ILV dump of the call object for debugging.
Example (Debug show directive):
TTS> [temip::call setup Show {{mcc 0} {appl tts_pm}} ident] dump

request mode : 0verb : 1, partition : 1, in entity : Scope : BASE OBJECT
entity [0] wild = NOT_WILD class = 7 id = 1 type = 5
instance = ......?K,...?.....temip..rap_director..
%X000000000000A14B2C019C1BA7001700010574656D6970010C7261705F64
…
callObj directive ?form?

returns the name, if form is -names (default), or code, if form is -codes, of the directive
verb of the call object, as defined in the dictionary.
Example (Get name of directive in call object):
TTS> $cl directive
SHOW
callObj partition ?form?

returns the name, if form is -names (default), or code, if form is -codes, of the attribute or
event partition of the call object, as defined in the dictionary.
Example (Get name of partition in call object):
TTS> $cl partition
Identifiers
callObj list argument

retrieves definitions from the TeMIP dictionary for attributes, request arguments or reply
arguments that are set on the call object. The list subcommand has three variants, determined
by the first argument, see the following descriptions.
callObj list attributes ?-all | -available?
retrieves and returns a list of definitions for attributes that are present on the call object. With the
–available option only attributes with reason code Available are returned. These
attributes may have been set using the set attribute subcommand or returned from a
TeMIP call. If the call object was set up with a null partition no attributes will be available. Each
element in the list is itself a list with the following elements:
0. The code of the attribute.
1. The presentation name of attribute.
2. The OID of the attribute (see section 6.7).
3. The code of the data type of the attribute.
4. The attribute reason (see section 6.3), only available if the call object contains a
reply argument with code 1 (as for Show and Set).
5. Access permissions for the attribute: Settable, NonSettable, or
WriteOnly.
6. Display state of the attribute: Display or NonDisplay.
7. The Units text, if available.
8. Default value status: DefaultValue or NoDefaultValue.
9. The default value, if available.
Example (Get list of definitions for attributes associated with call object):
TTS> $cl list attributes
{1 {Application Id} 1.3.12.2.1011.2.22.2.7.202.126.1 35 NoReply NonSettable
Display {} NoDefaultValue {}}
{2 {Application Name} 1.3.12.2.1011.2.22.2.7.202.126.2 3 NoReply
NonSettable Display {} NoDefaultValue {}}
Example (Get display state of attribute “Application Id”):

TTS> set al [$cl list attributes]
TTS> set info [lsearch -index 1 -all -inline $al {Application Id}]
TTS> set st [lindex $info 0 6]
Display

Or the short version
set st [lindex [lsearch -index 1 -all -inline [$cl list attr] *Appl*] 0 6]
callObj list request ?-all | -available?

retrieves and returns a list of definitions of the request arguments which are currently set on the
call object (using the set request subcommand). If –all is present then all request
arguments defined for the verb are included in the list. Each element in the list is itself a list with
the following elements:
0. The code of the argument.
1. The presentation name of argument.
2. The OID of the argument (see section 6.7).
3. The code of the data type of the argument.
4. Available or NotAvailable (only interesting with –all).
5. Required or NotRequired.
6. Display or NotDisplay.
7. Units text.
8. Default allowed.
9. The default value.
10. Echoed or NotEchoed.
Example (Get list of definitions for request arguments associated with call object):
TTS> set cr [temip::call setup Create {{oper oc1}}]
TTS> $cr list request –all
{2 {Associated Domain} 1.3.12.2.1011.2.22.4.27.126.12.2 5 NotAvailable
Required Display {} NoDefaultValue {} Echoed}
{1 {Reference Operation_Context Name} 1.3.12.2.1011.2.22.4.27.126.12.1 5
NotAvailable NotRequired Display {} NoDefaultValue {} Echoed}
{3 {Discriminator Construct} 1.3.12.2.1011.2.22.4.27.126.12.3 52
NotAvailable NotRequired Display {} NoDefaultValue {} Echoed}
…
callObj list reply ?-all | -available?
retrieves and returns a list of definitions of the reply arguments which are currently set on the
call object. If –all is present then all reply arguments defined for the verb are included in the
list. Each element in the list is itself a list with the same elements as for request arguments (see
list request above).
Note that the availability of reply arguments will depend on the response status after a call.
callObj set attribute id value
sets the value of an attribute in the request argument with code 1 provided it is of type
AttribList (as is the case for the Set directive). The attribute is the one identified by id,
which can be its name or its code. The value that is set is given by the argument value, which
must be a data value (see section 6.4.1) of the type of the attribute.
Example (Update the “trace mask” attribute of the tts_pm application instance):
set cl [temip::call setup Set {{mcc 0} {appl tts_pm}} char]
$cl set attribute "trace mask" 0xff
$cl call
Note
The total length of all data set in a call object cannot exceed ~ 60 Kbytes
callObj set request id value

sets the value of the request argument identified by id, which can be its name or its code, to the
value specified by value, which must be a data value (see section 6.4.1) of the type of the
argument.

Example (Create a corrective filter entry):
[temip::call setup create {{mcc 0} {corrective myfilter}}] move cf
cf set request input {}
cf set request target mymodule
cf set request action temip_ef_tts_library:TTS
cf set request parameters myfilterscript
cf set request cascade false
cf call
callObj default attribute id

callObj default request id
sets the default flag on the attribute or argument identified by id. This will notify the called
management module to apply the default value for the attribute or argument (if implemented).
callObj duration value
sets the duration for the call object to the value specified by value, which must be a data value
(see section 6.4.1) of type BinAbsTime or BinRelTime.
The command returns the absolute time (BinAbsTime) for the duration specified
Note that not all directives support duration. It is mostly used with the GetEvent directive and is
then often set to the value Infinity.
Example (Wait for a configuration event for the next 10 minutes):
set ge [temip::call setup GetEvent {{oper *} {alarm *}} config]
$ge duration +00:10:00
$ge call
callObj qualifier qtype qtext

sets the qualifier identified by qtype which can be one of: domain, password, account,
user, port and manager, to the value specified by qtext.
callObj retry mode
sets the retry mode of the call object, which will determine the retry handling if a ”Retrying call
requested” common exception (27) occurs when the call is actually made. There are three
possible values for mode:
auto retries are automatically made until communication is successful (default)
off no retries are made, the communication error is returned immediately. The
call is cancelled and cannot be repeated
self no retries are made, the communication error is returned immediately. The
retry decision is left to the calling script; if the call is not retried it must be
cancelled explicitly.
callObj call ?mode?
callObj call mode callback ?callControl?
Both of these commands cause a TeMIP directive call to be made, using the information held on
the call object, and returns the status of the call. The mode of the call can be access,
function (default) or presentation. See the TeMIP System Reference Manual for a
description of call modes.
Before making the actual directive call TTS will validate that the call is legal according to the
active security session (see section 2.1).
The first form makes a synchronous TeMIP call and returns when a response is available.
The second form makes an asynchronous call, i.e. the call is initiated, but the response from the
called TeMIP management module is not waited for before execution continues with the next
Tcl command. The asynchronous call is only allowed in the main thread of a TTS PM and in the
Master interpreter of TTS MM or CF.
Note
A synchronous call command may take a long time, depending on the called directive. The
call can be interrupted by sending the process an INT signal (CTRL-C).

In both cases the command returns a status which will be one of those shown in Table 10. An
“S” in the S/A column indicates the status may occur for a synchronous call, an A indicates it
may occur for an asynchronous call.
Table 10, Call Command Status
Status Description S/A
Response The call succeeded. S

CommonException The call returned a common exception S
SpecializedException The call returned a specialized exception S
Alert The call was alerted (interrupted). SA
Cancel The call was cancelled. SA
TransmitError The call was disconnected from the management SA
module servicing the call.
Status-XXX (text) An unknown status from the directive call was SA

received. XXX is the status value and text is the
derived explanation.
Asynchronous Asynchronous call started successfully. A

AsynchronousError The asynchronous call did not start correctly. A
NoMoreMemory The system did not have any more memory to execute A
the call.
After a synchronous call the response, timestamp, entity, director, get and more
subcommands on the same call object that was used to make the call may be used to extract
result information. If there are multiple replies, as indicated by the “more” flag, the call
command may be called again to retrieve the next one.
In the asynchronous form of the command the parameter callback is a Tcl command which is
called by the interpreter’s event handler when the response is received. It is called in the global
namespace. In this case the call reply information is not placed in the call object that was used to
make the call, but on another object, the reply object, which is created as a copy of the original
call object, before the reply information is placed in it. The name of the reply object is appended
to the callback command passed by the call command. For this reason the callback command
will typically take the form of a procedure call which is one parameter short of matching the
proc command that defines the procedure. The same subcommands as in the synchronous case
(response, timestamp, entity, get and more) can be used to extract information from
the reply call object.
When an asynchronous call returns multiple responses - typically if it is wild carded, the
responses are fetched automatically and the callback called for each one, i.e. the call
subcommand shall not (and cannot) be called repeatedly. The callControl parameter of the
initial call determines the flow control policy: if it has the value -single each new response is
retrieved when the previous one has been processed by the callback; if it has the value -all all
responses are retrieved to the TTS process as fast as they are produced by the called
management module and queued by the interpreter. This may require extended memory use for
the TTS process.
Example (Synchronous Show directive call):
TTS> set cl [temip::call setup Show {{mcc 0} {appl tts_pm}} ident]
TTS> $cl call function
TTS> $cl get attribute "Application Name"
tts_pm
Example (Asynchronous Show directive call):

proc CallBack {response} {
puts [$response get attribute "Application Name"]
}
set cl [temip::call setup Show {{mcc 0} {appl tts_pm}} ident]
$cl call function CallBack
…
temip::call wait; # Wait for a single response
Example (Asynchronous wild-carded Show directive call):

proc CallBack {response} {
if ![$response more] {set ::calldone true; return}
puts [$response get attribute "Application Name"]
}
[temip::call setup Show {{mcc 0} {appl *}} ident] call function CallBack
…
vwait ::calldone; # Wait for all responses (until variable is set)
callObj response option ?-expand | -noexpand? ?-names | -code?

retrieves and returns the latest response status from a call (possibly asynchronous reply) object.
The option parameter determines which part of the status is returned and how:
Table 11, Call response options
option Result
code The response code defining the type of response or exception. This is only
meaningful if the status indicates the reply contains a response or exception.
status The status as described in Table 10.
text A list of two elements: the presentation name and reply text of the response or
exception.
Note that the special reply text format “!<arg>” is only expanded if the -expand
option is specified.
full Returns the full reply.
The reply is a list of:
0. Status
1. Text
2. Reply argument list
Each argument in the list is a pair of argument name and value.
If –code option is specified, then only codes are returned and the Text is not
expanded.
Example (Asynchronous callback procedure testing response status):

proc CallBack {resp} {
set status [$resp response status]
if {$status eq "Response"} {
puts "Call result: [$resp get attribute "Application Name"]"
} else {
puts "Call failed with: $status"
}
}
callObj timestamp ?returnDataSpec?

returns the timestamp - a data value of type BinAbsTime - of a TeMIP call reply from the call
(possibly asynchronous reply) object in the form specified by returnDataSpec (see section
6.4.2).
callObj entity ?returnDataSpec?
returns the out-entity - a data value of type FullEntity - of a TeMIP call reply from the call
6.4.2). This is typically only used for a wild carded entity, where the out-entity of each reply is
not determined by the in-entity.

callObj director ?returnDataSpec?
returns the out-director - a data value of type FullName - of a TeMIP call reply from a call
6.4.2). This is typically only used for a wild carded global entity, where entities may be returned
from different directors.
callObj get arr id ?returnDataSpec?
returns the value of an attribute, request argument or reply argument from the call (possibly
asynchronous reply) object in the form specified by returnDataSpec (see section 6.4.2). An
attribute value may either have been set or shown.
The arr argument must take one of the values attribute, reason, request or
reply, to specify whether the get concerns an attribute value, the attribute reason code (see
Table 3), a request argument value or a reply argument value. The arr may also be specified as
value, in this case it will get the attribute value for examine (show) and modify (set) directives
and the reply value for other directives.
The id argument specifies which attribute or argument by name or code.
The type of the value which is returned is the type of the specified attribute or argument.
Examples (Interactive call Show session):
TTS> [temip::call setup show {{mcc 0}} char] move c
::c
TTS> c call
Response
TTS> c get attribute "Parse Table File"

/var/opt/temip/conf/en_US.iso88591/mcc_fdictionary.bpt
TTS> c get reply "arg show"

{{Director UID} 01DCA407-4DA1-5B90-0000-1031C9DB0002 Available}
{{Distribution Mode} Server Available} {{Binding Information} {} Available}
{{Director Username} temip Available} {{Director Host} test Available} ……
TTS> c get value "Director Creation Time"

2007-12-06-15:26:58.842
TTS> c get reason "MCC"

AttributeUnused
callObj more ?form?

checks if the call reply held on the call object has the “more” flag set to indicate that additional
responses are available from the original call. This is used with synchronous calls to determine
whether to re-invoke the call subcommand to retrieve the additional responses.
The form argument determines the form in which the result is returned.
If it is –text, availability of an additional response is indicated by the result More, no more
replies by the result End. Unavailability of data in the current reply is indicated by the result
Invalid.
If form is –more or omitted, the result will be 1 (true, more data) or 0 (false, no more data).
For an asynchronous call the result will indicate whether additional calls to the specified
callback will occur or if the current reply contains valid data.
If form is –text and the call have been cancelled; this is indicated by the value Cancel,
which also indicates that the reply object does not contain valid data. The value -cancel can
also be used for the form argument, and the response will then have the value 1 (true) if the call
was cancelled, 0 (false) otherwise.
Table 12, Call “more” options
Synchronous call object Asynchronous reply object
-text -more -text -cancel -more
Reply data not valid - - Invalid true false

Call canceled - - Cancel true false
More replies available More true More false true
Last reply End false End false false
Example (Print all registered TeMIP application names and break when no more):
[temip::call setup show {{mcc 0} {appl *}} ident] move c
while {[c call function] eq "Response"} {
puts "Application name is [c get attribute "Application Name"]"
if ![c more] break
}
callObj more -change

sets a flag on the call object indicating that when the call subcommand is re-invoked while the
“more” flag is set, the (possibly modified) call request parameters shall be passed again. This is
normally not done, i.e. when the repeated calls serve to retrieve additional responses to the
original call, but only if the particular directive implements a special protocol, where it is
meaningful to change the parameters.
callObj cancel
cancel a TeMIP call, i.e. inform the called management module to stop activity initiated by a call
made previously and discard any responses that have not been fetched.
If cancel is called on a reply object in an asynchronous callback, the original call will be
cancelled. Note that an additional call is made to the callback command with the “more” flag
indicating that the asynchronous call was cancelled.
Example (Cancel synchronous call after 10 calls with “more” handle):
[temip::call setup show {{mcc 0} {appl *}} ident] move c
while {[c call function] eq "Response"} {
puts "Application name is [c get attribute "Application Name"]"
if {[incr i] > 9} {
c cancel
}
if ![c more] break
}
6.11 Event Command and Object

TeMIP events can be generated from TTS Tcl scripts using TTS event objects (see section 6.2
for a description of general properties of TTS objects). For an introduction to the use of event
objects in the process of event generation, refer to the description under the heading Event
Command in section 2.1.3.
A TeMIP event is an asynchronous message which is passed to receiving management modules
as a response to GetEvent directive calls. It must be posted against a specified TeMIP entity,
which will be the out-entity returned from the GetEvent call. The GetEvent response has a
uniform specification which applies across all entity classes. The main body of an event is the
event report which is passed as the response argument called Event Data. The event report can
contain any collection of event arguments. In almost all TeMIP modules the supported event
reports comply with OSI event specifications, and are notification events, viz. alarms or security
alarms, or configuration events such as object creation / deletion or state / attribute value change.
All OSI events have an Event Type and an Event Time argument. Other event arguments depend
on the type of event. For OSI alarms they include Perceived Severity and Probable Cause,
Specific Problem, Additional Text and Additional Information. For information on the types of
the various OSI event arguments, including their enumerated values, it is recommended to look
them up using the dictionary browser.
A TTS event object includes a complete specification of an event relative to the TeMIP
dictionary in terms of entity, entity partition and event id as well as all the arguments which go
into the GetEvent response.
The GetEvent response includes a few response arguments outside of the event report. The
following arguments are supported by the TTS event command: Mode, Target Entity, and Target
Severity.

The setup subcommand of the TTS event command creates an event object with initial
arguments, and then subcommands of the event object command are used to specify additional
arguments and to forward the event to the event manager to be put into the event pool on behalf
of the specified entity. After an event has been forwarded, the arguments can no longer be
changed, but forwarding of the event object can be repeated. In the descriptions of event object
subcommands eventObj stands for the name of the event object.
temip::event deleteall
See section 6.2.
temip::event setup entity eventpartition eventid \
?eventtype? ?cause? ?severity?
temip::event nofiltersetup entity eventpartition eventid \
?eventtype? ?cause? ?severity?
creates an event object and returns its name as result. The entity against which the event will be
returned (out-entity in GetEvent response) is specified by the entity argument, which must be
a data value (see section 6.4.1) of type FullEntity.
The arguments eventpartition and eventid specify the event among those defined for
the entity; this definition determines the applicable event arguments (in the event report),
normally according to one of the OSI event types.
The eventtype argument provides the value of the Event Type OSI event argument and must
specify a data value of the type of this argument. If it is present the event will be an OSI event
and will include the Mode and Target Entity arguments, the Managed Object OSI event
argument is set to the value specified by entity (same as Target Entity), and unless overridden
by a call of the argument subcommand the OSI Event Time argument will be set to the time
the event is put.
The optional arguments cause and severity provide initial values for the OSI alarm event
arguments Probable Cause and Perceived Severity (or on OSI security alarms: Severity and
Security Cause). They must specify data values of the appropriate types.
Example (Create an event object):
temip::event setup {{OSI_SYSTEM test}} {NOTIFICATION EVENTS} {Operational
Violation} IntegrityViolation AuthenticationFailure Minor
or using dictionary codes:

temip::event setup {{OSI_SYSTEM test}} 16 1708 5 1 3
If the subcommand nofiltersetup is used instead of setup, low level filtering is

suppressed on event forwarding even in the case that the event is an OSI event (see the forward
sub-command below and section 2.4).
eventObj delete
See section 6.2.
eventObj entity value
re-specifies the out-entity of the event according to the entity argument, which must be a data
value (see section 6.4.1) of type FullEntity.
eventObj set id value
sets the value of the event report argument identified by id, which can be its name or code, to
the value specified by value, which must be a data value (see section 6.4.1) of the type of the
argument. Values for event record arguments already set by the setup subcommand can be
redefined.
This subcommand returns 1 (true), if a value had previously been set for the event argument,
otherwise 0 (false).
Example (Add arguments to an event object):
[temip::event setup {{OSI_SYSTEM test}} 16 1708 5 1 3] move eventObj
eventObj set "Additional Text" "Bad password"

eventObj set "Service User" "Administrator"
eventObj set 304 false
Note
The total length of all data set in an event object should not exceed ~ 30 Kbytes
eventObj timestamp value

sets a timestamp on the event as specified by value, which must be a data value (see section
6.4.1) of type BinAbsTime. If this subcommand is not called the event will be time stamped at
the time it is forwarded to the event manager.
Note
The event timestamp set with this subcommand is distinct from the event record “Event
Time” argument, found in OSI events.
Example (Set event timestamp to 10 seconds before now):

$event timestamp -00:00:10
eventObj targetentity value

sets the value of the Target Entity argument of the event as specified by value, which must be
a data value (see section 6.4.1) of type FullEntity or FullEntity.
The Target Entity argument is used for filtering purposes by the TeMIP Map Viewer and Alarm
Handling applications. For an OSI event is it set equal to the out-entity of the GetEvent response
to achieve the intended filtering. Normally that is what is needed for filtering. If not, this
subcommand can be used to change it.
eventObj targetseverity value
sets the value of the Target Severity argument of the event as specified by value, which must
be a data value (see section 6.4.1) of type Unsigned32. This argument is normally set when
the original Perceived Severity event argument is escalated.
eventObj forward
forwards an event, with arguments taken from the event object, to the event manager on the
TeMIP director to be put in the event pool. Returns 1 (true), if the event was waited for
(GetEvent), otherwise 0 (false).
Note
The command does only return after the event has been delivered and possibly low-level
filtered. Be careful when emitting events from within a corrective filter, that it does not cause
a loop or dead-lock.
This subcommand will return a Tcl error if the operation fails for any reason.
Example (Put event into event poll using low level filters):
set event [temip::event setup {{OSI_SYSTEM test}} 16 1708 5 1 3]
$event forward
Example (Put event with modified out-entity into event poll with no low level filtering):
set event [temip::event nofiltersetup {{OSI_SYSTEM test}} 16 1708 5 1 3]
$event entity {{OSI_SYSTEM moretests}}
$event forward
Note
If the event is not an OSI event (no event type specified) or if it was created using the
nofiltersetup sub-command, no low-level filtering will take place on forwarding.

eventObj filter args
This subcommand is used in corrective filters only. See section 9.2.
6.12 Acloc Command and Object

TTS implicitly maintain a TeMIP security session and all directive calls which are made to the
TeMIP framework are validated against this session. This is described in sections 2.2 and 2.3.
Security enforcement over and above this implicit validation can be implemented as explicit
checks done by means of a TTS acloc object. Explicit validation is most relevant in a
management module implemented with TTS MM.
The acloc object represents a user session as described in the TeMIP Security Operator’s Guide
and includes an AC view for a specified user, which can be different from the one used to
establish the implicit security session. It can be created using the session subcommand of the
temip::acloc command and used to validate the rights of the specified user to make TeMIP
calls and access attributes and arguments.
Deleting an acloc object will cause the user session to be terminated if the object was the first
one created for the user (except for the default user in TTS PM). Other acloc objects for the
same user session will be invalidated as a consequence.
In the descriptions of acloc object subcommands below aclocObj stands for the name of the
acloc object.
The log subcommand in its various forms can write entries into the central and user session
command logs. Writing of entries will only take place provided logging to the respective log is
enabled and the respective logging status value in the security session is ON.
temip::acloc password user ?pswd?
performs (UNIX) password authentication for the user specified by the value of user and
returns 1 (true) if the user is known 11 and the password correct, 0 (false) otherwise.
The password can be specified by the pswd argument. If this argument is omitted the password
is read from /dev/tty with no echo. The command does not output any prompt before reading the
password; this must be done by the calling script.
Example (Check password that user enters online):
set user temip
puts "Please enter password for user $user: "
set ok [temip::acloc password $user]
temip::acloc deleteall
See section 6.2 and also the remark in the beginning of this section about deleting an acloc
object.
temip::acloc session ?user?
creates a security acloc object and returns its name as result; this uses functions of the TeMIP
ACLOC API to create a security session for a specified user. ACLOC retrieves the name of the
user profile which applies to the user and the default AC view from the profile.
The user specified towards ACLOC can be given explicitly as the value of the user argument.
If this argument is omitted the user is specified as follows:
TTS PM The user of the TTS PM session as established when TTS PM was called;
see section 7.1 under the heading Security Setup.
TTS MM The owner of the process which called the directive in the management
module (the client of the management module).
Example (Create an acloc session for user temip):
temip::acloc session temip
11
The user is checked against NIS, /etc/shadow and /etc/passwd depending on configuration and permissions.

aclocObj delete
See section 6.2 and also the remark in the beginning of this section about deleting an acloc
object.
aclocObj activate ?password?
use the session object as the active ACLOC session for future directive calls. This session
remains in effect in the current Tcl interpreter until a new is activated or until the current session
object is deleted. Sessions must be activated individually for each interpreter in use.
The password for the session user must be specified if the process was not started as the user
“root”. If password is specified as the empty string, it is read from the TTY with no echo.
This subcommand returns a Tcl error if the session can not be activated for some reason.
Example (Activate a session for the temip user):
set user temip
set al [temip::acloc session $user]
puts "Please enter password for user $user: "
set err [catch {$al activate {}} res]
if $err {puts $res}
aclocObj info
retrieves the information contents of the acloc object and returns a list of 8 elements: host name,
user name, process name, session name, active AC view filename, user profile filename, central
LOC status, user session LOC status.
Example (Get acloc attributes for the temip user):
TTS> set user temip
TTS> set al [temip::acloc session $user]
TTS> $al info
rap.dnk.hp.com temip tts_pm temip.hgo@rap.dnk.hp.com@tts_pm@2009-MAR-31-
15:48:20:008067
/var/opt/temip/acloc/user_profiles/temip_root_default_ac_view.v
/var/opt/temip/acloc/user_profiles/user_temip.profile OFF {}
aclocObj check call ?callObj?

aclocObj check directive dir entity
aclocObj check attribute dir entity attr-id
aclocObj check argument dir entity arg-id
checks that the directive call or use of an entity attribute or directive call argument which is
specified by the arguments is allowed under the conditions of the session. The result returned
will be one of the following three strings:
Authorized The specified usage is allowed.
Rejected The specified usage is not allowed.
Partial The entity is wild carded, and the usage is disallowed for some of the
entities.
With the first form of the command the optional callObj argument, if present, must be the
name of a TTS call object. The check is then applied to the directive call specified by the call
object. Omitting the callObj argument is legal when the command is called from within a
directive script in TTS MM which is handling a directive call. In that case the check applies to
the call which is being processed.
In the other three forms of the command the arguments are as follows: dir specifies a directive
by name or code, entity must be a data value of type FullEntity representing one or more
(if wild carded) TeMIP entities, attr-id specifies an attribute of the entity by name or code,
and arg-id specifies an argument of the directive by name or code.
Example (Check authorization for directives in given acloc context):
TTS> $al check attribute Show {{mcc 0}} "Director Name"
Authorized
TTS> $al check directive Reset {{mcc 0}}
Rejected

aclocObj log call ?callObj?
aclocObj log directive dir entity
aclocObj log attribute dir entity attr-id
aclocObj log argument dir entity arg-id
checks, exactly like the check command, that the directive call or use of an entity attribute or
directive call argument which is specified by the arguments is allowed under the conditions of
the session and returns the same result as the similar call of check. In addition, if the usage is
disallowed, wholly or partially, entries are written to the central and user session command logs.
Example (Log authorization for directives in given acloc context if not allowed):
$al log directive Create {{oper *}}
aclocObj logall call ?callObj?

aclocObj logall directive dir entity
aclocObj logall attribute dir entity attr-id
aclocObj logall argument dir entity arg-id
works like the log subcommand, except that authorized commands are also logged.
aclocObj log string str ?str-type?
logs in the central and user session log the ASCII string specified by the str argument. The
argument str-type specifies a string type which is a number in the range 0-31 (default is 0)
used to distinguish between different types of strings that can be written to logs. Writing to each
of the logs will only take place provided the string type passes the mask which is configured for
the log. Refer to the TeMIP Security System Administrator’s Guide for more information on
string masks.
Example (Write text to TeMIP central log):
TTS> $al log string "test"
6.13 MIR Command and Object

The temip::mir command implements an interface to the standard TeMIP MIR (data-base) 12.
A TeMIP MIR (data-base) is constructed of a number of C-ISAM files that holds the instances
and the associated data. The name of the MIR is embedded in the C-ISAM files as:
iname.dat the instance data
iname.idx the instance index
iname.lck the instance lock
dname.dat the associated data
dname.idx the associated data index
dname.lck the associated data lock
To manage the MIR files, use the TeMIP utilities temip_mir_backup, temip_mir_recover, etc.
A new MIR object is created by the temip::mir open command.
A MIR object acts as a reference to a specific entity in the MIR (the current entity). This
reference may be changed by the subcommands of the MIR object.
Any number of MIR objects, open on the same MIR, may be used simultaneously; referencing
the same or different entities. There are no transaction locks or synchronization between access
to the same MIR, but each MIR object subcommand do read/write on the MIR as an atomic
operation.
The MIR is indexed by TeMIP entities (managed objects) with valid class ids and identifier
attribute values according to the TeMIP dictionary. For multi level entities, the parent entity
must exist in the MIR before a child entity can be inserted.
12
Other data-base interfaces are also available in TTS. See the Sqlite and Oratcl packages in chapter 11.2.

Each entity has a set of associated data. The data may be a user defined string and/or attribute
lists indexed by partitions ids. The partitions and attributes available for an entity are defined by
the TeMIP dictionary.
temip::mir check name
checks if the MIR already exists. Returns 1 (true) if it does, else 0 (false). The MIR files must
comply with the naming described above.
If the check encounters any problems, like missing data base file read/write permissions, it is
returned as a Tcl error.
Example (Check MIR):
if ![temip::mir check MyMIR] {
puts "MyMIR does not exists"
}
temip::mir open name ?location?

opens the MIR specified by name and returns a TTS MIR object. If location is specified the MIR
in that directory is opened else the MIR in the location specified in the environment variable
MCC_MIR_LOCATION is used (defaults to /var/opt/temip). If the MIR does not exist it is
created (with read/write permissions to owner and group).
If an existing data base can not be opened or if creation of a new data base fails, a Tcl error is
returned.
On successful open of the MIR, the name of a new MIR object is returned. The object is initially
not referencing any entity.
Example (Create MIR object):
set mymir [temip::mir open MyMIR]
mirObj delete
See section 6.2. Deleting the MIR object does not affect the data base.
mirObj insert entity
inserts entity (FullEntity) in the MIR. Returns 1 (true) if a new entity was inserted and returns 0
(false) if the entity did already exist. The entity referenced by the MIR object is changed to the
inserted entity. The data associated with a new entity is empty.
Example (Add parent and child entity to MIR):
$mymir insert {{mcc 0}}
$mymir insert {{mcc 0} {appl tts_pm}}
mirObj alias entity

inserts an entity in the MIR. Returns 1 (true) if a new entity was inserted or returns 0 (false) if
the entity did already exist. The data associated with the new alias entity is the same as the data
associated with the currently referenced entity. The entity of the alias command and the current
entity must be the same, except for the identifier attribute and the identifier attribute value of the
deepest level of the entity.
The entity referenced by the MIR object is changed to the inserted alias entity.
Example (Use both application name and id identifier, as index for same entry):
$mymir insert {{mcc 0} {appl tts_pm}}
$mymir alias {{mcc 0} {appl 42}}
mirObj remove ?-alias | -all?

If –all is specified (default) then removes the currently referenced entity and all associated
data and aliases. If –alias is specified the current entity must have been created using the alias
subcommand. The alias entity is deleted, but no associated data is deleted.
The command returns 1 (true) if the entity was deleted, else 0 (false). The MIR object is not
referencing any entity after the subcommand returns.
Example (Delete current entry in MIR):
$mymir remove

mirObj lookup ?entity? ?-all | -identifier ?id??
if entity is specified, then find the first entity in the MIR that matches the options (see below). If
no options are specified find the next match for an ongoing (wild-carded) lookup.
The entity must specify non wild-carded instances and classes except for the deepest class level.
At the deepest class level the identifier attribute value may be a fully, partial or non wild-carded
value.
If the instance value is not wild-carded and –all is specified (default) an exact matching entity
is looked up.
If the instance value is wild-carded, only entities matching the value is found. If an entity has
more than one identifier (alias) and –all is specified (default) all matching values are found,
independently of the identifier attribute id and type.
If–identifier is specified with the id of an identifier attribute. Only values of the specified
attribute that matches the (wild-carded) entity are found.
If the instance is non wild-carded and only –identifier is specified (no id), the specified
instance value is used to find the identifier attribute type and all values of that identifier are then
found (as if fully wild-carded on that identifier only). This is useful if e.g. only numeric
identifiers are to be found.
The lookup command returns 1 (true) if the lookup succeeded (an entity was found) and the
entity referenced by the object is set to the found entity. If the lookup failed, 0 (false) is returned
and the referenced entity is not changed.
Example (Find a specific entity):
$mymir lookup {{mcc 0} {appl tts_pm}}
Example (Loop though all application entities in MIR, including aliases):

set found [$mymir lookup {{mcc 0} {appl *}}]
while {$found} {
set found [$mymir lookup]
puts [$mydir entity]
}
Example (Loop though all application entities, by name):

set found [$mymir lookup {{mcc 0} {appl *}} –identifier “Application name”]
while {$found} {
}
Example (Loop though all application entities, identified by a number):

set found [$mymir lookup {{mcc 0} {appl 0}} –identifier]
while {$found} {
}
mirObj entity ?returnDataSpec?

returns the current entity in the form specified by returnDataSpec (see section 6.4.2).
Example (Get current entity):
$mymir entity
Example (Print all application entries in MIR):

set found [$mymir lookup {{mcc 0} {appl *}}]
while {$found} {
puts [$mymir entity]
}
mirObj key ?key?

if key is not specified, returns a key (see description below) to the current entity. If key is
specified, moved the current entity to the entity described by the key.

A key is a Tcl list with 2 entries:
0. The entity (in –codes format)
1. An associated data handle.
The key is not associated with a specific MIR object, but can be used for any MIR object opened
on the same MIR data-base, to set current entity.
To check if two different keys point to the same associated data (using alias) the “associated data
handle” can be compared.
Note
A key can be saved in the user defined part of the associated data, enabling cross references
within the MIR.
The value of a MIR object used as a Tcl variable is the key.

Example (Get key of current entry):
TTS> $mymir key
{{7 x_ns:.temip.x_director} {202 42}} {1 222 30 161 239 99 252 126 0 0 16
49 201 219 0 4}
Example (Open second MIR object and point it to same entity as first MIR object):
[temip::mir open MyMIR] move mymirobj1
mymirobj1 lookup {{mcc 0} {appl tts_pm}}
[temip::mir open MyMIR] move mymirobj2
mymirobj2 key [mymirobj1 key]
Example (Check if two MIR objects point to same entity):

if {$mymirobj1 eq $mymirobj2} {
puts "Same entity [mymirobj1 entity]"
}
mirObj write string ?partition?

write the string value to a user defined part of the associated data. The partition defaults to 0, but
can be any id that is not defined in the TeMIP dictionary for the current entity class (the attribute
partition ids).
Example (Write user defined data to current entity):
$mymir write "My personal data"
mirObj read ?partition?

returns the string value from a user defined part of the associated data. The partition defaults to
0, but can be any id that is not defined in the TeMIP dictionary for the current entity class.
Example (Get user defined data from current entity):
TTS> $mymir read 0
My personal data
mirObj set partition attribList ?-merge | -overwite?

If –overwite is specified (default) then set the specified attribList (AttribList) in the partition
in the associated data. If –merge is specified, merge the attribList with an existing attribute list
in the associated data.
The partition must be a valid partition id of the current entity class. The attributes in the attribute
list must be (some of) the attributes defined in the specified partition.
The attribute list is of AttribList data type (see Table 1, type 66). The individual attribute
reasons may also be specified.
Example (Set attribute values in the current entity):
$mymir set Characteristics {{{Trace File} /tmp/log }}
$mymir set Characteristics {{{Trace Mask} 0xff Available}} –merge
Example (Get all Characteristics attribute values from Show call and set in MIR):

[temip::call setup Show {{mcc 0} {appl tts_pm}} Characteristics] move c
c call
$mymir set Characteristics [c get reply {Arg Show Values}]
mirObj show partition ?returnDataSpec?

returns the attribute list value from the specified partition in the form specified by
returnDataSpec (see section 6.4.2).
The partition must be a valid partition id of the current entity class.
Example (Get all Characteristics attribute values from current entity):
TTS> $mymir show Characteristics
{{Trace Mask} 0x000000000FF Available} {{Trace File} /tmp/log Available}
Example (Get all Characteristics attribute values from MIR and use in Set directive call):
[temip::call setup Set {{mcc 0} {appl tts_pm}} Characteristics] move c
c set request "Attribute Values" [$mymir show Characteristics]
c call
Example (Efficient assignment using -object and TTS object reference “&”, see section 6.4.1):
c set request "Attribute Values" &[$mymir show Characteristics -object]
Example (Get attributes from MIR and use in reply in Show directive script in a MM):
temip::context set reply "Attribute Values" [$mymir show Characteristics]

Chapter 7
Presentation Modules and shells
7.1 Command Line and Script File

A TTS PM is called from a UNIX shell command line and behaves as a typical UNIX shell-type
application, by reading Tcl commands from its standard input or from a file and evaluating them.
Security setup
Normally, when invoked simply as tts_pm, the TTS PM is invoked through the TeMIP
“security wrapper”. This is a script which establishes a user session with an active AC view in
which a TeMIP PM runs. The security wrapper supports the options –u, -a and –i, as
documented in the TeMIP Security Operator’s Guide, section 2.1. The options are described for
the command line utility (FCL) but they work in exactly the same way for the TTS PM. Briefly:
-u selects a TeMIP user profile, when more than one of these are available for the same UNIX
user, -a selects the active AC view, when the user profile contains more than one of these.
The security options can be given anywhere on the tts_pm command line; they will be
consumed by the security wrapper before the command line is processed as described below.
To bypass the security wrapper the TTS PM executable can be invoked directly as
/usr/opt/temip/tts/bin/tts_pm. This does not compromise the security; it just
disables the “wrapper” options.
Command line
If invoked with no arguments the TTS PM runs interactively, reading Tcl commands from
standard input and printing command results to standard output. It runs until the exit command
is evaluated or it reaches end-of-file on standard input (CTRL-D on an empty line in the line
editor).
The shell command line syntax is:
$ tts_pm ?filename? ?arg arg ...?
If TTS PM is invoked with arguments and the first argument is the name of a file, then instead of
reading from standard input the TTS PM will read Tcl commands from the named file and exit
when it reaches the end of the file. When a named script file is used there is no automatic
evaluation of file .ttsrc; if desired, it can be sourced explicitly from within the named script
file.
If Tk is loaded (see section 7.2), Tk options can also be specified as arguments on the command
line.
Unused command line arguments will be passed to the TTS PM in the way which is standard for
Tcl via global variables as described in Table 13.
Table 13, Standard Tcl variables reflecting command line and interactivity
Variable Description
::argc Number of arguments available in argv.
::argv Tcl list whose elements are arguments which are not interpreted as a
script filename or Tk options. Note that Tk options will appear in the
list until the Tk package is loaded.

Variable Description
::argv0 filename argument if present, otherwise the name by which TTS
PM was invoked.
::tcl_interactive 1 (true) if TTS PM is reading commands interactively from a
terminal device through standard input, 0 (false) otherwise.
Initialization
If there exists a file named .ttsrc in the home directory of the user, TTS PM evaluates its
contents as a Tcl script just before reading the first command from standard input (in interactive
mode).
For example, if ~/.ttsrc contains the command:
puts "$tts_version $temip_version"
then the TTS and TeMIP versions will be output before the first prompt.
Executable script file
A TTS script file can be made executable in the standard UNIX way, i.e. by including:
#!/bin/sh
as the first 3 lines of the file 13. Shell command line arguments given to an executable script will
be available in the scripts as described in Table 13.
Alternative application names
An alternative name for the TTS PM application can be created by making a link from the new
application name (e.g. NAN) to the security wrapper:
ln –s /usr/opt/temip/acloc/bin/temip_up_pm NAN
and a link from the new executable to the TTS PM executable:

ln –s /usr/opt/temip/mmexe/tts_pm.exec /usr/opt/temip/mmexe/NAN.exec
and then create a new application instance MCC 0 APPLICATION NAN.

Note
If the TTS PM application is called with the name “tclsh”, it will start as a normal Tcl shell
application with no TTS commands available. This may be used as an alternative to
installing a Tcl kit on the platform.
ln –s /usr/opt/temip/tts/bin/tts_pm tclsh
All commands and packages that are not directly related to TeMIP are still available in the
standard Tcl shell.
7.2 GUI Mode

If the Tcl command
package require Tk
is executed , the TTS PM will load the GUI package for Tcl known as Tk (ToolKit) and
subsequently run in GUI mode with all Tk commands available. Tk options can be specified on
the shell command line, each one as two arguments: a flag beginning with – (dash) followed by
the corresponding value. The following Tk options can be specified: -colormap, -display,
-geometry, -name, -sync, -use, -visual. If the argument -- (2 dashes) appears, this
interpretation of leading dash will not be applied to any arguments in the remaining part of the
shell command line.
13
The tts_pm can not be called directly on Solaris, as it does not allow SUID programs as shell in executable
scripts.

In GUI mode, when the script file is exhausted, TTS PM creates a main window and will then be
event driven. Interactive processing of Tcl/Tk commands is possible also in GUI mode: if no
filename argument is present, TTS PM will read Tcl commands interactively from standard
input. Any received Tcl events are automatically processed; it is not necessary from the script or
interactive commands to call special methods such as vwait or update to achieve this.
In GUI mode TTS PM will continue processing commands until all windows have been deleted
or until an exit command is executed.
The following example code shows a TTS PM script running in GUI mode, monitoring alarm
creation and showing the color coded alarms in the GUIs text widget.
#!/bin/sh
# Init GUI
package require Tk
text .t
.t tag configure no -background white
.t tag configure red -background red
.t tag configure yellow -background yellow
.t tag configure green -background green
pack .t
# Event callback procedure

proc newAlarm response {
array set ep [tts::eventReportToArray [$response get reply {event data}]];
set col no
switch $ep(AO Perceived Severity) {
Warning {set col green}
Minor {set col yellow}
Major {set col red}
}
.t insert end "[array get ep]\n" $col
}
# Setup listen for alarm creation in operation context

set ge [temip::call setup getevent {{oper *} {alarm *}} config]
$ge duration infinity
$ge set request {Events Wanted} {{object creation}}
$ge call function newAlarm
7.3 TTS PM Initialisation

A TTS PM runs as a UNIX process which performs the following tasks as initialization actions
before creating and passing control to the Tcl interpreter:
• License check.
• The process announces itself to the TeMIP framework and an instance of the application
process entity class on the TeMIP self-management interface is created to allow standard
TeMIP control of the process, such as viewing its state and controlling trace output. The
name of the entity is:
MCC director APPLICATION app PROCESS pid
where pid is the UNIX process id of the application process app (default tts_pm).
• The TeMIP dictionary access is initialized.
• The default ACLOC security session is started.
7.4 Line Editing

When a TTS PM is called from a UNIX shell that reads data from a TTY device through
standard input, a line edit facility is active for input and display of Tcl commands typed from the
keyboard. In addition to a number of control characters for editing and positioning within the
current input line, the line editor supports a history list. The active keys and associated functions
are listed in Table 14.
When the TTS PM runs in GUI mode (Tk), line edit is not available. In this case each complete
line as compiled by the tty device driver will be processed.

If TTS PM is called from within another application, for example emacs, it will inherit the driver
used by that application to read and write standard i/o.
Command prompt
When reading Tcl commands from standard input in interactive mode, TTS PM will prompt for
each line to be input. The prompt is:
TTS>
If the Tcl command at the end of the last entered line is incomplete as determined by the Tcl
parser, the prompt is preceded by a double underscore:
__TTS>
Long lines are scrolled and indicated by < and > in start and end of displayed line.
Interactive Tcl event handling
An interactive TTS PM can handle (process) an outstanding Tcl event just before prompting for
input. So if you press “Enter” on an empty line, the next event, if any, will be handled in the
background. If multiple outstanding events shall be handled, then execute the Tcl command
update instead.
The automatic handling of events can be turned on by defining the environment variable
TTS_EVENTHANDLING
set env(TTS_EVENTHANDLING) {}
If the environment variable TTS_SHOWEVENTHANDLING is also set, then a star is printed in

front of the next prompt, if a Tcl event was actually processed.
TTS> set env(TTS_SHOWEVENTHANDLING) {}
TTS> after 10000 {puts {Event test}}
TTS>
TTS>
Event test
*TTS>
By adding these two environment settings to the .ttsrc file, this option can be set for all
interactive uses of TTS PM.
This interactive single Tcl event handling is very useful for debugging code that uses Tcl events
and call-backs, e.g. the tts::remote or asynchronous TeMIP call commands, as you can monitor
each event separately.
Note
Output from the temip::trace or puts commands in the background code will be
displayed just before the next prompt.
Command history
The line editor maintains a command line history, up to 500 lines, that can be accessed by edit
key functions. If TTS PM is exited by CTRL-D the command history is saved in the file
.ttspmhist in the user’s home directory ($HOME). If this file exists when a TTS PM starts,
it is reloaded as the active history.
Table 14, Interactive Line Edit Keys
Key Description
CTRL-A Move cursor to beginning of line.
CTRL-B Move cursor left (back) 1 column. (left-arrow)
CTRL-C Skip the current line, but save in history list.
See also INTR below.
ESC-B Move cursor back one word.
CTRL-D Delete the character under the cursor or exit from TTS PM if empty line (saving the history).
CTRL-E Move cursor to end of line.

Key Description
CTRL-F Move cursor right (forward) 1 column. (right-arrow)
ESC-F Move cursor forward one word.
CTRL-H Delete the character left of the cursor.
CTRL-I Jump to next tab stop.
CTRL-J Use the current line.
CTRL-K Kill from cursor to the end of the line (see ^Y).
CTRL-L Redisplay current line. Adjust to new screen size.
CTRL-M Use the current line. (enter)
CTRL-N Fetches next line from the history list (down-arrow).
CTRL-O Toggle overwrite/insert mode, initially in insert mode.
CTRL-P Fetches previous line from the history list (up-arrow).
CTRL-R Begin a reverse incremental search through history list.
Each printing character typed adds to the search sub-string (initially empty), and the line
editor finds and displays the first matching location. Typing ^R again marks the current
starting location and begins a new search for the current sub-string. Typing ^H or DEL
deletes the last character from the search string, unwinding the search. Typing ESC or any
other editing character accepts the current match and terminates the search.
CTRL-S Begin a forward incremental search through the history list. The behavior is like that of ^R
but in the opposite direction through the history list.
CTRL-T Transpose current and previous character.
CTRL-V Moved to matching {,[,(,},],).
CTRL-U Kill the entire line (see ^Y).
CTRL-Y Yank previously killed text back at current location.
BACKSPACE Delete the character left of the cursor.
DEL Delete the character left of the cursor.
INTR This is normally CTRL-C, but can be changed using the shell command stty.
When Tcl code is running, it will be alerted, if possible (vwait, etc. cannot be alerted). The
Tcl command that was alerted returns the Tcl error “alerted”.
RETURN Use the current line.
TAB Jump to next tab stop.
Note
If a command entered in interactive mode is not recognized as Tcl/TTS command it is
executed as a Unix shell command if possible.

Chapter 8
Management Modules
A general description of the capabilities of a TTS Access or Function module (TTS MM) is
given in section 2.3. This chapter supplements that description with specific reference
information. Chapter 5 shows an example of how to implement a TeMIP AM using TTS.
8.1 Module Naming

Every management module added to a TeMIP system must have a unique name (referred to as
module-name) and code (32-bit unsigned number, referred to as module-id). The name and code
are used to identify the self management class (child of class MCC) of the module and the
application class entity (MCC director application module-name) which is used to control it.
The module-name for a management module, created by customization of a TTS MM, is used as
the name of the module’s TTS script directory (see section 8.4) which contains the files
implementing the module’s behavior.
Typically, a management module will implement a particular global entity class. By convention,
the module-name is then obtained by adding the suffix ‘_am’ or ‘_fm’ to the class name,
depending on whether the module is an AM or an FM. By similar convention, the class code of
the global entity class is reused as module-id. This convention was followed in the example in
Chapter 5. but is not mandatory. A TTS FM can also be used to augment existing classes with
new partitions, verbs (directives) and attributes, without defining it own global class(es).
To ensure global uniqueness, names and codes for modules and classes should be registered
centrally (see section 2.3.5).
8.2 Management Model and Configuration File

The management model which exposes the capabilities of a customized version of a TTS MM
can be freely specified.
TeMIP calls against entities of a management model implemented using TTS MM must be
dispatched into the generic core of the TTS MM and then re-dispatched to the directive scripts
supplied by the customizer. To enable dispatching tables to be built for the second dispatching
step a module configuration file must be supplied when the customized module is enrolled.
The module configuration file must contain a section for each class in the management model
owned by the module. The section consists of a ClassGroup line followed by a VerbGroup line
for each group of verbs supported by the class. If the classes owned by the management module
support different sets of directives (verbs), different class groups must be configured.
The ClassGroup line has the syntax:
ClassGroup = TTSXCG, Class = (class-path), ClassPartitionIds = (partitions)
where class-path is a comma-separated list of the class names encountered in the class
containment tree on the path from the global entity class to the target class, and partitions is
a comma-separated list of codes of attribute partitions supported by the module (i.e. by the
customization of TTS MM). The X can be leaved out or replaced by a digit between 0 and 9,
defining up to 11 different groups.
The VerbGroup line has the syntax:

VerbGroup = verb-group, VerbIds = (verbs)
where verb-group is one of (X is the same as used for the associated class group):
TTSXEG for verbs of type Examine, e.g. Show.
TTSXMG for verbs of type Modify, e.g. Set.
TTSXAG for verbs of type Action, e.g. Create.
TTSXGG for the verb GetEvent. If events are emitted from the configured
class, this must be defined.
and verbs is a comma-separated list of directive codes in the verb group.
Note
The verbs defined using the verb groups are associated with all classes defined by the
associated class group. To be able to define other sets of verbs associated with different
classes, another set of verb classes and verb groups must be selected.
At enrollment and run-time the configuration file for a TTS MM must be present as:
/var/opt/temip/conf/module-name.cfg
The configuration can be checked as describe in 8.7.
Example:
ClassGroup= TTS0CG, Class=(company), ClassPartitionIds=(1, 4)
VerbGroup = TTS0EG, verbIds = (1)
VerbGroup = TTS0MG, verbIds = (2)
VerbGroup = TTS0AG, verbIds = (12, 13)
VerbGroup = TTS0GG, verbIds = (65)
ClassGroup= TTS1CG, Class=(company, employe), ClassPartitionIds=(1)

ClassGroup= TTS1CG, Class=(company, customer), ClassPartitionIds=(1, 2)
VerbGroup = TTS1EG, verbIds = (1)
Development
To accelerate the development cycle, it is recommended that you create a developer's dictionary
and use it until the management and service interfaces for your management module stabilize.
To do this, perform the following steps:
1. Establish a conf directory and define the TEMIP_CONF_LOCATION environment
variable to point to this location, as shown below.
% mkdir conf
% cd conf
% export TEMIP_CONF_LOCATION=`pwd`
% export MCC_DICT_NAME=mcc_fdictionary.dat
You may want to define the TEMIP_CONF_LOCATION environment variable in your

login file so that you always go to your developer's dictionary.
2. Copy the starter developer's dictionary to your conf directory as shown below.
% cp /usr/opt/temip/conf/%L/mcc_dictionary.dat mcc_fdictionary.dat
3. Copy the developer's parse tables and dictionary tree extract as shown below.
% cp /usr/opt/temip/conf/%L/mcc_fdictionary.bpt mcc_fdictionary.bpt
4. Copy the contents of the initial TEMIP_CONF_LOCATION directory into your conf
directory as follows:
% cp /var/opt/temip/conf/%L/* .
5. Invoke the Management Specification Language (MSL) Translator (mcc_msl) and load
your new management and service interfaces for your entity as follows. Be sure you
have write access to the dictionary files and to the directory.
% mcc_msl -I/usr/opt/temip/mmtoolkit/msl mcc_entity_am_srvc_if.ms
% mcc_msl -I/usr/opt/temip/mmtoolkit/msl mcc_entity_am_mgmt_if.ms
6. Rebuild the parse tables file using the mcc_ptb utility:

% mcc_ptb

8.3 Self Management Model
Every TeMIP management model has in addition to the management model also a self
management model which provides basic information about the module itself. The self
management model may also be used to configure a module, for example by setting values for
attributes which modify the behavior of the module.
TTS MM comes with a template MSL source file, located in the directory
/usr/opt/temip/tts/mm/models, for a minimum self management model which
includes the two standard descriptive attributes ‘Component Identification’ and ‘Component
Version’ in the characteristics partition of the un-instantiated self management entity, and with
support for the Show directive on this partition.
The template includes placeholders for the module-name and module-id. Even if there is no need
to define attributes and directives over and above those mentioned in the preceding paragraph a
suitably renamed copy of the template file must be edited to replace these placeholders with
proper values.
The values for the two descriptive attributes can be controlled by the customized module
through the TTS module command which allows values to be set which will be returned by
subsequent calls of Show. It is recommended that these values be set by the OnInit procedure
of the module interpreter (see next section) during module initialization.
8.4 Interpreters and Scripts

All execution of Tcl code is done by Tcl interpreters. A TTS MM process will run several Tcl
interpreters in separate threads. Each interpreter maintains its own set of namespaces for
variables and commands. The TTS commands, including the module command, are available in
all these interpreters and the context command also in the directive interpreters (see below).
Each interpreter has a TTS script file associated. All of the TTS scripts for a module must be
located within the module’s script directory and its sub-directories:
/usr/opt/temip/tts/mm/scripts/module-name
The Tcl interpreters in TTS MM are:
Interpreter Associated Description
thread script file
name
Module Module.tts The module interpreter performs module-wide
initialization and cleanup actions. These actions are
implemented by two parameter-less procedures:
OnInit and OnTerminate, which can optionally be
defined in the script file. These procedures are called
when the module is started and stopped, respectively.
For example, OnInit can use the temip::module
command to define values for informative attributes
which are made available on the self management
interface of the module. Note that OnInit cannot be
used to initialize Tcl variables for the other interpreters.
Master Master.tts The Master interpreter is the only one of the interpreters
which handles Tcl events. After loading its associated
script it enters an event handling loop that allows any
Tcl event to be handled.
All functions which involve waiting for events and then
processing them must be implemented in the Master
interpreter, not in directive interpreters or filter
procedures. A directive or filter interpreter can post a
command to be evaluated by the Master interpreter as
an “eval” event by means of the eval subcommand of
the TTS module command.

Interpreter Associated Description
thread script file
name
If a procedure named OnInit is present in the
Master.tts script it will be called after the script is
loaded as part of the management module initialization.
If a procedure named OnTerminate is present in the
Master.tts script it will be called as part of the
management module termination (when the
management module is stopped).
The Master.tts script OnInit and OnTerminate
procedures is also called in the Master thread associated
with TTS corrective filters (FilterMaster) when the
management module that loads the filters are started
and stopped (see Chapter 9).
Directive ClassGroup- The interpreter for a specific directive. Note that these
name/ scripts are placed in subdirectories under the script
directive- directory of the module, one for each class group that is
name.tts defined in the module configuration file (see 8.2).
E.g. TTS1CG/Show.tts.
See below for further description of directive scripts.
In addition to the scripts listed above a common initialization script for all the interpreters can be
located in the file Common.tts (within the module’s script directory). It can be used to
perform initialization actions that are needed in all the interpreters such as defining common
procedures.
The Master and Module interpreters are created and initialized when the TTS MM module is
started, and the OnInit procedures are called in the scripts if defined.
Initialization of the directive interpreters is deferred until the first time each one is needed to
process a directive call. A new directive interpreter will be initialized for each client (thread)
calling the management module. Whenever a client is terminated or times out
(MCC_RPC_TIMEOUT), the associated directive interpreter will be deleted. This means a
directive interpreter is not necessarily unique to the directive; therefore there should be no
dependence on Tcl variables surviving between calls (except in case of “more” handling).
Initialization of an interpreter is done in 4 steps:
1. The standard Tcl commands are created and Tcl libraries are loaded from:
/usr/opt/temip/tts/lib/tcl8.5/*.
2. The Common.tts initialization script is executed. It does not have access to TTS
commands.
3. The TTS commands, including the module and context commands are created.
4. The script which is specific to the interpreter is executed. The procedures which it defines
(OnExecute, etc.) are not called at this time.
If debugging is turned on for the module (see section 8.5), then step 4 is repeated each time a
directive or filter is called, allowing the script file to be modified between calls.
8.4.1 Directive scripts
The behavior of TeMIP directives is implemented by Tcl procedures defined in dedicated script
files, one per (class group, directive) combination.
Note
This implies that a directive script is common for all classes of the same class group as
defined in the module configuration file.

The directive script files must be installed within class group specific subdirectories of the
module’s script directory:
/usr/opt/temip/tts/mm/scripts/module-name/ClassGroup-name
each one named according to the directive:
directive-name.tts
Example of directive script file name:
/usr/opt/temip/tts/mm/scripts/test_fm/TTS8CG/Show.tts
Note
The module and directive names used to name these directories and files must match exactly
(case sensitive) the display names defined for the management module in MSL. The class
group name must be one of the fixed names defined by TTS (see section 8.2).
A directive script shall contain between one and six Tcl procedures with predefined names to
implement the behavior of the directive. The procedures are all parameter-less. They can all use
the TTS module and context commands to access module-specific information and the call-
context, i.e. call and reply parameters, etc. The example in chapter 5.1 illustrates the use of these
procedures.
The six TTS framework procedures are.
OnInit This optional procedure, if it is present, is called once before any
of the other procedures during the processing of each TeMIP
directive call, i.e. when the handle is “first”. It can be used to
perform initialization which applies to wild-carded calls as well
as calls with a uniquely specified in-entity.
OnExecute This procedure must implement the directive behavior for a call
with uniquely specified in-entity. If the “more” flag is set on a
reply, this procedure may be called multiple times as part of a
single TeMIP directive call, all calls having the same call-
context.
Example:
The following OnExecute procedure implements a directive that

executes a UNIX command given in the call argument
“Command” and returns the result in the response argument
“Result”.
proc OnExecute {} {
temip::context set reply "Result" [
exec [temip::context get request "Command"]
]
}
OnInitialWild This procedure must be present if the call supports wildcarding.

It is called once for each wild-carded TeMIP call at the
beginning of call processing and should set the replycode “No
such entity” if no entity satisfies the wild-carded specification.
Note that wildcarding of in-entity, on any entity class level, must

be handled by the OnInitialWild and OnExecuteWild
procedures defined for the class on the lowest level.
OnExecuteWild This procedure must be present if the call supports wildcarding.
It should process one entity matching the wild-carded
specification each time it is called, set the reply for that entity
and set the “more” flag if there are more entities. The Tcl
interpreter which processes the call of OnInitialWild and
the successive calls of OnExecuteWild will be the same. It is
therefore possible, and typically necessary, to establish a context

for these calls in one or more global Tcl variables, to keep track
of entities already processed and not yet processed, etc.
OnCancel This optional procedure is called when a TeMIP call is cancelled
by the caller before processing has completed. It can be used to
perform cleanup actions, such as close open files, delete
temporary data structures, etc, which would otherwise be done
when the last entity has been processed.
OnDone This optional procedure, if it is present, is called once as the last
procedure during the processing of each TeMIP directive call,
i.e. after a reply was returned without “more” flag or the call has
been cancelled. Possible uses include cleanup of the interpreter
or call summary logging.
If a directive call is alerted (e.g. if a user types Ctrl-C in the FCL utility), the currently executing
Tcl command in OnExecute or OnExecuteWild is terminated and returns the Tcl error
“alerted”.
Note
Commands which can be used to wait for Tcl events (vwait, update and temip::call
wait) are not available in the Tcl interpreters which execute directive procedures, as there is
no Tcl event queue associated with the executing thread.
8.5 Module Command

The TTS module command is available in all TTS scripts executed by a TTS MM, except in the
common initialization script (Common.tts). The command is also available in corrective filter
scripts (procedure OnEvent, see section 2.4 and Chapter 9). It gives access to the module-name
and module-id as defined at enrolment time, and it allows a script to set the values of the
informative attributes on the self management interface of the module.
The module command can also control the debug mode and it has the eval subcommand which
can use to request a command to be executed by the Master interpreter.
temip::module name
returns the module-name defined when the module was enrolled.
If the command is executed in a corrective filter, then the name of the management module that
emitted the event being filtered will be returned.
Example (Trace the module name):
temip::trace trace 0 "Running in [temip::module name]"
temip::module id
returns the module-id defined when the module was enrolled.
Example (Check the module id):
if {[temip::module id] == 12345} {…}
temip::module own ?-codes | -names?

returns a list of classes, attribute partitions and verbs as defined in the module configuration file
(see section 8.2). This is the model entries owned and managed by the module. The class, verb,
entity combinations are as set in the TeMIP dispatch table when the module is enrolled.
The list contains one element for each class managed by the module.
Each element contains a list of 3 elements:
0. The entity class.
1. A list of managed attribute partitions in the class.
2. A list of supported verbs (directives) in the class.
The –names form is default.

Example (Check TeMIP model managed by module):
If called in the example AM in Chapter 5
temip::module own
will produce
{Person {Identifiers Characteristics} {Show}}
temip::module description ?compid?

sets the “Component Identification” self management interface attribute value of the module to
compid. If compid is not present, the current value is returned.
temip::module version set verVal
sets the value of the ”Component Version” self management interface attribute of the module.
The value is specified by verVal, which must be a data value of type Version (see section
6.4.1).
Example (Set module version to V1.0.3):
temip::module version set "V 1 0 3"
temip::module version ?returnDataSpec?

returns the value of the ”Component Version” self management interface attribute of the module
- a data value of type Version - in the form specified by returnDataSpec (see section
6.4.2).
Example (Get current module version):
temip::module version –decode
returns:
V1.0.3
Note that this is the default form of decoding (-names); list form could have been specified by
appending –codes to the command.
temip::module debug ?debugVal?
turns debug mode on or off for the module according to the value of argument debugVal,
which may be any boolean value valid in Tcl. If the argument is not present the command just
returns the current debug mode.
When debug mode is on, directive scripts and corrective filter scripts are sourced at each call,
before their TTS framework procedures are called (see section 8.4).
Example (Turn on TTS debugging in module):
temip::module debug on
temip::module eval arg ...

causes the command specified by the arg arguments to be executed in the Master interpreter
thread (see 2.3.3). The arguments are handled as in the Tcl eval command. The command is
inserted in the Master interpreter’s event queue and evaluated when all events in front of it have
been processed.
The result of the evaluation is returned as the result of the module eval command.
Example:
Call the eval command in a directive thread, but log a message from the Master interpreter after
10 seconds. The eval command returns immediately to the directive thread that will continue
processing Tcl commands while the Master thread waits (Asynchronously).
temip::trace trace 0 TEST1
temip::module eval after 10000 {temip::trace trace 0 TEST2}
temip::trace trace 0 TEST3
logs

2009-04-03-10:14:31[29211][TTSCG/Show_786438] TEST1
2009-04-03-10:14:31[29211][TTSCG/Show_786438] TEST3
2009-04-03-10:14:41[29211][Master] TEST2
8.6 Context Command

The context command is only available in the TTS MM interpreters which execute directive
scripts, not in the Master interpreter. It is used to retrieve values passed as in-entity, call
arguments and attributes by the TeMIP directive call which is being processed (the “present
call”) and to set values to be returned as out-entity, reply arguments and attributes (the
“response”).
temip::context outentity entVal
sets the value of the out-entity. The value is specified by entVal, which must be a data value of
type FullEntity or LocalEntity (see section 6.4.1).
Example (Set out entity for directive reply):
temip::context outentity [list [list MyClass $MyInstance]]
If not set by this command the returned out-entity will equal the in-entity of the directive call. It
must be set to a specific value if the in-entity is wild-carded. Otherwise it is normally not
necessary to set the out-entity.
temip::context inentity ?returnDataSpec?
returns the value of the in-entity of the call context - a data value of type FullEntity - in the
form specified by returnDataSpec (see section 6.4.2). It may be wild-carded, i.e. the entity
name may include wildcard characters.
Example (Check wild-carding type of entity in directive call):
[temip::context inentity -object] show wildtype
temip::context entity ?returnDataSpec?

returns the value of the entity of the call context - a data value of type FullEntity - in the
form specified by returnDataSpec (see section 6.4.2). If the out-entity has been set by a call
of the outentity subcommand, the specified out-entity is returned, otherwise the in-entity.
temip::context partition ?-codes | -names?
decodes and returns the name or code of the partition the directive was called on. If no partition
was specified in the call, the command returns Null or 10. The –names form is default.
Example (Set attribute value only if current partition have id 1):
if {[temip::context partition -codes] == 1} {
temip::context set attribute Name $name
}
temip::context list type ?-all | -available?

retrieves and returns information (not data values) about either the attributes, the request
arguments or the reply arguments associated with the present call as determined by the value of
type, which can be attributes, request or reply.
If the –all argument is present all attributes in the partition of the directive call or all
request/reply augments of the directive are returned, otherwise only those available on the
present call.
The command returns the information in list form. The contents and form of the list is the same
as that described for the list subcommand of the TTS call object described in section 6.10.
temip::context set type id repVal ?reason?
sets the value of a reply attribute or argument of the present call identified by the values of
type, which can be attribute or reply, the latter indicating a reply argument, and id ,
which is the code or name of the specific attribute or reply argument. The value to be set is
specified by repVal, which must be a data value of the type of attribute or reply argument (see
section 6.4.1).

The optional reason for an attribute or argument can be specified by the reason argument,
using name or code according to Table 3.
Example (Set attribute values in directive reply):
temip::context set attribute Age 27 Available
temip::context set attribute Mood {} AttributeNotSet
temip::context get type id ?returnDataSpec?

returns the value of a request attribute or argument of the present call identified by the values of
type, which can be attribute or request, in the form specified by returnDataSpec (see
section 6.4.2). The type of the returned data value is the type of the specified request attribute or
argument.
Attribute arguments are used with modify directives like the Set directive. Request arguments
are used by other directive types, e.g. the arguments for a Create directive.
Example (Get decoded value of attribute “Age” if it is available in the directive request):
set ageObj [temip::context get attribute Age -object]
if {[$ageObj reason] eq {Available}} {
set value [$ageObj decode]
… …
}
temip::context replycode id ?type?

sets the type and code of reply from the present call.
There are three types of reply, indicated by the possible values of the type argument:
Response (default), CommonException and SpecializedException.
If a non-default reply is needed, it is set by specifying the response or exception by its id (name
or code) and type, before adding response or exception arguments.
Note
Any reply argument or attribute values that have been set before the reply code is changed
are cleared.
Note
The default reply of type Response with code 1 is (re)set automatically on entering the
OnExecute or OnExecuteWild procedures. This implies that the replycode
subcommand is only useful within these procedures.
Example (Set common exception reply):

temip::context replycode "No Such Entity" CommonException
temip::context more
sets the handle (more flag) of the call to be conveyed in the reply to indicate that more data is
available. This may be more data from the same out-entity or, for a wild-carded call, data from
additional entities.
temip::context instance ?-all | -last? ?-nonamespace?
returns the identifier value(s) (as string) of the instance(s) in the current entity of the context (in-
entity or out-entity as for entity subcommand). If -all is present a list of all instance
identifiers in the current entity is returned. If –last is present (default) then only the last
instance value is returned. If –nonamespace is present, instance identifiers of type FullName
are returned without prefixed namespace.
Example (Get value of last instance identifier without namespace prefix):
set inName [temip::context instance -last -nonamespace]

Instance identifier values would be a natural choice of index for a database holding instance
information. This command could then be used to extract, in a simple way, the key of the
instance concerned by a call.
temip::context user
returns identity of the caller of the directive in the context as a pair comprising user name and
director name. More information about the user can be retrieved by creating an ACLOC object
and then use the temip::acloc info command, see section 6.12.
Example (Assign name of user and TeMIP director that called directive to variables):
lassign [temip::context user] callUserName callDirectorName
temip::context qualifier type

returns a qualifier of the directive call in the context as a pair comprising the qualifier value and
a reason, the latter being Available or NotAvailable. There are five different types of
qualifiers: user, password, port, domain or account. The desired one is specified by
the type argument.
Example (Verify password if supplied in directive call):
set ok false
lassign [temip::context qualifier password] passwd avail
if {$avail eq {Available}} {
set ok [temip::acloc password $callUserName $passwd]
… …
}
8.7 Module Installation

The general installation process for a TTS MM module is explained in section 2.3.5. This
section gives the exact commands needed for each step, except installation of the script files for
the module.
See TeMIP System Reference Manual Chapter 7 “Extensibility and Enrollment” for further
details on enrolment and application instances.
An example of the install and uninstall process are shown in section 5.2.
Note
Most of the module installation commands require root privileges.
MSL compilation
The following UNIX command will compile the management model and self management
model into the TeMIP dictionary, assuming the current directory is the directory where the MSL
files are located. There is no standard location for this, and the files are not needed again after
compilation.
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl -I/usr/opt/temip/mmtoolkit/msl *.ms
Note
The shell command mcc_msl_extract or the tts_mb demo application may be used to
extract existing model information from the dictionary for edit and compile.
Parse table rebuild

The UNIX command to rebuild TeMIP’s parse table from the updated dictionary is:
Dictionary distribution
On a distributed TeMIP system apply the standard procedure to distribute the dictionary to all
directors and then reload the dictionary on each director.

Enrolling the management module
This step will update TeMIP’s dispatch tables to enable calls to the customized module to be
dispatched to TTS MM. It binds the module-name and module-id to a TTS MM. The scripts
which implement the module’s behavior are not needed at this time. The UNIX shell command
to enroll a TTS MM is:
$ TTS_MM_TYPE=type temip_enroll -m module-name \
-f /usr/opt/temip/bin/tts_mm -i module-id
where type is FM or AM, defining the type of module that is enrolled.

The process up to this point must be repeated if changes are made in the management model.
Checking module configuration
When the management module is enrolled, its configuration file must be installed in the proper
location (see section 8.2). It can then be checked that the configuration file for an TTS MM
agrees with the information in the dictionary, by starting the TTS MM binary application with
the -v option:
$ /usr/opt/temip/bin/tts_mm –v –i <module id>
The output from this command should be inspected for error messages.
The TTS temip::module own command (see 8.5) can also be used later on to check if the
configuration matches the needed class, verb, and partition combinations.
Create application entity
The TeMIP command to create the application entity for the customized module is:
$ manage create MCC 0 application module-name application type = MM, \
filename = /usr/opt/temip/bin/tts_mm
This command does not need to be repeated if the module is reenrolled.

Start module
The module is automatically started when a directive is called on one of its managed classes. For
debugging purposes, to receive standard output to a terminal, the TTS MM can also be started
manually from a UNIX shell command line. In this case the–i option must be included in the
command:
$ /usr/opt/temip/bin/tts_mm -i module-id
Uninstallation
The TeMIP command to stop the management module is:
$ manage stop MCC 0 application module-name
The TeMIP command to delete the application entity is:

$ manage delete MCC 0 application module-name
The UNIX shell command to de-enroll the management module is:

$ temip_enroll -r module-name
The UNIX shell command to remove the management model from the TeMIP dictionary is:
$ /usr/opt/temip/mmtoolkit/bin/mcc_msl –rclass-OID
where class-OID is the OID of the global class of the management model.

Chapter 9
Corrective Filters
A general description of the TTS corrective filter capabilities is given in section 2.4. This
chapter supplements that description with specific reference information.
A corrective filter has two parts:
• A corrective filter entity, e.g. MCC 0 CORRECTIVE_FILTER MyFilter. This
entity defines the events to which the corrective process is applied. One attribute of the
entity specifies the management module which emits the event (by forwarding it to the
event manager) by its application name. Another attribute specifies a discriminator
construct which is applied to the entity against which the event is reported (its out-
entity).
• A corrective process which is applied to the events that passes the constrains, set by the
corrective filter entity.
The TeMIP Event Filtering and Correlation Software Reference Manual describes how to
implement the corrective process by C++ programming. The TTS CF module allows this same
corrective process to be implemented as a TTS/Tcl script.
The script for each corrective filter type must be in a separate file in:
/usr/opt/temip/tts/cf
The file(s) must have the .tts file name extension.

The corrective filter entity (in class CORRECTIVE_FILTER) refers to the script by the name of
the file.
Each such file must contain, as a minimum, a Tcl procedure called OnEvent:
proc OnEvent {args} {
// commands to implement corrective process
}
The file is only sourced the first time the filter is activated and the OnEvent procedure is
thereafter repeatedly called each time the filter is activated.
If debug mode is on - it can be set by calling the debug subcommand of the TTS module
command - the script file is re-sourced each time the filter is activated. See also section 11.5.
The filter TTS code can use all the general low level TTS commands including the module
command (see section 8.5) plus the special event filter command which makes it possible to
manipulate the filtered event, as described in section 9.2.
The event report being filtered is also available as a global TTS data object - of data type
EventReport - called ::event.
All changes made to the current event using the temip::event filter command or by
modifying the ::event object, are applied to the event when the OnEvent procedure
returns. The event is then cascaded to the next low level filter.
If OnEvent returns with a Tcl error, this will be reported in the Additional Text argument of the
event report.
The OnEvent procedure must be defined with arguments if additional argument values are given
in the corrective filter attribute “Parameters”, as described below.

The Common.tts and Master.tts files as described in section 8.4, do also work for corrective
filters. They are sourced when the management module loading the filter (see 9.1) is started.
Here is a complete TTS corrective filter example.
proc OnEvent {} {
temip::event filter set {Additional Text} [
regsub -all {(\n)} [temip::event filter get {Additional Text}] +
]
}
The above filter code changes all new-lines in the “additional text” attribute of an alarm event to
“+” characters.
9.1 Corrective Filter Setup Procedure
Install corrective Filter Script

The script file(s) which implement(s) the corrective process for one or more corrective filters
must be placed in the directory /usr/opt/temip/tts/cf. If any Common.tts or Master.tts
files are used these must also be stored in the same directory 14.
Identify corrective filter library
To add a TTS corrective filter to a management module do as follows:
Update the TeMIP configuration file (if not already done):
/var/opt/temip/conf/.temip_config
with:
TEMIP_EF_USER_LIB=/usr/opt/temip/mmtoolkit/lib/libtemip_ef_user_library.so
TEMIP_EFUL_DIR=/var/opt/temip/conf/eful
Then add the line:
/usr/opt/temip/tts/bin/libtemip_ef_tts_library.so 15
to the file(s):
/var/opt/temip/conf/eful/MM
where MM is the application name of the Management Module which is the source of the
events to be filtered.
It is important to note that the filter libraries are loaded into each of the management modules
specified and that the TTS scripts are initialized and executed in each management module
processes.
The management module(s) must be restarted for the addition of the filters to take effect.
Note
If the TeMIP resynchronization FM (RFM) is used, the text line:

/usr/opt/temip/tts/bin/libtemip_ef_tts_library.so 16
must also be added to the file:
/var/opt/temip/conf/eful/temip_cpl_am
and additional filter entries with target set to temip_cpl_am must be created (see
below). The filter entries may have to be augmented with the DC attribute to
allow only events intended for the specific CF to be handled, as the filter would
else handle all events reemitted by the RFM. The RFM must be restarted to
include the TTS CF.
14
As the scripts are shared, checking for e.g. module name can be included for module specific code.
15
On PA-RISC the library files ends in .sl
16
On PA-RISC the library files ends in .sl

Note
It may be necessary to increase the thread count and stack size for the
management module where the filter is enabled, if the TTS filter code uses many
resources (e.g. using the Oracle Tcl package).
Create corrective filter entity

Two of the characteristic attributes which define a corrective filter instance are used in a special
way for a TTS filter:
Action the value must be temip_ef_tts_library:TTS.
Parameters the first value of the Latin1String Set must be the name of the
filter script file (case sensitive) without the path or .tts
extension. Additional values in the Set will be used as
arguments to the call of the OnEvent procedure in the file, as
described above.
The other two characteristic attributes which are used in the standard way are:
Input Discriminator Construct the discriminator construct used to filter events according to
the entity concerned.
Target the application name of the management module which is the
source of the event, i.e. the value of the identifier attribute of
the MCC APPLICATION entity which describes the
management module.
The corrective filter entity can be created using Iconic Map or the TeMIP command line utility
(FCL/manage) as described in TeMIP Event Filtering and Correlation User’s Guide, section 3.2.
It can also be done using a TTS PM and the high level command temip, as in the following
example, where a pass-all input filter is specified:
TTS> temip create {{mcc 0} {corrective MyFilter}} {
arg
{input {}}
{target MyModule}
{action temip_ef_tts_library:TTS}
{parameters {MyFilterScript}}
}
Example (Calling with arguments):

Write the filter TTS code (MyFilterScript) to take additional arguments:
proc OnEvent {arg1 arg2} {
temip::trace trace 0 "$arg1 $arg2"
}
Create the filter with additional arguments:

TTS> temip create {{mcc 0} {corrective MyFilter}} {
arg
{input {}}
{target MyModule}
{action temip_ef_tts_library:TTS}
{parameters {MyFilterScript {My Argument 1} {My argument 2}}}
}
9.2 Event Filter Command

The event filter command is syntactically a subcommand of the event command which
is described in section 6.11. It can, however, be considered a separate command, for use only
within the OnEvent procedure in a corrective filter script and with its own (second level)
subcommands. This command always implicitly refers to the event which has been filtered and
caused the OnEvent procedure to be called to execute the correction process.

The entity subcommand makes it possible to modify the entity against which the event is
being reported, and the set subcommand can be used to modify the arguments of the event
report.
It is also possible to generate an additional event as a clone of the filtered event; this is done
using the associated subcommand. The cloned event can subsequently be modified and will
be put to the event pool after the original filtered event.
It is not possible to suppress the filtered event. Creating a clone modified to clear the original
event or adding a tag that is filtered and discarded by another low level filter is the closest
possible to this effect.
temip::event filter entity ?entVal?
either retrieves or updates the entity against which the event will be returned (the out-entity of
the GetEvent response).
If entVal is present it must be a data value of type FullEntity (see section 6.4.1). The out-
entity of the filtered event will be updated with this value. If Managed Object field in the event
report is also to be updated, this must be done using the set subcommand.
If entVal is not present the command returns the out-entity, if present, as a decoded
FullEntity data value. If the out-entity is not present the target entity values is returned.
Example (Get and set the event entity):
set entity [temip::event filter entity]
temip::event filter entity $newEntity
temip::event filter targetentity ?entVal?

either retrieves or updates the target entity of the event.
If entVal is present it must be a data value of type FullEntity (see section 6.4.1).
If entVal is not present the command returns the present target entity as a decoded
FullEntity data value.
temip::event filter get argid ?returnDataSpec?
returns the value of an event report argument of the filtered event in the form specified by
returnDataSpec (see section 6.4.2).
If the argument is not available in the event report (but is defined by the dictionary) and the –
decode option is specified (default), an empty value is returned. If the –object option is
specified, the argument is returned with the actual reason values set in the data object.
Example (Get additional text argument from event):
set addtxt [temip::event filter get {additional text}]
Example (Get additional text argument value from event only if it is set):
set addtxtObj [temip::event filter get {additional text} -object]
if {[$addtxtObj show reason] eq Available} {
set addtxt [$addtxtObj decode]
…
}
temip::event filter set argid value ?reason?

updates the value of an event report argument of the filtered event and returns 1 (true) if the
argument had a value already, 0 (false) otherwise.
The argid argument specifies which event report argument by name or code.
The value argument, which must be a data value of the type of the indicated event report
argument (see section 6.4.1), specifies its new value.
The optional reason argument, which must be the name or code of an attribute reason as
specified in Table 3, will cause the specified reason to be associated with the event argument.
The default reason is “Available”.
Example (Set event severity):

temip::event filter set {perceived severity} Critical
Example (Remove argument from event):

temip::event filter set {Additional Text} {} AttributeUnused
Note
The total length of all data set in the event should not exceed ~ 30 Kbytes
temip::event filter alarm

returns 1 (true) if the filtered event is an OSI alarm, 0 (false) otherwise.
Example (Check if event is an OSI alarm):
if [temip::event filter alarm] {
# The alarm filtered is an OSI alarm
…
}
temip::event filter event

returns a list with 4 elements providing information about the filtered event:
• event code
• event OID
• event name
• reply text
as defined in the TeMIP dictionary.
Example (Trace event properties for debugging):
temip::trace trace 0 [temip::event filter event]
may produce 17
2009-04-04-10:17:11[25271] 1806 1.3.12.2.1011.2.22.9.7.202.126.1806 {
Object Creation} {OSI Event : Object Created}
temip::event filter associated

associates a new event with the current filtered event. The name of a new event object is
returned; allowing subsequent modifications to be done to the associated event using the
subcommands of the event command (see section 6.11).
The associated event is a new event with the same event id, event type, event time and managed
object as the filtered event.
The forward subcommand is not available for the associated event; it will automatically be
forwarded after the original filtered event has been forwarded.
Note
All calls of subcommand filter associated, will return with reference to the same
associated event, but not the same TTS event object.
Note
At least one event parameter must be modified (using the set subcommand of the event
object) for the associated event to be forwarded.
Example (Set additional text in associated event):

[temip::event filter associated] set {additional text} {new value}
17
If this trace is included in a CF, it will be logged to the file belonging to the management module that
forwarded the event.

Example (Create a clear for the original event):
set ae [temip::event filter associated]
$ae set {Perceived Severity} Clear
$ae set {Probable Cause} [temip::event filter get {Probable Cause}]
Example (Modify event timestamp of associated event to be 10 seconds after now.):

set ae [temip::event filter associated]
$ae set {Event Time} +00:00:10
$ae timestamp +00:00:10
9.3 Discarded events handling

Events discarded by TeMIP low-level filters, like the TAP filter, can be handled by the TTS
corrective filter library.
If a filter script called DiscardedEvents.tts, with an OnEvent procedure defined, is
found in /usr/opt/temip/tts/cf, the procedure will be called each time an event is
discarded.
The procedure is called with one argument that specifies the FullEntity value of the filter
instance that discarded the event. The available TTS commands and debug handling are the
same as for the corrective filter scripts.
Note
If the event is modified the modification is cascaded to other “discarded events” filters.
Example (Trace discarded events (file: /usr/opt/temip/tts/cf/DiscardedEvents.tts)):

proc OnEvent {filter} {
temip::trace trace 0 "Event $::event discarded by $filter"
}
9.4 Adding user defined fields to the TeMIP Alarm Object

When a new field is added to the Alarm Object class (AO) in TeMIP it is often needed to set this
field value from a corrective filter (CF).
To allow this, the model of the class that emits the alarm (event) must also define the new field.
This is necessary because the AO is "just" a copy of the received alarm (event) fields and the CF
is working on the emitted event, not the AO.
For TTS (and TeMIP) to work properly, it is therefore necessary to define the new event field
and its data type in the dictionary. This will normally mean that the class model (MSL) of the
management modules that implements the GetEvent directive for the filtered alarms needs to be
updated and re-loaded into the dictionary.
A failure to update the management model will in TTS be seen as the error “invalid id”, when
the Id of the AO field is used, instead of the Id of the management module associated event
field.
2008-10-22-17:41:53[21485][cf_test_1] TTS: Error in TTS corrective filter
script 'cf_test.tts'
invalid id 10003
while executing
"temip::event filter get {10003}"
(procedure "OnEvent" line 9)
invoked from within
"OnEvent"

Chapter 10
Remote TTS access
A tts_pm interpreter or the Master interpreter in a tts_mm may be configured to act as a remote
TTS server.
The server allows execution of Tcl/TTS scripts from any remote Tcl interpreter client, including
Tcl/Tk (version 8.5 or later) scripts running on Windows®, Linux, Mac or Windows Mobile®.
10.1 Server
The server TTS side interpreter is initialized by the command:
tts::remote server <port> ?<connect command>? ?<close command>?

where <port> is the (free) port number used for remote connection. The server interpreter must
enter an event serving loop before connections can be honored (E.g. executing the vwait Tcl
command). The optional arguments are described in 10.8 below.
The “server” command returns the name of the listen socket. To stop the services just close this
socket.
10.2 Client connect

The client side Tcl interpreter must include the TTS remote functionality in one of the following
ways:
• Copy the file /usr/opt/temip/tts/lib/tts/TTS.tts to the remote client

system. It can be placed in any directory. Then source this file into the Tcl
interpreter. To source it from the same directory as the Tcl application script is loaded
from, use: source [file dirname [info script]]/TTS.tcl
• Copy the package files /usr/opt/temip/tts/lib/tts/TTS.tts and

/usr/opt/temip/tts/lib/tts/pkgIndex.tcl to the (new) subdirectory
tts in the Tcl package library directory. The Tcl package library directory is specified
in the global Tcl variable ::tcl_pkgPath. 18 Then request the Tts package to be
loaded by executing the Tcl command: package require Tts
The connection to the TTS server can then be established using the command:
tts::remote connect <host> <port> ?<string>?

where <host> is the host (or IP address) name of the host where the server is running and <port>
is the same number as specified for the server. The optional argument is described in 10.8 below.
Any number of clients may connect simultaneously, but each client can only have one
connection. Each connection will have its own private Tcl interpreter (slave 19) running on the
server 20.
18
If you install the package anywhere else, then you must ensure that the directory containing the package is in
the auto_path global variable or an immediate subdirectory of one of the directories in auto_path
19
See http://www.tcl.tk/man/tcl8.5/TclCmd/interp.htm for a description of the “interp” Tcl command and the
concept of slave interpreters.
20
In the same thread as the tts::remote server command was executed

The dedicated slave interpreter exists as long as the client is connected. The client may close the
connection by the command:
tts:remote disconnect
The server can close a connection to the client by executing the exit command in the client
specific interpreter.
10.3 Client eval command

The client interpreter can evaluate Tcl commands in the server interpreter using the command:
tts::remote eval <arg> ?<arg> …?

where the list of arguments is a valid and complete Tcl/TTS command specified in the same way
as the Tcl eval command arguments.
The command returns with the result when the command has been executed on the remote
server. If the command fails, then the eval command also fails with the same error code and
error text as the script returned.
Note
If more than one client executes commands on the server at the same time they may block
each other temporally.
All variables, commands, TTS objects, etc. created by the command, will be stored in the
dedicated interpreter on the server side and can not be accessed locally on the client, only via
new call of the tts::remote eval command from the same client.
Example (Set the variable a in the Tcl interpreter on the server side and return 27 as the result):
tts::remote eval set a 27
Example (Define procedure test in remote interpreter):

tts::remote eval proc test {} {
# A test procedure
}
10.4 Client send command

The client can send Tcl commands to the server using the command:
tts::remote send <script>

This command works in the same way as the “eval” command described above, except that it
only takes a single argument that must include the complete command (script).
10.5 Callbacks
Many times, when working with TeMIP, there is a need for asynchronous event handling (e.g.
alarm handling). In a traditional client-server setup, this is implemented by having the client
waiting for the events in a separate thread. In TTS this is instead implemented as a standard Tcl
callback, allowing the server to push events (commands) to the client.
The code running in the slave interpreter on the server side of a remote connection can execute
commands in the associated client as call backs, using the following command:
tts::notify <arg> ?<arg> …?
The command specified by <arg> … is evaluated as a callback command on the client. Note that
no result from the command is returned to the server interpreter, as the command is executed
asynchronously on the client.
A server side interpreter can only execute commands in its associated client side interpreter
using this command. Not in any other interpreters or clients.
The tts::notify command returns 1 if the command was send to the client and 0 if it was
ignored (callback is off on the client).

The client must allow the server Tcl interpreter to do the call backs using the command:
tts::remote callback on ?disconnect-command?
and disable it by:
tts::remote callback off
If the disconnect-command is specified it is executed (as a callback) when the connection
is disconnected by client or server, except if this happens as a result of a call of eval or send.
In that case the eval or send command return the error disconnected instead.
Example:
On the server side the following Tcl command is executed:
tts::notify set a 27
This will set the global variable “a” in the associated client side interpreter. No result is returned
from the command.
Example:
On the server side a TeMIP directive call is executed as:
$callobject call access {tts::notify callreturn}
This will call the directive specified in the callObject (already defined) and when the result is
returned later (asynchronous) it will notify the client side by calling the procedure “callreturn” in
the client interpreter (with call result argument appended).
Note
This command is only available in a slave interpreter that runs as remote interpreter of a
client connection made by tts::remote connect. Both client and server (Master
interpreter) must handle events (using commands like: update or vwait).
Errors from tts::notify are reported on the client side as background errors.
No errors are returned by this command in the case that the client has set the callback to off.
10.6 Remote file sourcing

A client side Tcl script file may be “sourced” in the server side dedicated slave interpreter by the
command:
tts::remote source <file name>

This may be used to e.g. initialize the remote interpreter after a connection has been made, with
the procedures etc. needed, if these are stored in a separate file.
10.7 Simple example

Server code running in tts_pm on “MyHost” (Background):
tts::remote server 12345

vwait forever
Client code running in e.g. Windows® Tcl shell (Interactive):
$ tclsh
% source TTS.tcl
% tts::remote connect MyHost 12345
%
% # Execute a remote TTS command
% tts::remote send {temip show {{mcc 0}}}
{{{MCC MyHost_ns:.temip.MyHost_director}} Identifiers} {Response {{Show

Success} {Examination of Attributes Shows:}} 2004-11-29-13:14:41 {{Arg Show
Values} {{{Director Name} MyHost_ns:.temip.MyHost_director Available} {{MCC
Local} {} AttributeUnused}}}}

Note
A Tcl alias for the tts::remote send command may be created like this for
convenience:
% interp alias {} remote {} tts::remote send
And used like this:
% remote {temip show {{mcc 0}}}
10.8 Advanced connections

When a client connects to the server it may give an optional connection string that can be used
by the server to verify the client:
% tts::remote connect MyHost 12345 "My connection info"
This string is handed over to the server side as an argument to the servers <connect command>,
if any.
The server may be started with an additional specification of a <connect command> and a <close
command>:
tts::remote server 12345 MyConnectCommand MyCloseCommand
The <connect command> will be called with the following arguments each time a client
connects:
<slave interp> <client host> <client port> <client string>
The <close command> will be called when the client exits again with the following argument:
<interp>
The <slave interp> is the name of the dedicated slave interpreter that executes the client
commands (via tts::remote eval). The interpreter is a slave of the Master interpreter that executes
the <connect command> and the Tcl command interp and its slave commands may be used to
do further initialization of the slave interpreter.
The <client host> is the IP address of the connecting client and <port> is the port it connects
from.
The <client string> is the string specified by the client in it’s connect command. This string
may be used to e.g. identify the client (user, password, etc).
If the <connect command> returns a non-empty string, this is taken as an error message returned
to the connecting client. The connection will in that case be closed (rejected).
10.9 Advanced example

Server Tcl code running in tts_pm (Background):
# Procedure called when client connect

proc OnConnect {interp host port string} {
puts "New client: $host $port $string"
# Create command in slave interpreter that executes
# command in Master interpreter
interp alias $interp masterAlias {} clientAlias
# Define new procedure in slave interpreter

$interp eval {
proc serverCallback {} {
puts "serverCallback procedure in slave called"
tts::notify clientCallback
}
}
# Return “no error” to client connection request
return {}
}
# Procedure defined in the Master interpreter that

# can be called by the slave interpreter

proc clientAlias {} {
puts "Client Alias called"
return {Master procedure called}
}
# Start server
puts "Start server on port 12345"
tts::remote server 12345 OnConnect
vwait forever
Client Tcl code running in e.g. Windows® Tcl shell (Interactive):
$ tclsh
% package require Tts
%
% # Connect
% tts::remote connect MyHost 12345
%
% # Define an alias “remote” for the
% # “tts::remote eval” command
% interp alias {} remote {} tts::remote eval
%
% # Source local file in remote slave interpreter (if needed)
% tts::remote source C:/InitMyServer.tcl
%
% # Define new procedure in remote slave interpreter (server)
% tts::remote send {
proc slaveProcedure {a} {
puts "Client called me"
return "Slave procedure called with $a"
}
}
%
% # Call it
% remote slaveProcedure Test
Slave procedure called with Test
%
% # Call procedure in remote Master interpreter
% # via alias in slave
% remote masterAlias
Master procedure called
%
% # Define local procedure
% proc clientCallback {} {
puts {Server called me}
}
%
% # Enable callbacks from server
% tts::remote callback on
%
% # Call procedure serverCallback on server side
% # This will in turn call clientCallback defined above

% remote serverCallback
%
% # Handle background events
% # (here callback from remote slave interpreter)
% update
Server called me
%
% # Disconnect
% tts::remote callback off
% tts::remote disconnect
10.10 Using secure socket layer connections

The tts::remote command can use the secure socket layer (OpenSSL) available in the Tcl
package “tls”.
To use it, the tls package must first be loaded into the current Tcl interpreter:
package require tls
Then the needed SSL parameters must be set using the command:
tls::init ?options?
Where options is one or more of:

-cadir dir
-cafile filename
-certfile filename
-cipher string
-command callback
-keyfile filename
-model channel
-password callback
-request bool
-require bool
-server bool
-ssl2 bool
-ssl3 bool
-tls1 bool
Refer to the tls manual (http://docs.activestate.com/activetcl/8.5/tls/tls.html) for the definition of

the options.
A description of SSL/TLS and how to generate key pairs and certificates can be found on
http://www.openssl.org/docs/.
Note
The OpenSSL command line utilities (like openssl) and libraries are not part of the TTS
TLS package. These must be available on the TeMIP platform before the SSL connections
can be made.
Example:
On the server side the initialization could be:
package require tls
tls::init -certfile server-pub.pem -keyfile server-priv.key –cafile ca.pem
An on the client side it could be:

package require tls
tls::init -certfile client-pub.pem -keyfile client-priv.key
The tts::remote sub-commands can now be used as described above.

Note that both the client(s) and the server must support SSL for this to work.

Chapter 11
Miscellaneous
11.1 Files
This section gives an overview of the files that are installed as part of TTS.
/usr/opt/temip/bin location for TeMIP commands
tts_pm symbolic link to security wrapper
tts_mm indirect symbolic link to TTS MM executable
/usr/opt/temip/mmexe contains links used by wrappers
tts_pm.exe symbolic link to actual TTS PM executable
tts_mm.exe symbolic link to actual TTS MM executable
/usr/opt/temip/tts/bin actual TTS executables
tts_pm actual TTS PM executable
tts_mm actual TTS MM executable
libtemip_ef_tts_library.so TTS corrective filter library
/usr/opt/temip/tts/lib/* Packages installed with TTS
/usr/opt/temip/tts/lib/tts TTS as package
libtts.so TTS low level commands
TeMIP.tcl TTS high level commands
TTS.tcl TTS support procedures and tts::remote command
pkgIndex.tcl TTS package description (for external install)
/usr/opt/temip/tts/mm/models MSL template files
/usr/opt/temip/tts/mm/scripts TTS AM or FM directive scripts
/usr/opt/temip/tts/cf/ Corrective filter scripts
11.2 Using Tcl Packages

Tcl packages implementing useful functions in many different areas are available in the public
domain and can be incorporated in TTS solutions.
To make the package available within a script, execute the command:
package require package
The following packages are available per default in the TTS kit 21:
• Tts - The TTS commands. Loaded by default in the Master interpreter.
21
The links and references given in this document may not be the official home pages of the Tcl packages.

• Tk - The GUI commands.
Link: http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm
• Expect - Tools for system administration and test automation, as well for automating
other interactive applications.
Links: http://expect.nist.gov, http://www.cotse.com/dlf/man/expect/index.html.
• Tcllib - A collection of standard packages for Tcl. Including HTTP, HTML, JavaScript,
POP3, MIME, Math, TAR, FTP, etc.
Link: http://tcllib.sourceforge.net/doc/.
• Tclx - Extended Tcl is a superset of standard Tcl, including low-level UNIX access and
advanced list manipulation.
Link: http://docs.activestate.com/activetcl/8.5/tclx/TclX.n.html
• Thread - Interface allowing multiple threads, each with one or more Tcl interpreters.
Documentation in: /usr/opt/temip/tts/lib/thread/thread.html
Link: http://ftp.chg.ru/pub/lang/tcl/thread/thread21.html
• Xml - XML Parsing for Tcl (sub packages).
Link: http://tclxml.sourceforge.net/tclxml.html
• dom - Document Object Model For Tcl.
Link: http://tclxml.sourceforge.net/tcldom.html
• SOAP - Tcl commands for SOAP remote procedure calls.
Link: http://tclsoap.sourceforge.net
• Tix - A Tk Interface Extension, enabling OO GUI implementation and advanced
widget sets.
Documentation in: /usr/opt/temip/tts/lib/Tix8.4.3/docs/*.pdf
http://tix.sourceforge.net/docs/html/TixUser/TixUser.html and
http://tix.sourceforge.net/dist/current/man/html/contents.htm
Link: http://tix.sourceforge.net
• Oratcl - A SQL interface to Oracle
Documentation in: http://docs.activestate.com/activetcl/8.5/oratcl/oratcl.html
Link: http://oratcl.sourceforge.net/
Important Note
The environment variable ORACLE_HOME must be specified correctly before the package
is loaded. The environment variable ORACLE_LIBRARY may also need to be set if the
standard Oracle library “libclntsh” is not available.
Values for TeMIP Oracle could be (Check your local Oracle setup):
set ::env(ORACLE_HOME) /usr/opt/temip/oracle

set ::env(ORACLE_LIBRARY) /usr/opt/temip/oracle/lib/libclntsh.so.9.0
• cgi - Make CGI scripts with TTS

Documentation: http://expect.nist.gov/doc/cgi.pdf and
/usr/opt/temip/tts/lib/cgi/refdoc.txt
Link: http://expect.nist.gov/cgi.tcl/
• Tnm - Extensions for network management applications.
Link: http://www.digipedia.pl/man/Tnm.n.html
• tls - Binding to OpenSSL (Secure Socket Layer)
Link: http://docs.activestate.com/activetcl/8.5/tls/tls.html
Note: The libraries libssl.so and libcrypto.so, in 64 bit version, from OpenSSL must be
available on the platform before this package can be loaded (http://www.openssl.org)

• sqlite3 - A self-contained, serverless, zero-configuration, transactional SQL database
engine.
Link: http://www.sqlite.org/tclsqlite.html
Note
Both Tcl/Tk and the described packages include a large number of sub-packages that can all
be loaded using the same “package require” command as described above. See the packages
documentation for details.
To add new package to TTS, install the package as a subdirectory of

/usr/opt/temip/tts/lib and create the package index (if not already available). This
can be done by the Tcl command:
pkg_mkIndex /usr/opt/temip/tts/lib/package
Or follow the build and install description for the package.
Note
TTS runs as binary ELF 64-bit on HP-UX IA64 and SunOS, so loading a 32 bit based
package will fail.
Example (Use the SQlite package to create a database with a table and insert rows into it):
package require sqlite3
sqlite3 db ./testdb
db eval {create table tbl1 (i int, s string)}
db eval {insert into tbl1 (i,s) values (42,'test text')}
db eval {insert into tbl1 (i,s) values (55,'hej')}
lassign [db eval {select i,s from tbl1 where i == 42}] i s
puts "Result: $i - $s"
db close
11.3 Global Tcl Variables

TTS provides information in the global Tcl variables as listed in Table 15.
Table 15, TTS global Tcl variables
::tcl_version Tcl interpreter version (static).
::tts_version TTS release version (static). Only available in tts_pm and Master
interpreters.
::tts_build TTS build revision for bug reporting (static). Only available in
tts_pm.
::tts_library Path name of directory containing TTS library and initialization
commands (static). Only available in tts_pm and Master interpreters.
::tts_interp_id Id of TTS (slave) interpreter when multiple interpreters are running.
Id 0 (zero) is always the first interpreter to be initialized in the
module, 1 the next and so on.
Only available in corrective filter and directive interpreters.
::temip_version Current TeMIP version. Only available in tts_pm and Master
interpreters.
::temip_director Current TeMIP director name. Only available in tts_pm and Master
interpreters.
11.4 Environment variables and TeMIP configuration

Customization of TeMIP by means of environment variables is controlled from the TeMIP
configuration file .temip_config as described in the TeMIP Customization Guide.

A few standard TeMIP environment variables are modified by TTS, overriding their values from
.temip_config:
Time formats
The TeMIP Time format controlling environment variables are changed by TTS in tts_pm and
tts_mm, but may be modified by the user to control the time format. The format is not changed
in a TTS corrective filter and it will follow the format used by the management module that the
filter is loaded into.
TTS uses the following formats:
MCC_TIME_OUT_MODE=2
MCC_TIME_IN_MODE=2
MCC_TIME_ABS_TRUNC=19
Milliseconds can be included in the time format by executing the command:
set ::env(MCC_TIME_ABS_TRUNC) 23
Tracing
The standard TeMIP trace environment is modified as follows:
TFC_DEFAULT_EXCEPTION_TRACE=OFF
MCC_K_TRACE_NO_FORMATTED_HEADER=TRUE
The tracing from TTS includes its own header with timestamp controlled by
MCC_TIME_OUT_MODE and with thread names and ids following the Thread extension
package format.
TTS
The following environment variables are specific to TTS:
TTS_SCRIPTS Root location for TTS MM script files, default value:
/usr/opt/temip/tts/mm/scripts
This may be changed before staring a module, to use scripts from
another location.
TTS_FCL When this environment variable is present, data values of types
FullEntity and LocalEntity are accepted in FCL format. This is not
recommended for scripts, but may be useful for online use. For
scripts, the convert sub-command of data objects should be used
instead.
TTS_MASTER A timestamp set when the TTS Master interpreter thread is started.
TTSCHANNEL Output channel for the temip high level command standard
formatter. Defaults to stdout.
TTSFORMATTER Output formatter used for the temip high level command.
TTS_EVENTHANDLING
Enable interactive event handling in TTS PM (see section 7.4).
TTS_SHOWEVENTHANDLING
Enable display of interactive event handling PM (see section 7.4).
.
Within each Tcl interpreter the current set of environment variables (shared by all Tcl
interpreters and threads in the process) can be read and written through the global Tcl array
variable ::env.
Example (Set environment variable; Allow “manage” formatted entities):
set ::env(TTS_FCL) {}
Example (Remove an environment variable):

unset ::env(TTS_FCL)

11.5 Debugging
This section collects information which is useful when debugging scripted solutions built with
TTS.
Corrective filter considerations
A corrective filter script can be reloaded before each activation, just like a TTS MM directive
script, controlled by the temip::module debug command.
Telnet to a Tcl interpreter
To retrieve information from Tcl interpreters which support event processing, it is possible to
make a telnet connection to it and via Tcl command inspect variables, etc. Incoming telnet
connections must be enabled by the Tcl interpreters which are to accept remote connections (e.g.
the Master interpreter in a TTS MM). This is done by executing the command:
tts::telnet local-port ?prompt?
where local-port is the port that the remote telnet application must connect to, and prompt
is the prompt that will be output to signal readiness to receive a Tcl command. The Tcl
interpreter must be event driven for this connection to work.
Example:
The following code in the (common) Master.tts file will enable telnet servers in the management
modules test_am and person_am with different port numbers and command line prompts.
switch [temip::module name] {
cf_test_pm {tts::telnet 12345 "test_am Master> "}
company_am {tts::telnet 12346 "person_am Master> "}
}
A UNIX shell telnet connection to the Master interpreter 22 in the test_am could look like this.
$ telnet -8 –e c localhost 12345
Trying...
Connected to localhost.dnk.hp.com.
Escape character is '^C'.
test_pm Master> array get env TTS*
TTS_MASTER 2007-08-23-09:28:49 TTS_SCRIPTS /usr/opt/temip/tts/mm
The puts Tcl command writes per default to stdout of the module, not to the telnet consol. So
to write to the telnet connection, use the open Tcl channel saved in the TTSCHANNEL
environment variable.
test_pm Master> puts Hello
test_pm Master> puts $::env(TTSCHANNEL) Hello
Hello
test_pm Master> exit
Connection closed by foreign host.
The Tcl trace command

The Tcl command trace 23 may also be very helpful in debugging a TTS script. It can be used
to trace variable changes and command execution in several ways.
The trace initialization will normally take place in the end of the script to debug.
Note
The trace add command must be executed after the procedure/variable to trace has been
defined and must be repeated if it is redefined.
Example (Set up trace of all commands in a CF call):

proc report {com s} {temip::trace trace 0 "[info level 1] : $com"}
trace add execution OnEvent enterstep report
22
The Master interpreter will run both in MMs created using TTS and in MMs where a TTS CF has been
loaded.
23
Not to be confused with the temip::trace command

11.6 Error handling
Tcl exceptions
Errors in Tcl scripts will result in Tcl exceptions, i.e. violations of Tcl rules or syntax which are
detected at runtime.
Tcl exceptions can be caught, using the Tcl catch command, and handled by outer level code.
If not caught within user the code, a Tcl exception will propagate to where the user code was
executed from: e.g. a command running from a script file, interactively or event driven in TTS
PM, or a call from TTS MM into one of the procedures in a directive script. When a command in
a script produces an unhandled Tcl exception, the script terminates.
All Tcl exceptions which are not caught by user code will print a Tcl error text. Tcl exception
texts are normally printed on stderr of the process where they occur. With a TTS PM
Application started from a command line on a terminal this normally means the exception text
will be visible in the terminal window.
Exceptions occurring in Tcl code evaluated as callbacks triggered by events are called
background errors. Tk includes its own handling of background errors: a special window with
information about the exception is launched. To handle background errors in other contexts such
as a TTS PM not running as GUI or a TTS MM Master interpreter, will require an explicit
background error handler. For this topic, consult a Tcl documentation source.
Example (Catch error):
set errorState [catch {command arg1 arg2} errorText]
if {$errorState != 0} {
# Handle error
……
}
Example (Catch error):
if ![catch {command arg1 arg2} errorText] {
# Command OK
…
} else {
# Handle error
……
}
The Tcl errorInfo variable

When a Tcl exception has occurred, information in addition to the Tcl exception text will be
found in the Tcl global variable ::errorInfo, in the form of a stack trace including useful
information about the failing activity.
To see the information on-line enter the command:
TTS> set ::errorInfo
TTS MM considerations
When an unhandled Tcl exception occurs in a TTS MM during the evaluation of a procedure in a
directive script, the directive call will return the common exception “The requested operation
cannot be completed.”, and a Tcl exception trace is provided in the reply argument
Additional Text.
Management modules built with TTS MM may be started implicitly in which case stdout and
stderr may not be visible, as they are inherited from the process that started the TeMIP
Framework. To make them visible, the TSM MM process can be started from a UNIX shell
prompt in a terminal window (which could be dedicated to this purpose). The UNIX command
for this is:
/usr/opt/temip/bin/tts_mm –i module-id
Using the TTS module command (see section 8.5) a TTS MM can be placed in the debug mode.
In this mode directive scripts are reloaded each time the MM receives a directive call. Also the
Tcl Error Trace bit (see next paragraph) is automatically set in the debug mode.

TeMIP application trace
Unhandled Tcl exceptions in scripts executed by a TTS MM can be reported in the application
trace file. To enable this, the Tcl Error Trace bit (0x8000000000000000) must be set in the
application trace mask and a trace file must be specified.
Example:
temip::trace mask 0x8000000000000000
temip::trace file /tmp/tracefile.log
TTS command exceptions

In addition to the standard Tcl exceptions, the TTS specific commands can also generate errors
related to TeMIP. This includes bad TeMIP data type formats and unavailability of directory
information (e.g. unknown names). The exception text from these errors will generally be the
same as the exceptions that can be thrown from the Visual TeMIP C++ API.
The error stack in variable ::errorInfo will show details of the TeMIP error.
Note
A TeMIP exception returned from a directive call are not handles as a Tcl related error, but
as a TeMIP call return status that can be inspected using TTS commands.

Appendix A
The “temip” high level command
The temip command is intended for interactive use, for example for testing of functionality
implemented with TTS or existing TeMIP modules.
Tcl errors found while executing the command will terminate the execution and return a Tcl
error. Exceptions found as results of the directive call are reported as part of the result and
command execution is done as normal.
The temip command is at same functional level as the directive commands of TeMIP’s FCL
command line utility (“manage”). The basic syntax is however different.
As the temip command does not enforce as many restrictions on calls as FCL, this is not an
operator command, but a command useful for testing.
Important: The temip command should not be used in scripts except in simple cases, as the
performance is not as good as the low level commands.
The temip command has the following syntax:
temip directive entity ?arg ...?
Where:
directive is the id (code or name) of the directive to use in the call.
entity is the entity to call. The entity may be wild-carded. The format of
the entity is the TTS format (see section 6.3).
arg is a list with two elements: key and info, which supplies
arguments, etc. for the call. The argument may be repeated.
The value that can be used for info depends on key as shown in the table below.
The key may be abbreviated.
key info
attribute List of pairs of attribute id and value.
For examine directives (E.g. Show) the value shall be omitted.
event List of event ids.
argument List of pairs of argument id and value.
partition List of attribute partition ids.
all List of attribute partition ids. If omitted, specifies all available partitions (with
all attributes).
any List of event partition ids.
duration Specifies end time as absolute value (BinAbsTime) or relative value
(BinRelTime).
qualifier List of qualifier name and value pairs
formatter Name of result formatter. Defaults to “stdout”, writing directly to tty.
expand Boolean. If false, don't expand global wild-carded entities using the entities
registered with the registration FM. The global level wild-carded entity is given
to the local MM directly.

key info
Default is true.
asynchronous Call the directive asynchronously. Default is false.
variable Name of global or name-space variable to hold result instead of returning it as
result of call.
The result from the formatter will be appended to this variable when each result
is returned.
Works also with asynchronous calls.
Does not work with the built-in “stdout” formatter as there is no return value.
restricted Boolean: test restrictions defined in dictionary, e.g. Attribute Settable. Default is
true.
Setting restricted to false can be used, for example, to test the robustness of new
TeMIP management modules.
This option is not available with the built-in “list” formatter.
compact Boolean: in the built-in “stdout” formatter display only available attributes and
do not format output on multiple lines. Default is false.
retry Boolean: do automatic retry of call on “Retry Requested” error. Default is false.
The contents of this table can be displayed on-line by means of the command:
tts::help temip
Example (Show all identifier attributes of instance MCC 0):

TTS> temip show "{MCC 0}" {all ident}
SHOW Identifiers @ 2004-09-21-09:04:43
Response @ 2004-09-21-09:04:44 from {{MCC x_ns:.temip.x_director}}
Show Success :: Examination of Attributes Shows:
Director Name = x_ns:.temip.x_director
TTS> temip show {{MCC 0}} {all ident} {format list}
{{{MCC x_ns:.temip.x_director}} Identifiers} {Response {{Show Success}
{Examination of Attributes Shows:}} 2004-09-21-09:05:37 {{Arg Show Values}
{{{Director Name} x_ns:.temip.x_director Available} {{MCC Local} {}
AttributeUnused}}}}
Note
If an attribute or argument name contains spaces they must be escaped ( using {}, "" or \ ).
Example (Set an attribute):

TTS> temip set {{MCC 0}} {attribute {{Responsible Person} {My Mother}}}
SET References @ 2004-09-21-09:09:47
Response @ 2004-09-21-09:09:48 from {{MCC x_ns:.temip.x_director}}
Set Complete :: Modification completed successfully
Responsible Person = {My Mother}
Example (Wait for all notification events from a class (stop using CTRL-C)):
TTS> temip getevent {{company *}} {any notif} {duration infinity}
All the normal Tcl syntax, variable and command substitution handling also applies to the temip
command arguments.
Example (All call info in variables):
TTS> temip $directive &entity [list attr [list $attrName $attrValue]]
Example (View current problem list):

TTS> temip view "{transmissionNetwork .demo-net}" {all problemlist}
view ProblemLists @ 2005-04-01-17:13:41 on
alladin_ns:.temip.alladin_director
Response @ 2005-04-01-17:13:42 from {{transmissionNetwork
alladin_ns:.demo-net}}
view Success :: Examination of attributes shows
currentProblemList = {
{

{problem LossOfSignal}
{managedObject {{transmissionNetwork .DEMO-NET} {layer SDHSECTION}
{trail E7907990A}}}
{eventType CommunicationsAlarm}
{eventTime 2005-04-01-17:13:16}
{perceivedSeverity Critical}
{notificationId 113}
{additionalText {Operate: A=DXC799:1-1-1-1, Z=DXC790:1-1-1}}
}
}
Formatter
The formatter controls how the result from a call of command temip is returned.
There are 3 build-in formatters, but the user can write his/her own for special purposes.
The default formatter in interactive mode is called “stdout” and writes the result and errors on
the standard output (the terminal) in an FCL like format. The temip command does in this case
not return any Tcl result.
The standard out channel used by the “stdout” formatter can be changed to any other open Tcl
channel by setting the channel name in the environment TTSCHANNEL.
Example (Redirect output from temip command):
TTS> set ::env(TTSCHANNEL) [open "MyFile" w]
TTS> temip show {{mcc 0}} all
TTS> close $::env(TTSCHANNEL)
All output from the temip call is now in the file MyFile.
The next build-in formatter is called “list” and it returns the result as a return value of the
temip command. Errors are returned as Tcl errors. The list format is the default in non-
interactive mode. The result is a list of entity-values pairs that can be used to assign to an array.
The list is the “raw” result of the temip call and is not processed and formatted as in the “stdout”
formatter.
Example (Get result from temip command into Tcl array):
TTS> array set showResult [temip show {{mcc 0}} all "format list"]
The showResult array index is then a pair of entity and partition values and the array entry value
is the reply values from the entity on the partition.
Example (Show the result from the entity " MCC x_ns:.temip.x_director" in partition Counters
from the call above):
TTS> puts $showResult({{MCC x_ns:.temip.x_director}} Counters)
Response {{Show Success} {Examination of Attributes Shows:}} 2003-06-30-
11:09:50 {{Arg Show Values} {{{Last zeroed} 2003-01-28-09:48:24 Available}
{{Number of remote directors} 1 Available} {{Number of inbound connections}
0 Available} {{Number of outbound connections} 3 Available} {{Number of
inbound messages} 0 Available} {{Number of outbound messages} 59
Available}}}
The default formatter can be changed by setting the environment variable TTSFORMATTER to
the name of the requested default formatter.
set ::env(TTSFORMATTER) list
Makes the list formatter the default.

If the “list” formatter is used, the result can be returned in a user defined variable, by specifying
the “variable” key as a temip command argument.
The third build-in formatter is called “text”. It returns the result as a Tcl return value of the
temip command in the same format as written to stdout by the “stdout” formatter. Any error is
returned as a Tcl error.
User defined formatters
See the description and implementation of the Tcl procedures for the build-in formatters “stdout”
(stdoutTTSFormat), “list” (listTTSFormat) and “text” (textTTSFormat) in the file:

/usr/opt/temip/tts/lib/tts/TeMIP.tcl.
Asynchronous calls
The asynchronous call allows for the call of any number of directives before the responses are
handled.
E.g. call the GetEvent directive asynchronous on a number of different unrelated entities and
then wait for a response from any of the calls.
Note that each pair of entity, partition in the result will be returned as a single response.
The wait can be done using, e.g. the, update, vwait or temip::poll commands.
Example (Asynchronous temip command call):
TTS> temip show {{mcc 0} {appl *}} all {async yes} {var res} {format list}
Asynchronous
TTS> vwait res
TTS> puts $res
{{{MCC x_ns:.x.peony_director} {APPLICATION iconicmap_pm}} Characteristics}
{Response {{Show Success} {Examination of Attributes Shows:}} 2004-09-21-
10:39:43 {{Arg Show Values} {{{Application Type} MM Available} {{Module
Type} Standalone_PM Available} ...
The TTS temip:poll command is just a wrapper around the temip::call wait command,
like this:
namespace eval temip {
proc poll {{timeout 0}} {
while {[call wait $timeout]} {}
}
}

Appendix B
What is TTS Tcl
The dynamic scripting language Tcl (Tool Command Language) used by TTS is a very simple
programming language. If you have programmed before, you can learn enough to write
interesting Tcl programs within a few hours. This chapter provides a quick overview of the main
features of Tcl. After reading this you'll probably be able to start writing simple TTS scripts on
your own; however, we recommend that you consult one of the many available Tcl books for
more complete information.
For online information and documentation you may also visit:
http://tcl.activestate.com/doc/ or http://tcl.tk
Basic syntax
TTS and Tcl scripts are made up of commands separated by newlines or semicolons. Commands
all have the same basic form illustrated by the following example:
expr 20 + 10
This command computes the sum of 20 and 10 and returns the result, 30. You can try out this
example and all the others in this page by typing them to a Tcl application such as tts_pm;
after a command completes, tts_pm prints its result on the terminal.
Each Tcl command consists of one or more words separated by spaces. In this example there are
four words: expr, 20, +, and 10. The first word is the name of a command and the other
words are arguments to that command. All Tcl commands consist of words, but different
commands treat their arguments differently. The expr command treats all of its arguments
together as an arithmetic expression, computes the result of that expression, and returns the
result as a string. In the expr command the division into words isn't significant: you could just
as easily have invoked the same command as
expr 20+10
However, for most commands the word structure is important, with each word used for a distinct
purpose.
All Tcl commands return results! If a command has no meaningful result then it returns an
empty string as its result.
All Tcl commands also returns an exception code, if this is 0 the command executed without
error.
Variables
Tcl allows you to store values in variables and use the values later in commands. The set
command can be used to write and read variables. For example, the following command
modifies the variable x to hold the value 32:
set x 32
The command returns the new value of the variable. You can read the value of a variable by
invoking set with only a single argument:
set x
You don't need to declare variables in Tcl: a variable is created automatically the first time it is
set. Tcl variables don't have types: any variable can hold any value.

To use the value of a variable in a command, use variable substitution as in the following
example:
expr $x*3
When a $ appears in a command, Tcl treats the letters and digits following it as a variable name,
and substitutes the value of the variable in place of the name. In this example, the actual
argument received by the expr command will be 32*3 (assuming that variable x was set as in
the previous example). You can use variable substitution in any word of any command, or even
multiple times within a word:
set cmd expr
set x 11
$cmd $x*$x
Command substitution
You can also use the result of one command in an argument to another command. This is called
command substitution:
set a 44
set b [expr $a*4]
When a [ appears in a command, Tcl treats everything between it and the matching ] as a
nested Tcl command. Tcl evaluates the nested command and substitutes its result into the
enclosing command in place of the bracketed text. In the example above the second argument of
the second set command will be 176.
Quotes and braces
Double-quotes allow you to specify words that contain spaces. For example, consider the
following script:
set x 24
set y 18
set z "$x + $y is [expr $x + $y]"
After these three commands are evaluated variable z will have the value 24 + 18 is 42.
Everything between the quotes is passed to the set command as a single word. Note that (a)
command and variable substitutions are performed on the text between the quotes, and (b) the
quotes themselves are not passed to the command. If the quotes were not present, the set
command would have received 6 arguments, which would have caused an error.
Curly braces provide another way of grouping information into words. They are different from
quotes in that no substitutions are performed on the text between the curly braces:
set z {$x + $y is [expr $x + $y]}
This command sets variable z to the value: $x + $y is [expr $x + $y]

Control structures
Tcl provides a complete set of control structures including commands for conditional execution,
looping, and procedures. Tcl control structures are just commands that take Tcl scripts as
arguments. The example below creates a Tcl procedure called power, which raises a base to an
integer power:
proc power {base p} {
set result 1
while {$p > 0} {
set result [expr $result * $base]
incr p -1
}
return $result
}
This script consists of a single command, proc. The proc command takes three arguments: the
name of a procedure, a list of argument names, and the body of the procedure, which is a Tcl
script. Note that everything between the curly brace at the end of the first line and the curly
brace on the last line is passed verbatim to proc as a single argument. The proc command
creates a new Tcl command named power that takes two arguments. You can then invoke
power with commands like the following:

power 2 6
power 1.15 5
When power is invoked, the procedure body is evaluated. While the body is executing it can
access its arguments as variables: base will hold the first argument and p will hold the second.
The body of the power procedure contains three Tcl commands: set, while, and return.
The while command does most of the work of the procedure. It takes two arguments, an
expression ($p > 0) and a body, which is another Tcl script. The while command evaluates its
expression argument using rules similar to those of the C programming language and if the result
is true (nonzero) then it evaluates the body as a Tcl script. It repeats this process over and over
until eventually the expression evaluates to false (zero). In this case the body of the while
command multiplied the result value by base and then decrements p. When p reaches zero the
result contains the desired power of base. The return command causes the procedure to exit
with the value of variable result as the procedure's result.
Where do commands come from?
As you have seen, all of the interesting features in Tcl are represented by commands. Statements
are commands, expressions are evaluated by executing commands, control structures are
commands, and procedures are commands.
Tcl commands are created in three ways. One group of commands is provided by the Tcl
interpreter itself. These commands are called built-in commands. They include all of the
commands you have seen so far and many more (see below). The built-in commands are present
in all Tcl applications.
The second group of commands is created using the Tcl extension mechanism. Tcl provides
APIs that allow you to create a new command by writing a command procedure in C or C++ that
implements the command. You then register the command procedure with the Tcl interpreter by
telling Tcl the name of the command that the procedure implements. In the future, whenever that
particular name is used for a Tcl command, Tcl will call your command procedure to execute the
command. The built-in commands are also implemented using this same extension mechanism;
their command procedures are simply part of the Tcl library.
When Tcl is used inside an application, the application incorporates its key features into Tcl
using the extension mechanism. Thus the set of available Tcl commands varies from application
to application. There are also numerous extension packages that can be incorporated into any Tcl
application. One of the best known extensions is Tk, which provides powerful facilities for
building graphical user interfaces. Other extensions provide object-oriented programming,
database access, more graphical capabilities, and a variety of other features. One of Tcl's greatest
advantages for building integration applications is the ease with which it can be extended to
incorporate new features or communicate with other resources.
The third group of commands consists of procedures created with the proc command, such as
the power command created above. Typically, extensions are used for lower-level functions
where C programming is convenient, and procedures are used for higher-level functions where it
is easier to write in Tcl.
Strings and Lists
Under Tcl, the value of each variable is stored as a string. Even if you want to save a number in
a variable, this number is transformed into a string.
As a special type of string, the list deserves a special attention in data representation in Tcl. The
list is nothing more than a string with, as elements separator, the white-space. A list may contain
sublists.
Example
TTS> set list {12 {78 5} 45 "I am not a number"}
12 {78 5} 45 "I am not a number"
TTS> set sublist1 [lindex $list 1]
78 5
TTS> set sublist2 [lindex $list 3]
I am not a number
TTS> lindex $sublist2 2
not
TTS> lindex $list 1 1
5

TTS> lindex $list end 0
I
Other features
Tcl contains many other commands besides the ones used in the preceding examples. Here is a
sampler of some of the features provided by the built-in Tcl commands:
• More control structures, such as if, for, foreach, and switch.
• String manipulation, including a powerful regular expression matching facility. Arbitrary-
length strings can be passed around and manipulated just as easily as numbers.
• I/O, including files on disk, network sockets, and devices such as serial ports. Tcl provides
particularly simple facilities for socket communication over the Internet.
• File management: Tcl provides several commands for manipulating file names, reading
and writing file attributes, copying files, deleting files, creating directories, and so on.
• Subprocess invocation: you can run other applications with the exec command and
communicate with them while they run.
• Lists: Tcl makes it easy to create collections of values (lists) and manipulate them in a
variety of ways.
• Arrays and Dicts: you can create structured values consisting of name-value pairs with
arbitrary string values for the names and values.
• Time and date manipulation.
• Events: Tcl allows scripts to wait for certain events to occur, such as an elapsed time or the
availability of input data on a network socket.

Appendix C
The Tcl language syntax.
The following 12 rules define the syntax and semantics of the Tcl language:
[1] Commands.
A Tcl script is a string containing one or more commands. Semi-colons and newlines are
command separators unless quoted as described below. Close brackets are command terminators
during command substitution (see below) unless quoted.
[2] Evaluation.
A command is evaluated in two steps. First, the Tcl interpreter breaks the command into words
and performs substitutions as described below. These substitutions are performed in the same
way for all commands. The first word is used to locate a command procedure to carry out the
command, and then all of the words of the command are passed to the command procedure. The
command procedure is free to interpret each of its words in any way it likes, such as an integer,
variable name, list, or Tcl script. Different commands interpret their words differently.
[3] Words.
Words of a command are separated by white space (except for newlines, which are command
separators).
[4] Double quotes.

If the first character of a word is double-quote (“"”) then the word is terminated by the next
double-quote character. If semi-colons, close brackets, or white space characters (including
newlines) appear between the quotes then they are treated as ordinary characters and included in
the word. Command substitution, variable substitution, and backslash substitution are performed
on the characters between the quotes as described below. The double-quotes are not retained as
part of the word.
[5] Argument expansion.

If a word starts with the string “{*}” followed by a non-whitespace character, then the leading
“{*}” is removed and the rest of the word is parsed and substituted as any other word. After
substitution, the word is parsed again without substitutions, and its words are added to the
command being substituted.
For instance, “cmd a {*}{b c} d {*}{e f}” is equivalent to “cmd a b c d e f”.
[6] Braces.
If the first character of a word is an open brace (“{”) and rule [5] does not apply, then the word
is terminated by the matching close brace (“}”). Braces nest within the word: for each additional
open brace there must be an additional close brace (however, if an open brace or close brace
within the word is quoted with a backslash then it is not counted in locating the matching close
brace). No substitutions are performed on the characters between the braces except for
backslash-newline substitutions described below, nor do semi-colons, newlines, close brackets,
or white space receive any special interpretation. The word will consist of exactly the characters
between the outer braces, not including the braces themselves.
[7] Command substitution.

If a word contains an open bracket (“[”) then Tcl performs command substitution. To do this it
invokes the Tcl interpreter recursively to process the characters following the open bracket as a
Tcl script. The script may contain any number of commands and must be terminated by a close
bracket (“]”). The result of the script (i.e. the result of its last command) is substituted into the
word in place of the brackets and all of the characters between them. There may be any number
of command substitutions in a single word. Command substitution is not performed on words
enclosed in braces.
[8] Variable substitution.

If a word contains a dollar-sign (“$”) followed by one of the forms described below, then Tcl
performs variable substitution: the dollar-sign and the following characters are replaced in the
word by the value of a variable. Variable substitution may take any of the following forms:
$name
Name is the name of a scalar variable; the name is a sequence of one or more characters that are
a letter, digit, underscore, or namespace separators (two or more colons).
$name(index)
Name gives the name of an array variable and index gives the name of an element within that
array. Name must contain only letters, digits, underscores, and namespace separators, and may
be an empty string. Command substitutions, variable substitutions, and backslash substitutions
are performed on the characters of index.
${name}
Name is the name of a scalar variable. It may contain any characters whatsoever except for close
braces.
There may be any number of variable substitutions in a single word. Variable substitution is not
performed on words enclosed in braces.
[9] Backslash substitution.
If a backslash (“\”) appears within a word then backslash substitution occurs. In all cases but
those described below the backslash is dropped and the following character is treated as an
ordinary character and included in the word. This allows characters such as double quotes, close
brackets, and dollar signs to be included in words without triggering special processing. The
following table lists the backslash sequences that are handled specially, along with the value that
replaces each sequence.
\a Audible alert (bell) (0x7).
\b Backspace (0x8).
\f Form feed (0xc).
\n Newline (0xa).
\r Carriage-return (0xd).
\t Tab (0x9).
\v Vertical tab (0xb).
\<newline>whiteSpace
A single space character replaces the backslash, newline, and all spaces and tabs after the
newline. This backslash sequence is unique in that it is replaced in a separate pre-pass before the
command is actually parsed. This means that it will be replaced even when it occurs between
braces, and the resulting space will be treated as a word separator if it is not in braces or quotes.
\\ Backslash (“\”).
\ooo
The digits ooo (one, two, or three of them) give an eight-bit octal value for the Unicode
character that will be inserted. The upper bits of the Unicode character will be 0.
\xhh
The hexadecimal digits hh give an eight-bit hexadecimal value for the Unicode character that
will be inserted. Any number of hexadecimal digits may be present; however, all but the last two

are ignored (the result is always a one-byte quantity). The upper bits of the Unicode character
will be 0.
\uhhhh
The hexadecimal digits hhhh (one, two, three, or four of them) give a sixteen-bit hexadecimal
value for the Unicode character that will be inserted.
Backslash substitution is not performed on words enclosed in braces, except for backslash-
newline as described above.
[10] Comments.
If a hash character (“#”) appears at a point where Tcl is expecting the first character of the first
word of a command, then the hash character and the characters that follow it, up through the
next newline, are treated as a comment and ignored. The comment character only has
significance when it appears at the beginning of a command.
[11] Order of substitution.

Each character is processed exactly once by the Tcl interpreter as part of creating the words of a
command. For example, if variable substitution occurs then no further substitutions are
performed on the value of the variable; the value is inserted into the word verbatim. If command
substitution occurs then the nested command is processed entirely by the recursive call to the Tcl
interpreter; no substitutions are performed before making the recursive call and no additional
substitutions are performed on the result of the nested script.
Substitutions take place from left to right, and each substitution is evaluated completely before
attempting to evaluate the next. Thus, a sequence like:
set y [set x 0][incr x][incr x]
will always set the variable y to the value, 012.
[12] Substitution and word boundaries.

Substitutions do not affect the word boundaries of a command, except for argument expansion as
specified in rule [5]. For example, during variable substitution the entire value of the variable
becomes part of a single word, even if the variable's value contains spaces.

3dn00801iaaadezza v1 Alcatel-Lucent 1300 XMC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3dn00801iaaadezza v1 Alcatel-Lucent 1300 XMC

Uploaded by

Copyright:

Available Formats

HP TeMIP Software

TeMIP Tcl Scripting

for PA-RISC Unix Operating System

© Copyright 2011 Hewlett-Packard Development Company, L.P.

License Requirement and U.S. Government Legend

Restricted Rights Legend

Open Source proposals

TeMIP Integration Tools - TTS Page 5 of 136

DOCUMENT INFORMATION ...................................................................................4

PART I TTS PRIMER..............................................................................................11

CHAPTER 1 INTRODUCTION ...............................................................................12

CHAPTER 2 CAPABILITIES OVERVIEW ..............................................................14

2.1 Common Capabilities ........................................................................................................................... 14

2.2 Presentation Module Capabilities ....................................................................................................... 18

2.3 Management Module Capabilities ...................................................................................................... 20

2.4 Corrective Filter Capabilities .............................................................................................................. 23

CHAPTER 3 TTS COMMANDS..............................................................................25

3.1 High Level Commands ......................................................................................................................... 25

3.2 Low Level Commands and TTS objects ............................................................................................. 26

3.3 High level commands v. low level command example ....................................................................... 32

CHAPTER 4 SUGGESTED USES OF TTS ............................................................33

4.1 System Configuration Scripts .............................................................................................................. 33

4.2 Information Extract and Presentation................................................................................................ 33

4.3 Simple GUI ............................................................................................................................................ 34

4.4 Web Server ............................................................................................................................................ 34

4.5 Automatic Alarm Acknowledge .......................................................................................................... 34

4.6 Northbound Integration ....................................................................................................................... 34

4.7 Alarm Mapping .................................................................................................................................... 35

Page 6 of 136 TeMIP Integration Tools - TTS

4.9 Importing Data to TeMIP Entities ...................................................................................................... 35

4.10 Combined Inventory and Element Information Retrieval................................................................ 35

4.11 Director-to-Director Integration ......................................................................................................... 36

4.12 Corrective Filter ................................................................................................................................... 36

CHAPTER 5 EXAMPLE AM .................................................................................. 37

5.1 Management Module person_am ........................................................................................................ 37

5.2 Installing the example AM ................................................................................................................... 40

5.3 Viewing Person Dictionary and Data Using a TTS PM .................................................................... 41

5.4 Raising TeMIP alarms from the example AM ................................................................................... 43

PART II TTS REFERENCE MATERIAL ................................................................ 44

CHAPTER 6 TTS COMMANDS REFERENCE INFORMATION ............................ 45

6.1 TTS Module Application and Process Entities .................................................................................. 45

6.2 TTS Objects .......................................................................................................................................... 45

6.3 Data Types and Formats ...................................................................................................................... 49

6.4 Data Value Specification and Representation .................................................................................... 54

6.5 High Level Commands ......................................................................................................................... 55

6.6 Trace Command ................................................................................................................................... 59

6.7 Dictionary Information and OIDs....................................................................................................... 61

6.8 Dictionary Command and Object ....................................................................................................... 62

6.9 Data Command and Object ................................................................................................................. 66

6.10 Call Command and Object .................................................................................................................. 73

6.11 Event Command and Object ............................................................................................................... 81

6.12 Acloc Command and Object................................................................................................................ 84

6.13 MIR Command and Object ................................................................................................................. 86

TeMIP Integration Tools - TTS Page 7 of 136

7.1 Command Line and Script File ........................................................................................................... 91

7.2 GUI Mode .............................................................................................................................................. 92

7.3 TTS PM Initialisation........................................................................................................................... 93

7.4 Line Editing ........................................................................................................................................... 93

CHAPTER 8 MANAGEMENT MODULES ..............................................................96

8.1 Module Naming .................................................................................................................................... 96

8.2 Management Model and Configuration File ...................................................................................... 96

8.3 Self Management Model ...................................................................................................................... 98

8.4 Interpreters and Scripts ....................................................................................................................... 98