Enterprise Console
Enterprise Console
Enterprise Console
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Table of Contents
Introduction.............................................................................................................................................. 3
Feature Overview .................................................................................................................................... 3
Using TEC Monitor .................................................................................................................................. 4
Launching TEC Monitor ....................................................................................................................... 4
Customising TEC Monitor .................................................................................................................... 5
Introduction .......................................................................................................................................... 5
[Link] ............................................................................................................................. 6
Configuration ........................................................................................................................................... 7
Introduction .......................................................................................................................................... 7
[Link].......................................................................................................................................... 7
[Link]............................................................................................................................... 8
[Link] ..................................................................................................................................... 8
[Link]............................................................................................................................ 8
TEC and Events................................................................................................................................... 9
Details of [Link]........................................................................................................................ 10
Modifying profiles On the Fly........................................................................................................... 10
Application Design................................................................................................................................. 11
Data Production ................................................................................................................................. 11
[Link] .................................................................................................................................... 11
[Link] ................................................................................................................... 12
Worked Example................................................................................................................................ 13
TecPack................................................................................................................................................. 15
How does TecPack get built? ........................................................................................................... 15
What does TecPack contain? ............................................................................................................ 15
Sending TecPack Data to Temenos Support .................................................................................... 15
Appendices............................................................................................................................................ 16
Appendix 1 API Definitions ............................................................................................................. 16
Appendix 2 Worked example - Adding Custom Time Items to TEC ............................................ 17
Appendix 3 Worked Example Adding other custom items to TEC ............................................... 20
Introduction
The T24 Enterprise Console (TEC) is a comprehensive system management framework, built to
internet standards, which provides a robust console, a rich set of tools, and the ability to detect, solve,
and simplify the full range of problems that can arise in any managed environment.
TEC is based upon a lightweight architecture with minimal impact to your T24 installation, allowing T24
users to monitor every aspect of performance and behaviour of their T24 environments by defining a
monitoring profile that reports on the use and activity of the system.
Menus and graphical displays with full drilldown and investigative facilities ensure that the information
is easily accessible, and includes the ability to store this information historically for reporting purposes,
as well as the full help and documentation you would expect from T24.
The TecPack extracts details on T24 performance, which are gathered automatically by the system,
and can be sent data back to Temenos for analysis. Temenos client services (support) can then
monitor T24 health and, therefore, be more pro-active in implementing solutions before the problem
becomes critical.
Standard T24 tools are used to build the TEC display. The composite screens, widgets, enquiries and
versions allow the features, display and workflow to be tailored to your requirements.
Feature Overview
Through the TEC monitor, the TEC offers a summary view of the T24 system in the following areas:
Introduction
The TEC Monitor uses the Workspace and Widgets functionality to define the content and layout of
the monitor. Content may be added from the TEC Monitor widget itself, or from the standard Widget
List.
Each Widget can be repositioned and resized by dragging and dropping the widget, or by grabbing the
resize handle at the bottom right of each widget. The whole screen automatically refreshes every
minute.
For full details, refer to the Workspaces and Widgets section of the Browser User Guide.
[Link]
In addition, the TEC monitor widget itself has a standard extension point (defined in [Link]) to add
items into the TEC monitor widget itself. An example is shown below:
SUBROUTINE [Link](responses,request)
!* Example [Link] subroutine
* @return responses A dynamic array or items to add to [Link]
* @param request Information passed in from [Link]
*!
*--------------------------------------------------------------------------
$INSERT I_TEC.[Link]
*--------------------------------------------------------------------------
responses = ''
response = ''
response<apiNames> = 'Custom Item' ; * The Name of the item to add
response<apiValues> = '27' ; * The value
response<apiDrills> = '' ; * Drilldown item, e.g. ENQ [Link] [Link] EQ SECUIRTY
response<apiTypes> = '' ; * Type of the drilldown. Normally CMD
response<apiImages> = '' ; * Any Image to display with the item
responses<-1> = LOWER(response)
response = ''
response<apiNames> = 'Other Custom Item' ; * The Name of the item to add
response<apiValues> = '28' ; * The value
response<apiDrills> = ''
response<apiTypes> = '' ; * Type of the drilldown.
response<apiImages> = '' ; * Any Image to display with the item
responses<-1> = LOWER(response)
*--------------------------------------------------------------------------
RETURN
Configuration
Introduction
The TEC is not controlled by phantoms, services or other background processes, but is an inherent
part of the T24 code base. The TEC starts monitoring activities when a user logs in or when a service
is initiated and stops monitoring when the user logs off of when the service terminates.
The lowest level of configuration is the [Link] table, where items that may be monitored are
defined. Multiple [Link] are combined into a [Link] to determine which metrics to
monitor. In addition, default [Link] are automatically added to the [Link]. To activate a
[Link], the record should be verified.
NB It is not necessary to define a [Link], as the default profile is always active.
[Link]
This is the main table where all the items that may be monitored are defined. Here, the definition of the
severity of a particular item is defined.
In the below example, a response time of less than 1000 milliseconds will assign a severity of INFO,
and a response time of greater than or equal 1000 milliseconds, but less than 3000 will assign a
severity of WARNING. Response times of 3000 milliseconds or greater will be flagged as critical. The
severity levels are used in the various TEC reports and enquiries.
[Link]
This table defines severity levels that are used by [Link]. There are three default records,
though additional thresholds may, of course, be defined. The standard thresholds are:
Information
Warning
Critical
[Link]
This is the table where we can specify the specific items that we wish to monitor and the list of users
for which they need to be monitored.
Once a record with the necessary items to be monitored are specified in the [Link], the
record needs to be verified in order for the record to be made as an active profile. Verifying a record in
the [Link] will write the verified record into the [Link] file. It is this file that the
TEC will refer to in order to obtain the items to be monitored (active items).
To make a given profile the active profile, the record should be verified:
[Link]
This is a work file that holds the currently active profile. This file is automatically updated when the
[Link] is verified.
Details of [Link]
[Link] Description Always on
[Link] Response time for API call
[Link] Enquiry build response time
[Link] Count of file opens
[Link] Size of opened files
[Link] Count of Lock Collisions 9
[Link] Response times for record read
[Link] Size of read records that have been read 9
[Link] Select response time
[Link] Response time for utility requests made to 9
T24 to service browser requests, e.g.
menu screens, enquiry selection screens,
etc.
[Link] Response time for clearing messages. 9
N.B. multiple clearings transactions per
message
[Link] Total response time (including OFS and all 9
processing) for a transaction commit. The
is a super set of the metric
[Link]
[Link] Total response time (including OFS and all 9
processing) for An enquiry request. The is
a super set of the metric [Link]
[Link] Total response time (including OFS and all 9
processing) for a transaction validate
requests
[Link] Throughput metrics for a given service 9
(either online or CoB) showing throughput
per minute.
[Link] Total response time (including OFS and all 9
processing) for any other OFS requests.
[Link] For j4 / JR database, the number of frames 9
accessed before the record was found.
Requires Jbase 5.
[Link] Transaction commit response time, i.e.
from commit processing until database
update. Does not include time spent in
OFS
[Link] Response time for record write
[Link] Size of written records
Application Design
Data Production
The TEC enquiries build data from the [Link] file that has a similar structure to the
[Link] file. As the data in the [Link] file is bound to change rapidly, the TEC enquiries
transfer the data from the [Link] file to the [Link] file. The [Link] file is
always cleared before data is placed into it.
The controlling factor of the TEC enquiries is the [Link] field in the [Link]. This
field specifies the time with in which, if a TEC enquiry is executed, the data in [Link] will not
be rebuilt. The default value of this field is 15 seconds.
The TEC enquiries display data that correspond to the THRESHOLDs that we specify in the
[Link]. Let us understand this with a simple example:
[Link]
File Type : L File Classification : INT
[Link]
Session Number : Whenever the user logs in, the initial initialisation process of the TEC environment
is performed. It loads the active profile from [Link] on to the memory and also reads the
[Link] table with the id [Link]. This record contains a sequence number,
which is incremented by one and written back into the [Link] table. This incremented number is
the first part of the [Link] table. The field [Link] in the [Link] table allows us
to set the maximum value that this session number can hold. For example, if this is set to 50, once the
session number crosses 50, it will automatically be reset to 1.
LogSetNumber : Making the [Link] file store all the activities for ever could be very
expensive on storage space. Therefore, the [Link] file has been built with a self-cleaning
mechanism. There are 2 fields that control this in the [Link] table namely, [Link] (the
number of log sets to maintain) and [Link] (the number of seconds after which the data will be
flushed from the memory to the disk).
[Link]
All items are automatically consolidated into the historic TEC data store. The layout of this data is:
Worked Example
Let us understand the working of the TEC using a simple example. Assume that the following record is
created in the [Link] table and verified:
So, the only item that we wish to monitor is the time taken for every [Link] to be executed. When the
user INPUTTER signs on, the active profile in the [Link] gets loaded on to the memory.
The load routine will then check to see if the current user needs to be monitored and monitor only if
the current signed on user name is specified in active profile ([Link] record). If the user
performs an activity that invokes an [Link], (e.g. typing CUSTOMER L), find below the sample data
that could be written on to the [Link] file for the [Link] item.
[Link]
Session Number : Whenever the user logs in, the initial initialisation process of the TEC environment
is performed. It loads the active profile from [Link] on to the memory and also reads the
[Link] table with the id [Link]. This record contains a sequence number,
which is incremented by one and written back into the [Link] table. This incremented number is
the first part of the [Link] table. The field [Link] in the [Link] table allows us
to set the maximum value that this session number can hold. In our case it is set to 50. Hence, once
the session number crosses 50, it will automatically be reset to 1.
LogSetNumber : Making the [Link] file store all the activities for ever could be very
expensive on storage space. Therefore, the [Link] file has been built with a self-cleaning
mechanism. There are 2 fields that control this in the [Link] table namely, [Link] (the
number of log sets to maintain) and [Link] (the number of seconds after which the data will be
flushed from the memory to the disk). In our case, these 2 fields have the following values:
[Link] : 5
[Link] : 60
For the first time after the user signs on or when the COB is initiated, when activities gets recorded,
the log set number is set to 1 and therefore the records with the following ids will be formed:
[Link]
Once the data gets flushed from the memory to the [Link] file, the log set number is
incremented (by one). Hence, the activities that get recorded after the first flush of data to the
[Link] table will have the following id:
[Link]
Since we have set the [Link] to 5 in the [Link], once the log set number crosses 5, it
would get reset 1. Once the log set number gets reset to 1 data in the [Link] file will start
getting overwritten. What this means to us is, if we set [Link] to 5 and [Link] to 60, we
would at any point in time have the activities performed by a user in the last 5 minutes.
TecPack
A COB job produces the file TecPack - which is a jBASE file (regardless of the target database for T24
data) stored in the main data account (specified in the SPF). It is overwritten everyday and contains
the following information:
Appendices
Appendix 1 API Definitions
[Link] and [Link]
These APIs are used to log items that have a metric type of TIME.
[Link] ([Link], [Link])
Where:
[Link] Used to identify the [Link] that is being logged. Can be left blank if the
routine is to be used to calculate the execution time of a routine. If it is going
to be used to calculate the read/write time per transaction, then it needs to
hold the transaction reference.
[Link] Used to identify the item such that the timer can subsequently be stopped
using the [Link] API.
[Link] Will hold the detail level information on the item that you are recording.
Example:
[Link] = [Link]
[Link] = [Link]
CALL [Link]([Link], [Link])
CALL [Link]([Link], [Link],[Link])
[Link]
This API is used when items of any metric type other than time needs to be measured.
[Link]([Link],[Link],[Link],[Link])
Where:
[Link] Item name
[Link] Id of the record if the routine is used to measure the size of a record/Descriptive String
[Link] Name of the file on which the read/write/select is being performed
[Link] Size of the record/element being measured
OFS Syntax
For full details refer to the OFS User Guide.
SUBROUTINE [Link]
$INSERT I_COMMON
$INSERT I_EQUATE
MSLEEP(1000) ; * Sleep for 1000 milliseconds (i.e.) 1 second
RETURN
END
[Link] Creation
Create an item in the [Link] file so that it can be used to monitor your subroutine.
[Link]
Create a new record in [Link] and add this item to it. Alternatively, you could add the custom
item to any one of the existing records in the [Link] table.
[Link]
[Link] 50
Modify code
In order to monitor the above-mentioned subroutine, the subroutine needs to call the
[Link] and the [Link] routines.
SUBROUTINE [Link]
$INSERT I_COMMON
$INSERT I_EQUATE
response =
CALL [Link](,TRAINING.TEST1)
MSLEEP(1000)
CALL [Link](,TRAINING.TEST1,response)
RETURN
END
Check Results
Now verify the [Link] record, log in, execute the routine (remember to make an entry in the
[Link] with [Link] set to M in order to execute the routine as a mainline routine). Check the
[Link] to view the recorded activity.
ID [Link].TEST1
[Link]
[Link] TRAINING.TEST1
THRESHOLD
[Link] 1
[Link]
[Link] 1
[Link] 1001
[Link]
[Link] 1001
[Link]
[Link]
APPLICATION [Link]
[Link] 37685413
[Link] 37716
SUBROUTINE [Link]
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
[Link] = [Link]
[Link] =
[Link] =
[Link] =
[Link] = 0
CALL OPF([Link],[Link])
[Link] = SELECT :[Link]
CALL [Link] ([Link],[Link],,[Link],[Link])
RETURN
END
[Link] Creation
Create an item in the [Link] file so that it can be used to monitor your subroutine.
[Link]
Create a new record in [Link] and add this item to it. Alternatively, you could add the custom
item to any one of the existing records in the [Link] table.
Modify Code
In order to calculate the size of the selected is the [Link] routine needs to be used.
Change the above subroutine to include a call to [Link]. Now modify the routine to
call [Link]:
SUBROUTINE [Link]
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
[Link] = [Link]
[Link] =
[Link] =
[Link] =
[Link] = 0
CALL OPF([Link],[Link])
[Link] = SELECT :[Link]
CALL [Link]([Link],[Link],,[Link],[Link])
CALL [Link](TRAINING.TEST2,Size of selected list,[Link],
LEN([Link]))
RETURN
END
Check Results
Now verify the [Link] record, log in, execute the routine (remember to make an entry in the
[Link] with [Link] set to M in order to execute the routine as a mainline routine). Check the
[Link] to view the recorded activity.