Vous êtes sur la page 1sur 14
TEMENOS T24 TSA Service User Guide Information in this document is subject to change without notice.

TEMENOS T24 TSA Service

User Guide

Information in this document is subject to change without notice.

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.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Table of Contents

Introduction

3

Writing the service routines

3

 

Service routines

3

 

3

.SELECT

4

.LOAD ...............................................................................................................................................

4

I_…COMMON ..................................................................................................................................

4

Data records

5

 

Initiate the Service

6

Batch Output

12

Error

Handling

13

Error Messages

14

Introduction

TSA services were created to replace phantoms and are run as background processes. This guide lists the routines and T24 records that need to be produced in order to create and run a TSA service. The example used in this guide is an existing service created to process OFS messages via API hooks in T24.

Writing the service routines

3 routines are needed. Standard routine names must be adhered to when naming the routines for TSA Services. In the below example a T24 API hook writes OFS messages to the F.OFS.MESSAGE.QUEUE file by calling the OFS.POST.MESSAGE routine. These OFS messages are then picked up by the TSA service, OFS.MESSAGE.SERVICE and processed via OFS.

OFS.POST.MESSAGE is called with the following arguments:

OFS message

OFS message ID – this is null when OFS.POST.MESSAGE is called and returns the ID to the F.OFS.MESSAGE.QUEUE file.

Key to OFS.SOURCE file

OPTIONS – to be used at a later stage.

Service routines

Main service routine

A service routine, called OFS.MESSAGE.SERVICE as an example, contains one argument, which receives the ID to the record selected from the service select routine, in this example the ID will be to the F.OFS.MESSAGE.QUEUE file. The name of the service should remain constant throughout the naming of the below routines. The reading of and any processing to the individual record is done in this routine. This routine generally contains the services common insert file.

.SELECT

A routine ending in .SELECT, EG. OFS.MESSAGE.SERVICE.SELECT, sets up the files and select statements used to select records from the relevant service file, F.OFS.MESSAGE.QUEUE in this example.

The common variable, LIST.PARAMETER, is passed through to BATCH.BUILD.LIST in the first argument and contains the following:

LIST.PARAMETERS<1> = List file name or null if we're using a list from the pool

LIST.PARAMETERS<2> = Extract file name (F

we open) EG. FN.OFS.MESSAGE.UQEUE

... LIST.PARAMETERS<3> = Extract selection criteria (if any) LIST.PARAMETERS<4> = Last key to the list file - used for multiple calls to BBL LIST.PARAMETERS<5> = Total number of keys to process LIST.PARAMETERS<6> = Number of contracts to bulk (separated by *) - default 1 LIST.PARAMETERS<7> = if set to filter, a filter, JOB.NAME.FILTER is called

ID.LIST = List of keys to be stored in the list file This variable is passed through to BATCH.BUILD.LIST in the 2 nd argument

.LOAD

A .LOAD routine, as in OFS.MESSAGE.SERVICE.LOAD, is written to load any common variables used throughout the service. This routine also opens all files needed for the service.

The 3 routines above are automatically called and run in the correct order via the TSA.

I_…COMMON

COMMON routine can be written to include any common variables for the service. EG, I_OFS.MESSAGE.SERVICE.COMMON, will contain the OFS.MESSAGE.QUEUE file variables which is the service activation file.

Data records

The following data records need to be set up to invoke the service;

TSA.WORKLOAD.PROFILE

TSA.SERVICE The ID must be the same as the BATCH record.

BATCH.NEW.COMPANY

BATCH BATCH.ENVIORNMENT set to F JOB.NAME set to the name of the service. EG. OFS.MESSAGE.SERVICE

When GLOBUS.RELEASE is run, all BATCH record ID’s will be re-created with company mnemonics in multi company environments depending on the BATCH.NEW.COMPANY, LEVEL setting.

PGM.FILE For the new routine, with TYPE set to ‘B’ and BATCH.JOB = @BATCH.JOB.CONTROL

FILE.CONTROL

For the service/activation work file.

Initiate the Service

Initiate the Service Figure 1 – Starting the Temenos Service Manager TEMENOS T24 User Guide

Figure 1 – Starting the Temenos Service Manager

Figure 2 – Invoking the Temenos Service Manager TEMENOS T24 User Guide Page 7 of

Figure 2 – Invoking the Temenos Service Manager

Figure 3 – Starting the Service This makes the service available and also TSM allo

Figure 3 – Starting the Service

This makes the service available and also TSM allocates the number of agents that are available for running services. The agents replace the sessions which were used to run the job in a multi thread architecture to save upon the time and to maximise the system resources.

Temenos Service Agents are invoked to TSA.STATUS of their progress and status.

run

the

Service

and

they

run

and

update the

file

Figure 4 – TSA.WORKLOAD.PROFILE Record The agents available for the Service record as def ined

Figure 4 – TSA.WORKLOAD.PROFILE Record

The agents available for the Service record as defined in the profile will be used by the Temenos Service Manager to run the service sessions.

Service in Interactive Mode

Services can be run in interactive mode for testing purposes. The agents then have to be manually started for every session. This requires the Temenos Service Manager to run in debug mode and thus the subsequent agents have to be manually started. It is advised that this method is used for testing purposes only. After starting the TSM, the individual agents allotted to SERVICE should be manually started.

Figure 5 – Invoking the Temenos Service Manager in DEBUG mode TEMENOS T24 User Guide

Figure 5 – Invoking the Temenos Service Manager in DEBUG mode

Figure 6 – Invoking the agent in Interactive Mode List Files Every job during the

Figure 6 – Invoking the agent in Interactive Mode

List Files

Every job during the Service uses a LIST file for storing and sharing the records for processing between different agents. The LIST file is dynamically determined based on the session number doing the SELECT processing of a multi-threaded job. The other agents use the allotted list for sharing their load of the job. The list file is empty at the end of the job thus making it available for a different job.

Como

Since the introduction of multi threaded architecture, the Como will be written with the session no to distinguish processing between different threads. The Como will be written with the key as tSA_<agent no>_datetime.

Batch Output

All reports, COMOs etc. produced by the batch system are output using the T24 report control system. This enables the operator to determine the destination printer, user addressing, number of copies etc. The following applications are used in this process:

Batch Output All reports, COMOs etc. produced by the batch system are output using the

Figure 7 – SERVICE Output Applications

It is recommended that all SERVICE COMOs be retained securely for at least six weeks.

If there is an occasion to restore and rerun, then the COMOs should be printed or copied to a secure medium before the restore takes place.

Error Handling

A process can consist of any number of jobs, which in turn can execute a number of programs or operating system commands. If an error occurs the system may return immediately to the monitor screen and display the process and the job in error, or in the case of less severe errors, update the record for the current job and the current company on the EB.EOD.ERROR file and continue.

Error Handling A process can consist of any number of jobs, which in turn can

Figure 8 –Agent running manually in DEBUG mode, showing an error.

Figure 9 – EB.EOD.ERROR record The details of these errors can be found be exam

Figure 9 – EB.EOD.ERROR record

The details of these errors can be found be examining the records on the EB.EOD.ERROR file and on the EB.EOD.ERROR.DETAIL file.

Any system related crashes will be sensed by the Temenos Service Manager and the dead agent will be started again. The Temenos Service Manager, if there is no activity in a agent for a period of time as defined in the DEATH.WATCH field of TSA.SERVICE, restarts the agent thus ensuring that the service crashes are monitored and restarted by the Service Manager.

Any application related crashes will write into EB.EOD.ERROR with the information on the job name, the record and the text of the crash.