T24 Ofs

This page is different from the print version of this document.
Links are also removed from the print version of this document.
Open Financial Service
Version Date Description Consultant

0.1 24-Nov-2004 New document - Draft Srivatsan. S
1.0 3-Jan-2005 Release candidate 1 Srivatsan. S
1.1 1-Feb-2005 First release Srivatsan. S
1.2 12-Apr-2007 R6 revisions Gerard Thomas
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 2007 TEMENOS Headquarters SA. All rights reserved.

Course: T3OFS Release: R6 Version: 1.2 Open Financial Service
Published by:
Temenos Training Publications
Temenos Corporate Education Centre,
Temenos India Private Ltd,
No.146, Sterling Road, Nungambakkam, Chennai: 600 034, INDIA.
Ph: +91 44 2822 2001. E-mail: indtr@temenos.com
Authoring Contributions:
Srivatsan. S (First edition, 2005) – Temenos India Private Ltd.
Thankful Acknowledgements:
Temenos Training, et al.
First published: 2005

First edition.
Copyright © 2004 TEMENOS HOLDINGS NV
Warning: This document is protected by copyright law and international treaties. 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 Unauthorized
reproduction or distribution of this presentation or any portion of it, may result in severe civil and
criminal penalties, and will be prosecuted to the maximum extent possible under applicable law.”
Information in this document is subject to change without notice.
Trademarks
TEMENOS™, TEMENOS T24™, TEMENOS GLOBUS™, TEMENOS ™, ™ are registered trademarks

of TEMENOS HOLDINGS NV in Switzerland and other countries.
®
jBASE , jBC, jEDI, TM and TM are registered trademarks of TEMENOS Holdings NV in
Switzerland and other countries.
UNIX is a registered trademark of The Open Group. All other trademarks and copyrights mentioned herein may
be the trademarks or registered trademarks of their respective owners.
TEMENOS Training Publications Temenos Education Centre, Chennai

T3OFS – R06 – 1.2 Page 2 of 73 April 2007
Table of Content
Table of Content ................................................................................................................................... 3
Preface ................................................................................................................................................. 5
Scope of this document..................................................................................................................... 5
Who should read this ........................................................................................................................ 5
Conventions used ............................................................................................................................. 6
Software and their versions............................................................................................................... 6
1. Introduction ....................................................................................................................................... 7
Features at a glance ......................................................................................................................... 7
Why OFS .......................................................................................................................................... 8
2. The Architecture ............................................................................................................................... 9
3. OFS Message Types ...................................................................................................................... 10
Transaction requests....................................................................................................................... 10
Enquiry requests ............................................................................................................................. 10
Subroutine requests ........................................................................................................................ 10
4. Modes of processing....................................................................................................................... 11
OFS Batch ...................................................................................................................................... 11
OFS Online ..................................................................................................................................... 12
OFS Globus .................................................................................................................................... 14
5. TEMENOS T24 OFS Applications .................................................................................................. 15
OFS.SOURCE ................................................................................................................................ 15
EB.PHANTOM ................................................................................................................................ 21
OFS.REQUEST.DETAIL ................................................................................................................. 23
6. Setting up OFS ............................................................................................................................... 25
OFS Batch ...................................................................................................................................... 25
OFS Online ..................................................................................................................................... 28
OFS Globus .................................................................................................................................... 31
7. Key Components ............................................................................................................................ 33
OFS Queue Manager ...................................................................................................................... 34
OFS Online Manager ...................................................................................................................... 35
OFS Globus Manager ..................................................................................................................... 36
OFS Request Manager ................................................................................................................... 37
OFS Connection Manager............................................................................................................... 38
OFS Session Manager .................................................................................................................... 39
8. OFS Message Syntax ..................................................................................................................... 40
Transaction request ........................................................................................................................ 40

Transaction response...................................................................................................................... 41
Enquiry request ............................................................................................................................... 41
Enquiry response ............................................................................................................................ 41
Routine request............................................................................................................................... 41
Routine response ............................................................................................................................ 41
9. I_GTS.COMMON – OFS Common variables .................................................................................. 41
10. Controls for OFS Processing ........................................................................................................ 41
GTS.CONTROL .............................................................................................................................. 41
GTS.VALUE .................................................................................................................................... 41
GTS.TYPE ...................................................................................................................................... 41
GTS.INC.EXC ................................................................................................................................. 41
NAU.PROCESSING........................................................................................................................ 41
NOFS – Preventing updates through OFS ...................................................................................... 41
APPENDIX A – Common OFS error messages.................................................................................. 41
Message related errors ................................................................................................................... 41
System related errors ...................................................................................................................... 41
File / I/O related errors .................................................................................................................... 41

Preface
Scope of this document

The scope of this document is limited to detailing the Open Financial Service module of TEMENOS
T24 and its functionalities. In the process of explaining the various functionalities of the Open Financial
Service module this document may make references to various interfaces, internal / external and
software. However the details of such interfaces and software themselves are excluded from the
scope of this document. Also the other modules of TEMENOS T24, their functionalities, and
TEMENOS products like TEMENOS Connectors, TEMENOS T24 Browser and TEMENOS Internet
Bank are not covered in this document.
Who should read this

Temenos implementation teams that needs to understand the various features of the Open
Financial Service module to implement / to make recommendations.
Developers and Architects building interfaces based on / using the Open Financial Service
module.
Temenos Technical consultants who want to know the finer nuances of various processing
modes of Open Financial Service.
Anyone with a fair knowledge of TEMENOS T24 technology and who wants to know in detail
about the Open Financial Service module.
This document is not intended to be used as a sales manual.

Conventions used
This document is organized in to various logical sections by combining related subtopics and carefully
putting these topics in a proper sequence. There are also some formatting conventions followed
uniformly across this document with an aim to improve the readability. The following are the
conventions followed throughout:
– Numbered footnotes are provided wherever deemed necessary to aid understanding.

Footnotes are not provided more than once for the same terms / words avoiding
duplication and redundancy. E.g. a footnote for the term OFS.GLOBUS.MANAGER is
put only for the first occurrence and is not repeated for subsequent occurrences.
– Indication notes are marked in bold italics and prefixed with a

symbol.
– Features available from TEMENOS T24 R5 & R6 releases are prefixed with a
symbol.
– Main informational notes are marked in italics and prefixed with a

symbol.
– Information requiring special attention are marked in italics and prefixed with a
symbol.
– Syntax / commands and source codes are given in colored boxes.
Software and their versions

The following are the various software with their version / release numbers, that are required to run the
commands / source codes / examples given in this document:
– TEMENOS T24 R4 or above (Globus release 14.0.0.1 or above).
– jBASE v 4.0.3.3 or above.
Additionally the following software may be used optionally.

– TEMENOS T24 Browser client for interacting with TEMENOS T24 Server (used for
application screen-shots).
– TEMENOS Connectors for connectivity to TEMENOS T24 Server (required for using
the TEMENOS T24 Browser).

1. Introduction
Open Financial Service – in short referred to as OFS provides an interface to allow the update and
interrogation of TEMENOS T24 applications. OFS provides a standard mechanism to accept
messages in TEMENOS T24’s native format. Using the OFS online module, transaction updates and
enquiries about data within TEMENOS T24 can happen in real-time.
Features at a glance
A standard module of TEMENOS T24 that can be used for updating and querying
TEMENOS T24 database
Request – Response based approach
Provides various modes of operations – Batch, Online, Globus (inter-application

updates)
Provides real-time and batch transaction and interrogation (Enquiry) capabilities to

interfaces (external and internal)
Provides options to customize message processing through user-defined subroutines

(User exits)
Support for Multi-value and Sub-value data
Support for multi-company processing
Messages accepted only in OFS and GTS syntax
Support for XML format messages
Supports logging of messages and provides error message details
Downward compatible with Globus Transaction Server (GTS)
Available for all platforms for which TEMENOS T24 is available
Provides options for offline store and forward of messages
Optional audit trail for each message processed
Validating transactions in TEMENOS T24 standard and local applications, without

committing them to the database

Why OFS
OFS is the ONLY standard gateway to TEMENOS T24. The OFS syntax and OFS format messages
are native to TEMENOS T24. It is the native way to represent requests to execute TEMENOS T24
transactions, enquiries or routines.
Perhaps the most important factor is the ability of the OFS module to run any TEMENOS T24
business function via an automated (machine) interface. It thus brings in a possibility to substitute for
direct user interaction with TEMENOS T24. This also means that the OFS processing is not merely an
update to database, but goes through the same level of validations, including SMS, as it will be in a
manual effort. With OFS it becomes possible for TEMENOS T24 database to transact with / reply
queries from various external channels (systems). This is especially handy when we have huge
volumes of transaction to be updated or when there are systems like ATM switches and Internet
banking requiring a 24/7 connection to TEMENOS T24.
It may also be noted that TEMENOS T24 technology platform products like TEMENOS Connectors,
TEMENOS T24 Browser and TEMENOS Internet Bank use OFS to interact with TEMENOS T24
Applications.

2. The Architecture1
The following diagram shows an architectural overview of OFS. The various key components2 of the
OFS module are shown.
Files Messages Offline queue
Connection Session Online Queue Globus Request Enquiry

manager manager manager manager manager manager manager
Retail Private Treasury Corporate Core
TEMENOS T24 Applications / Versions, Enquires and Subroutines
Subroutine calls
TEMENOS T24 Server

DB Updates /
Transactions Enquiry data Query
TEMENOS T24 Database

Fig 1. The OFS Architecture - Overview
1
The “Open Financial Service” layout in the diagram shows the various managers (components) constituting to
the OFS module. Each component may function at a specific level and for a specific purpose inside the OFS
module. Hence it must not be interpreted as components functioning together or as components functioning at
same levels.
2
For detailed information on various key components of the OFS module read the “Key Components” section that
follows.

3. OFS Message Types

The OFS module supports three types of requests namely:
Transaction requests
Enquiry requests
Subroutine requests
These types form the basis for processing by the OFS. Each request that is submitted to OFS must
fall in to one of these types. They correspond exactly to the process that needs to be carried out in the
T24 server namely updating, querying or running a custom built subroutine.
Transaction requests
An OFS transaction denotes a request by the caller to execute a specific T24 application or version.
The requests contain all (mandatory) transaction-related field data. An OFS transaction request is
mostly based on a direct mapping between a single message to a single T24 application. A request to
input / authorize a FUNDS.TRANSFER transaction, a request to create a CUSTOMER record, a
request to see an already present SECTOR record in T24 are all classic examples of transaction type
requests.
Enquiry requests
An OFS enquiry denotes a request by the caller to execute a T24 enquiry. OFS enquiry requests are
used to query the T24 database by running some already built enquiries. All the actions possible while
running an enquiry like specifying selection condition(s), operand(s), fields etc (dynamic selection
criteria) can be carried out by giving them in the OFS requests. A request to run an enquiry for
knowing the list of customers or accounts present in the T24 database; a request to run a standard
enquiry like BAL.MVMT. ENQ (to find the movement of balances) in T24 are all classic examples of
enquiry requests.
Subroutine requests
An OFS routine denotes a request by the caller to execute a custom routine in the T24 environment. A
routine request is to call a custom built subroutine in the T24 server to do some processing. The OFS
module itself does not do any processing here. OFS just calls the routine specified in the request. T24
routines are useful especially when updates to multiple files (involving more than one T24 application)
have to be effected. Routine requests are very flexible and can even be used to return some data from
T24 like a query.

4. Modes of processing
The following are the various modes of processing available in OFS
OFS Batch
OFS batch, as the name suggests, deals with batches of data / messages. The batch of data is
contained in files. The batch mode can also be used for offline processing. In case of offline
processing messages are picked up from a queue file.
In OFS Batch mode the OFS Queue manager3 runs a phantom process. It picks up messages from a
file / queue file and calls the Request manager for processing the request. The Request manager
processes the request and returns the response. The Request manager shall call the Enquiry
manager if the request is an enquiry request, to run an enquiry inside TEMENOS T24. OFS batch
mode can look into a directory containing various messages as files or handle single file containing
messages. All this is controlled using the setup4 of OFS.SOURCE record and EB.PHANTOM record.
Files Offline queue
Queue manager
Request manager
Enquiry manager*
Applications / Versions, Enquires and Subroutines

Subroutine calls
TEMENOS T24 Server

Transactions Enquiry data DB Updates /
Query

Fig 2. OFS Batch Mode - Overview
3
For detailed information on OFS Queue Manager read the “Key Components” section that follows.
4
For detailed information on setting up OFS, OFS.SOURCE and EB.PHANTOM read the “Setting up OFS” and
“TEMENOS T24 OFS Applications” sections that follow.

OFS Online
OFS online allows real-time update to TEMENOS T24 via a live TELNET link / connection. In this
mode messages are accepted and processed individually. The connection will be established with the
TEMENOS T24 server by supplying a pre-defined UNIX / Windows login.
When OFS is set to work in online mode, the program EB.AUTO.INIT.PROCESS is executed upon
login. When EB.AUTO.INIT.PROCESS is launched it looks for a record on the EB.AUTO.PROCESS
file with an id equal to the UNIX / Windows login id of the user logging in. If such a record exists then
the OFS online application will be invoked.
The EB.AUTO.PROCESS record is updated from OFS.SOURCE - when an OFS.SOURCE record is

created for the telnet connection, an EB.AUTO.PROCESS record is automatically created with an id
generated from the LOGIN.ID field from the OFS.SOURCE record.
The AUTO.START.PROCESS field of EB.AUTO.PROCESS file is updated with the process name that
will be called by EB.AUTO.INIT.PROCESS. This process name is OFS.START.ONLINE.COMMS.
Once the connection is established the OFS.ONLINE.MANAGER5 will be started automatically as a

phantom by OFS.START.ONLINE.COMMS.
The connections (phantom processes) are started automatically by OFS.START.ONLINE.COMMS. A

maximum number of open OFS connections for a particular source can be specified. Each OFS
connection will continue to be active until either shutdown from TEMENOS T24 or by the external
application. The connection can remain active during the offline mode to allow enquiry functions to
take place.
5
For detailed information on OFS Online Manager read the “Key Components” section that follows.

Messages
EB.AUTO.INIT.PROCESS (Login / .profile)
Communication initiation (OFS.START.ONLINE.COMMS)
Online manager
Request manager
Enquiry manager*

Subroutine calls
TEMENOS T24 Server
Query

Fig 3. OFS Online Mode - Overview

OFS Globus
OFS can be used by TEMENOS T24 Applications internally to perform updates across application /
files i.e. between TEMENOS T24 applications / subroutines. OFS Globus mode is used for this
purpose.
Earlier cross application updates were possible only by directly writing / updating the applications.
Clearly this had a disadvantage especially when it required updates to a lot of dependent and concat
files. The process required extensive coding. To overcome this OFS was used in batch mode i.e. –
OFS messages were created and written to a file / directory and OFS batch phantom would be run to
process these messages. This again had its disadvantages of poor response / error handling since the
OFS batch process and the process that creates the OFS messages (within TEMENOS T24) were
independent and different from each other. Besides usage of phantoms added overheads to
performance. The answer was to take the OFS Globus approach. In OFS Globus mode, a message is
6 7
created in OFS format and the routine OFS.POST.MESSAGE is called passing the OFS.SOURCE
record Id and the actual message string to process, as arguments. OFS.POST.MESSAGE calls
OFS.REQUEST.MANAGER to do the processing and returns the response.
Messages from T24 Applications / Subroutines
OFS.POST.MESSAGE
Request manager
Enquiry manager*

Subroutine calls
TEMENOS T24 Server

Query

Fig 4. OFS Globus Mode - Overview
6
For detailed information on OFS format read the “OFS Message Syntax” section that follows.
7
For detailed information on OFS.POST.MESSAGE, read the “Key Components” section that follows.

5. TEMENOS T24 OFS Applications

The following are the 3 very main OFS module related applications in TEMENOS T24 that should be
well understood.
OFS.SOURCE
EB.PHANTOM8
OFS.REQUEST.DETAIL
These applications control the behavior and operation of the OFS. By setting up the OFS.SOURCE
and EB.PHANTOM applications the various functionalities of the OFS module can put to action.
These applications are explained in detail in the sections that follow.
OFS.SOURCE
The first step to get started with OFS is to setup a record in the OFS.SOURCE. It is the TEMENOS
T24 application that is required to be setup to use OFS.
The fields of the OFS.SOURCE application and their meaning / purpose is given below.
NOTE: Fields that are not stated explicitly as mandatory are optional.
ID – OFS Source Name

Contains the name / Id of the OFS Source record. The User can set an appropriate name that can
contain up to a maximum of 20 alphanumeric characters. Mandatory field
SOURCE.TYPE – OFS Source Type

This field defines the type of communication to be used. This is a mandatory field.
OFS allows the following modes of communication:
A BATCH process where a directory is populated with records in either a particular file, or
several files. Multiple messages, each delimited by a field marker – @FM can also be created.
These would be treated as if they were multiple sequential files.
Single messages may be passed to TEMENOS T24 for processing through a TELNET
connection.
TEMENOS T24 Applications can internally use OFS to perform updates across application /
files.
Can be set to any one the following depending on the connection / processing mode required
BATCH - for BATCH mode of processing
8
EB.PHANTOM is not a part of OFS module although it is very much used for the OFS Batch and Online modes.
For details on EB.PHANTOM refer to the TEMENOS T24 User Guides.

TELNET - for TELNET (Online) mode of processing

GLOBUS - Between TEMENOS T24 applications / subroutines
SESSION - For use with TEMENOS T24 Browser
LOGIN.ID – System Login ID

This field specifies the UNIX or NT login that will automatically initiate the communication with the
external source. The external source will initiate communications by issuing a login using the specified
id. Automatic processes initiated at login are stored in the EB.AUTO.PROCESS application.
EB.AUTO.PROCESS is updated automatically using the value mentioned in this field. The system will
automatically begin the communication process when this login is detected. This is a mandatory field if
the SOURCE.TYPE is TELNET. Alphanumeric characters 1 - 15 in length are allowed.
EB.PHANT.ID – EB.PHANTOM record ID

For online mode, this field specifies the ID of the specific EB.PHANTOM record to be used. If not
specified for online mode, OFS will create EB.PHANTOM records automatically during run-time. The
runtime EB.PHANTOM records created so will have an ID of the form OFS.SOURCE.ID-Session No,
where Session No is a randomly generated number less than / equal to the value specified in
MAX.CONNECTIONS.
For batch mode, this field can be used to specify the ID of EB.PHANTOM record used for picking up
the data from the input batch file / directory. It is important to note that OFS neither makes any checks
for the validness, nor does it use it. This field can hence be used to just store the name of the
EB.PHANTOM record for reference.
MAX.CONNECTIONS – Maximum connections

Specifies the maximum number of on-line OFS connections for the specified service, which can be
active at any one time. Each OFS on-line session is a single jBASE user, so the number specified
here must be less than the maximum number of users defined in NO.OF.USERS field of SPF. The
maximum value allowed here is NO.OF.USERS minus 5. It is mandatory for telnet source type.
RESTRICT.LINK – Restrict Link

This field is used to control the usage of OFS service (open / close). The service can be closed for all
on-line communication by specifying CLOSE, alternative, enquiry only access can be provided by
specifying ENQ. The system will not allow updates to take place during end of day processing,
irrespective of the values defined here.
INITIAL.ROUTINE – Initial Routine

Allows a user defined routine, which will be called when a service is started. Typically such a routine
could be used to perform some initial communication. The routine specified here must be defined in
PGM.FILE as a type S. This routine is called only when the SOURCE.TYPE is set to TELNET.
CLOSE.ROUTINE – Close Routine

Allows a user defined routine, which will be called when a service is closed. Typically such a routine
could be used to perform some final communication. The routine specified here must be defined in
PGM.FILE as a type S. This routine is called only when the SOURCE.TYPE is set to TELNET.
IN.MSG.RTN – In Message Routine

Allows a user defined routine to be specified for a particular service. The routine specified here will be
called when each message is received prior to processing by OFS. Typically such a routine could
convert or map the data received into the required OFS message format. Note the routines cannot use
any of the TEMENOS T24 common variables like R.NEW, R.OLD etc. The routine specified here must
be defined in PGM.FILE as a type S. The subroutine must have one argument that will contain the
OFS message. This routine is called only when OFS runs in batch mode or online mode.
From TEMENOS T24 R5 release onward, this routine is also called from OFS Connection
Manager9.
OUT.MSG.RTN – Out Message Routine

Allows a user defined routine to be specified that will be called when each message is returned from
OFS processing. Typically such a routine could convert or map the data received from the required
OFS message format into an external format. The routine specified here must be defined in PGM.FILE
as a type S. The subroutine must have one argument that will contain the OFS message. This routine
is called only when OFS runs in batch mode or online mode.
From TEMENOS T24 R5 release onward, this routine is also called from OFS Connection
Manager.
MSG.PRE.RTN – Message Pre Routine

Allows a user defined routine to be specified for a particular service that will be called within the OFS
processing prior to application update or execution of Enquiry. Typically such a routine could update
additional local applications. The routine specified here must be defined in PGM.FILE as a type S.
Note that the content of the message cannot be modified within this routine. The subroutine must have
one argument that will contain the OFS message. This routine is called for all modes of OFS.
MSG.POST.RTN – Message Post Routine

Allows a user defined routine to be specified for a particular service that will be called within the OFS
processing after application update or execution of Enquiry. Typically such a routine could update
additional local applications. The routine specified here must be defined in PGM.FILE as a type S.
Note that the content of the message cannot be modified within this routine. The subroutine must have
one argument that will contain the OFS message. This routine is called for all modes of OFS.
LOG.FILE.DIR – Log File Directory

OFS can maintain a log of various messages. This is controlled through the setup in
LOG.LEVEL.DETAIL field (see next field). LOG.FILE.DIR field defines the name of the directory used
to store the log files created when running OFS. This either refers to an existing directory or a new
directory will be created (under the .run directory) at authorization of the record. If a path is specified,
then that path must exist (or be created) before specifying it here.
LOG.DETAIL.LEVEL – Log Detail Level

Specifies the type of OFS message logging to be performed by OFS. The following levels of message
logging are supported:
FULL - All message communications are fully logged (Advised only during debugging).
OPEN - Only initial start and stop for processes are logged.
EXCEPT - Only exceptions such as incorrect message syntax, invalid user details and validation
errors are reported.
9
For detailed information on OFS Connection Manager read the “Key Components” section that follows.

NONE - No message logging.

This is a mandatory field, defaulted to NONE.
OFFLINE.QUEUE – Offline Queue

Specifies whether the service has offline capability (only when SOURCE.TYPE is set to BATCH).
Entry of transactions is not possible when the system is off-line. If this field is set to Y the system will
maintain a store of all transactions that are submitted whilst the system is offline. Transactions can be
processed when the system is back on-line by running an EB.PHANTOM process using the
RUN.ROUTINE OFS.QUEUE.MANAGER.
MAINT.MSG.DETS – Maintain Message Details

Specifies whether an audit record is to be maintained for each OFS message sent and received. If this
field is set to Y the file OFS.REQUEST.DETAIL will be updated with the progress and content of each
OFS request. Each message will be allocated a separate id.
DET.PREFIX – Detailed Prefix

Specifies the prefix to be used for the message details recorded when an audit trail is maintained.
Mandatory input if OFFLINE.QUEUE or MAINT.MSG.DETS are set to Y. Accepts 2 - 6 alpha
characters. Whenever a record in OFS.REQUEST.DETAIL is created, the value specified in this field
will be used as the prefix to the record ID.
IN.QUEUE.DIR – Inward Queue Directory

Defines the name of the directory used to hold incoming batches of messages when operating in a
BATCH mode. A Batch OFS service can operate using either a specific record within the directory
specified here, defined in IN.QUEUE.NAME (see next field), or can process any file within the
directory if no specific name is specified. Each file may contain one or more records in specified OFS
message format. Processed records are written to the directory specified in the OUT.QUEUE.DIR (see
below) either to the specified OUT.QUEUE.NAME (see below) or the same name as the inward record.
This either refers to an existing directory or a new directory will be created (under the .run directory) at
authorization of the record. This field is mandatory input if SOURCE.TYPE is BATCH or GLOBUS.
IN.QUEUE.NAME – Inward Queue Name

Defines the name of a specific input file resident in the input directory (specified by IN.QUEUE.DIR) to
be processed when operating in a BATCH mode. If not specified, OFS will pick up any messages
falling into the directory defined in the IN.QUEUE.DIR.
OUT.QUEUE.DIR – Outward Queue Directory

Defines the directory used to store output files, which contain details of completed transactions
together with any validation errors or overrides. This either refers to an existing directory or a new
directory will be created (under the .run directory) at authorization of the record. This field is
mandatory input if SOURCE.TYPE is BATCH.
OUT.QUEUE.NAME – Outward Queue Name

Defines the name of a specific output file resident in the output directory used to hold outgoing
batches of messages when operating in a BATCH mode. If not specified, OFS will write output
messages into the directory defined in the OUT.QUEUE.DIR.
QUEUE.INIT.RTN – Queue Initial Routine

Allows a user defined routine, which will be called when the service is started. Typically such a routine
could be used to perform some initialization / service startup activities. This routine is called only when
the SOURCE.TYPE is set to BATCH.
QUEUE.CLOSE.RTN – Queue Close Routine

Allows a user defined routine, which will be called when the service is closed. Typically such a routine
could be used to perform some final / closing activities. This routine is called only when the
SOURCE.TYPE is set to BATCH.
SYNTAX.TYPE – Syntax Type

Indicates the syntax type of the messages within batch files in the IN.QUEUE.DIR directory. The
allowed values are:
GTS - Request and response follows the old style GTS syntax. This syntax is deprecated.
OFS supports this syntax to be downward compatible with legacy code.
OFS - Request and response follows the standard OFS syntax10.
XML - Request and response are in XML format.
GENERIC.USER – Generic User

Identifies the TEMENOS T24 USER used by the OFS.ONLINE.MANAGER phantom process. This
field is mandatory input when SOURCE.TYPE is TELNET.
IN.DIR.RTN - In Directory Routine

Allows a user defined routine to be specified. The routine specified here will be called when the input
directory defined in IN.QUEUE.DIR is empty, i.e. there are no messages to process. Typically such a
routine could be used to populate the input directory with OFS messages derived from a third party
source. This routine must not have arguments.
VERSION – Version
Contains the name of a valid version record, which can be used in association with the routine
specified in IN.DIR.RTN to create OFS messages. For example a routine to process information for
FUNDS.TRANSFER will have a valid FUNDS.TRANSFER version defined here.
IB.USER.CHECK – IB User Check

If this field is set to ‘Y’, then TEMENOS T24 will validate if the user exists in F.USER and IB.USER
applications. IB.USER is an application that is used by the TIB module in TEMENOS T24.
EOD.VALIDATE – EOD Validation

If this field set to ‘YES’ then OFS requests are allowed when the system is not online. Only Validation
is allowed during offline processing. Records Validated are not queued. This option should only be
used with great care. If not set, then OFS requests made during offline processing are queued.
10
For detailed information on the OFS syntax read the “OFS Message Syntax” section that follows.

FIELD.VAL – Field Validations

Specifies whether field validation is to take place on the message. This option was introduced for use
with the TEMENOS T24 Browser clients. Most applications repeat field validations at record
commitment and do not need this option. A few older applications rely on the input being edited as it is
entered online. OFS field validation can be used to stop certain invalid data getting through to
authorized records. The allowed options are:
YES - Field validation takes place
NO / null - Validation starts at cross-validation

EB.PHANTOM
EB.PHANTOM is a generic application within TEMENOS T24 that controls all phantom and interactive
jobs. It is used to set up all common logic required for all phantom / interactive jobs. The
EB.PHANTOM itself does not provide processing intelligence. The actual processing is handled by the
subroutine mentioned in its RUN.ROUTINE field. The RUN.ROUTINE must handle the starting and
stopping correctly whether run interactively or as a background process. The RUN.ROUTINE must
take signal to stop the process when a value STOP is input in the PHANT.STOP.REQ field.
A record in EB.PHANTOM needs to be setup if OFS were to be run in the BATCH mode.
OFS.QUEUE.MANAGER is a standard TEMENOS T24 OFS program. This program must be specified
in the RUN.ROUTINE field of EB.PHANTOM.
For ONLINE mode an EB.PHANTOM record is automatically created with OFS.ONLINE.MANAGER

as the RUN.ROUTINE upon starting OFS. Hence a record need not be created.
The other modes of OFS do not use EB.PHANTOM and hence a record need not be created.
The fields of the EB.PHANTOM application and their meaning / purpose is given below.
NOTE: Only fields that are relevant to OFS setup are given below. For other fields refer
the TEMENOS T24 EB.PHANTOM User Guide. Fields not stated explicitly as mandatory
are optional.
EB.PHANT.ID – Phantom Name / ID

This field specifies the EB.PHANTOM record ID to be used for OFS processing. A meaningful ID
(name) is recommended. This mandatory input can be 1 - 30 alphanumeric characters.
DESCRIPTION – Description of the Phantom record

This field describes the function of the phantom record. A meaningful description is recommended.
This mandatory input can be 1 - 35 alphanumeric characters. Also supports Multilanguage.
RUN.MODE – Run Mode

This field indicates the mode that will be used to invoke the process. The following values are allowed:
I – for Interactive i.e. process will run from the current terminal session in such a way that the user can
start / stop the process.
P – for Phantom i.e. process will run as a background phantom.
SLEEP.SECS – Sleep time (in seconds)

This field specifies the time interval (in seconds) with which the OFS checks whether there is anything
in the in directory. An optimal amount is recommended here. A shorter interval means frequent use of
system resources, while a larger interval means increased lead times in processing.
TIMEOUT.SECS – Time out (in seconds)

This field specifies the timeout (in seconds) for the process. If a process has difficulty in reading from a
file, such that it fails to read the file in the time set here, the process will stop reporting a timeout error.
An optimal amount is recommended here. A shorter value may result in unnecessary timeouts, while a
large value may result in delays in reporting timeouts.
GTS.USER.ID – GTS User ID

This field specifies the user that will appear on the audit information for the processed batch jobs. This
can be used for audit trail purposes in all records that are Input, Changed or Authorized by the OFS
process. It is recommended that the TEMENOS T24 user specified here be set-up exclusively for the
OFS processing. Accepts 3-16 alphanumeric characters (first character alpha). The value must exist in
the USER application of TEMENOS T24. This field is mandatory.
OFS.SOURCE – ID of OFS.SOURCE record

This field specifies the ID / key of the OFS.SOURCE record created. This represents the
OFS.SOURCE record to be used with this batch process.
RUN.ROUTINE – Name of the Subroutine to run

This field specifies the name of the subroutine that defines the logic that will be invoked when the
phantom process is spawned. This could be a site-specific or a standard routine that will be performed
as background job when run in PHANTOM mode, or in the foreground when run in INTERACTIVE
mode.
For OFS batch mode, this field must contain the standard TEMENOS T24 subroutine –
OFS.QUEUE.MANAGER.
For OFS online mode, this field will contain the value – OFS.ONLINE.MANAGER (automatically
created by the system).
RUN.STATUS – Process status

This is a NOINPUT field that specifies the run status of the phantom process. This field will also
identify error conditions encountered during processing. During routine phantom execution this field
may contain the text 'Running' and may also contain additional information such as the number of
records processed11.
OFS updates this multi-valued field with the status of processing.
11
The subroutine specified in the RUN.ROUTINE is responsible for the information or text populated in this field.
The information and its extent may vary from one subroutine to another. For accurate details refer to the
documentation and / or source code (if any) of the attached subroutine.

OFS.REQUEST.DETAIL
OFS.REQUEST.DETAILS sometimes referred to as ORD in short, is a TEMENOS T24 file that is used
by OFS to maintain an audit of OFS requests. To enable the OFS audit in to this file the field
MAINT.MSG.DETS in OFS.SOURCE must be set to be “Y”. The audit information is recorded per
message.
The fields of the OFS.REQUEST.DETAIL file and their meaning / purpose is given below.
NOTE: OFS.REQUEST.DETAIL is a live file and hence cannot be user input. The OFS
module automatically updates this file.
MESSAGE.KEY – ORD key / ID

This field contains the record ID of the OFS.REQUEST.DETAIL written by OFS. Each OFS message
recorded here is allocated a separate ID automatically. If a value is specified in DET.PREFIX field of
OFS.SOURCE, then this ID will be prefixed with the same.
APPLICATION – TEMENOS T24 Application

This field contains the TEMENOS T24 application that is updated through the OFS message.
VERSION – TEMENOS T24 Application’s Version

This field contains the version of the above-mentioned TEMENOS T24 application that is updated
through the OFS message.
FUNCTION – TEMENOS T24 Function used

This field contains the function used by the OFS like Input / Authorize / Reverse etc.
TRANS.REFERENCE – Transaction Reference

This field contains the transaction reference number / value of the transaction. The transaction
references are generated by the TEMENOS T24 applications and may vary from one application to
another.
USER.NAME – Name of the User

This field contains the name of the TEMENOS T24 User that is used to perform the OFS processing.
The User name can be found in the message except in case of OFS GLOBUS mode where the user is
the current signed on user (contained in the common variable OPERATOR) running the process.
COMPANY – TEMENOS T24 Application

This field contains the TEMENOS T24 Company in which the OFS processing is taking place (Useful
in case of a multi-company setup).
DATE.TIME.RECD – Date and time of message received

This field contains the date and time when the message was received by OFS. This is extremely
useful to measure the performance of TEMENOS T24 system, especially the OFS processing.

DATE.TIME.QUEUE – Date and time of message queued

This field contains the date and time when the message was queued by OFS. This field is updated
only when the TEMENOS T24 system is offline and the messages are queued by OFS for later
processing (when system comes online).
DATE.TIME.PROC – Processing date and time

This field contains the date and time when the message was processed by OFS. This field is updated
only when OFS has processed the message and is not updated when the messages are queued when
TEMENOS T24 system is offline.
STATUS – Status of the message / processing

This field contains the status of the message processed by OFS. The status can be any one of the
following:
Received – The message was received by the OFS.
Accepted – The message has been accepted, validated and processed successfully by the OFS.
Error – The message has been processed but found to have some error(s).
Queued – The message is queued to be processed later. This happens when the TEMENOS T24
system is offline.
MSG.IN – Message received

This contains the message received by the OFS module for processing. Messages from all modes of
OFS operation are recorded here.
MSG.OUT – Message sent

This contains the message sent (response) by the OFS module after processing. Messages from all
modes of OFS operation are recorded here.
Name of the Application
Request message
Status of processing Response message
Fig 5. An OFS.REQUEST.DETAIL Record

6. Setting up OFS
OFS Batch
Source type setup to Batch
Directory to log messages
Directory for request

messages
Directory for response

messages
Request messages are in

OFS format
Fig 6. OFS.SOURCE Record for Batch Mode

OFS Source record for

Batch mode
OFS routine to be run as

a phantom process
Fig 7. EB.PHANTOM Record for Batch Mode
To setup OFS to work in batch mode create a record in OFS.SOURCE and EB.PHANTOM as shown
in the illustration above.
Notice the value “BATCH” setup in the “Source Type” field of OFS.SOURCE record. Also
notice the directory defined in “In Queue Dir” of OFS.SOURCE where OFS will pick-up the
request messages for processing and the directory defined in “Out Queue Dir” for OFS to write
response messages after batch processing.
The EB.PHANTOM record for the OFS Batch has to be created. It is this phantom that infact
runs the OFS Batch. Notice the OFS.QUEUE.MANAGER (routine) defined in the “Run
Routine” field and the batch record id of OFS.SOURCE in the “Ofs Source field”.

After the setup as shown above is carried out, to run OFS in Batch mode, login to TEMENOS T24 and
VERIFY (“V” Function) the corresponding EB.PHANTOM record.
Request messages created / copied inside the inward directory (or file) defined in the corresponding
OFS.SOURCE record will be taken by OFS Batch phantom. Reply messages are populated in the
outward directory defined in the corresponding OFS.SOURCE record.
Messages may also be logged to the log directory defined in the corresponding OFS.SOURCE record
depending on the log level set.
To stop the Batch OFS enter the value “STOP” in the PHANT.STOP.REQ (“Phant Stop Req”) field of
the corresponding EB.PHANTOM and commit (as you would do to stop any other phantom).

OFS Online
#
# If you wish to use OFS online via EB.AUTO.INIT.PROCESS, uncomment
# the following four lines of script:
# First we check if there are any auto processes to run. The program
# EB.AUTO.INIT.PROCESS checks the table EB.AUTO.PROCESS for a record
# with an id of the user. If this is found (defined in OFS.SOURCE)
# the EB.AUTO.INIT.PROCESS will run the routine, an ultimately logout
# Where nothing is found, the routine terminates normally.
# Hence we examine the $? code. A non zero seems to indicate that the
# process DID something, so get out. This will need to be tested
# on a site by site basis.
#
#
EB.AUTO.INIT.PROCESS
if [ $? != 0 ]; then
exit
fi
#
Fig 8. A small part of .profile file
To setup OFS, to work in online mode on UNIX systems, open the .profile12 file of the predefined user
account13 using a text editor (ex. vi) and uncomment the four lines (remove the comment character ‘#’)
starting from the line with “EB.AUTO.INIT.PROCESS” to line with “fi” (shown in bold in the above
illustration).
Also create a record in OFS.SOURCE as shown in the illustration below.
12 ®
The .profile file can be found in the home directory of the user. For more details on .profile refer to UNIX
system guide supplied by your system vendor.
13
Indicates a separate user account created for use with OFS Online. Though this is not mandatory, it is highly
recommended, especially if the TEMENOS T24 environment needs to be used by users not using OFS Online.

Source type setup to TELNET
The Unix / Windows login ID
Maximum number of
connections allowed

OFS format
Fig 9. OFS.SOURCE Record for Online Mode

Notice the value “TELNET” setup in the “Source Type” field of OFS.SOURCE record. Also
notice the operating system (UNIX / Windows NT/2000/XP) login ID specified in the “Login
Id.1” field.
Note that an EB.PHANTOM record for the OFS Online setup is not created. Although a
specific EB.PHANTOM record may be created and specified in the “EB Phant ID.1” field, it is
not required since the system automatically creates the required EB.PHANTOM records
during run-time.
After the setup as shown above is carried out, the OFS Online mode can be run by hand by logging on
to TEMENOS T24 using telnet, through the predefined operating user account created for the purpose.
Upon login, the OFS Online mode prompt (? – Question mark) is displayed. Messages can be input at
this prompt for which OFS will display responses. Typing the word “EXIT” / “exit” will disconnect the
connection.
Alternatively, after setting up the OFS.SOURCE record as shown above, running the program
EB.AUTO.INIT.PROCESS from the jSHELL prompt, if a separate operating system user account is
not created, can also run OFS Online mode. In such a case changes to the .profile file is not
necessary. Though this is possible it is not recommended.

OFS Globus
Source type setup to GLOBUS
Directory to log messages
Directory to write request

messages if another OFS
GLOBUS Manager is active

OFS format
Fig 10. OFS.SOURCE Record for Globus Mode

To setup OFS to work in Globus mode create a record in OFS.SOURCE as shown in the illustration
above.
Notice the value “GLOBUS” setup in the “Source Type” field of OFS.SOURCE record.
Note that there is no need to create an EB.PHANTOM record for the OFS GLOBUS setup to
work. This is because the OFS.GLOBUS.MANAGER does not run as a phantom.
After the setup as shown above, is carried out the OFS.GLOBUS.MANAGER routine must be called
with 2 arguments (OFS.SOURCE record ID created for the purpose and OFS Message). This call can
be made from a Version / Version Control subroutine or an application if you are building the
application or from a custom-built TEMENOS T24 subroutine.
From TEMENOS T24 R5 release onward, OFS.GLOBUS.MANAGER routine cannot be

called from a VERSION / VERSION.CONTROL routine. A check has been made in
EB.CALL.API to prevent this call, with a view to ensure integrity of the updates.

7. Key Components
The following are the various key components of the OFS module.
OFS Queue manager
OFS Online manager
OFS Globus manager
OFS Request manager
OFS Connection manager
OFS Session manager
These components are explained in detail below.

OFS Queue Manager

The OFS.QUEUE.MANAGER is used for BATCH communication with the OFS module. It also
supports processing of OFFLINE messages (in Batch mode) when system comes back online.
The OFS.QUEUE.MANAGER does the following:
Checks for the processing functionality i.e. normal BATCH or OFFLINE batch.
If OFFLINE batch is set it reads the messages from the offline queue.
If normal BATCH mode is set it reads the OFS request messages from a file or from a
directory depending on the configuration done in the related OFS.SOURCE record.
Calls the OFS.REQUEST.MANAGER for actual processing of the message.
Writes the reply for the processed message to a file or directory depending on the
configuration done in the related OFS.SOURCE record.
It also checks for a signal to stop initiated by setting a value STOP in the PHANT.STOP.REQ
field of the related EB.PHANTOM record.
It also performs message logging (request / response) depending on the level setup in the
related OFS.SOURCE record.
Calls to various user exits (subroutines) - QUEUE.INIT.RTN, IN.MSG.RTN, OUT.MSG.RTN,

IN.DIR.RTN and QUEUE.CLOSE.RTN at the appropriate stages.

OFS Online Manager

The OFS.ONLINE.MANAGER is used for TELNET communication with the OFS module. The
messages are accepted via a TELNET link / connection.
The OFS.ONLINE.MANAGER does the following:
Receives messages from the external application (e.g. ATM Switch software) or user via a
TELNET link.
Passes the request message to the OFS.REQUEST.MANAGER to perform the required

processing.
Passes the reply message returned to the external application.
Checks for a signal to stop initiated by getting a string “EXIT” from the TELNET link or by
setting a value “CLOSE” in the RESTRICT.LINK field of the related OFS.SOURCE record.
Performs message logging (request / response) depending on the level setup in the related
OFS.SOURCE record.
Calls to various user exits (subroutines) - IN.MSG.RTN, OUT.MSG.RTN, INITIAL.ROUTINE

and CLOSE.ROUTINE at the appropriate stages.

OFS Globus Manager

The OFS.GLOBUS.MANAGER is used by TEMENOS T24 Applications to perform OFS module
functions like update and querying between them. The OFS.GLOBUS.MANAGER is invoked through
a call made to it by another TEMENOS T24 application / subroutine. It takes the OFS.SOURCE record
Id and the actual OFS message as arguments.
The OFS.GLOBUS.MANAGER does the following:
Receives messages from some TEMENOS T24 application / subroutine through a subroutine
call.
Performs checks to see if the call is from another OFS interface (e.g. via TEMENOS T24
Browser).
Sets the environment & common variables based on the checks done for processing.

processing.
Restores the environment & common variables to original point as they were before the
processing to prevent crashes / malfunctions of the caller application / subroutine.
Passes the reply message returned, to the caller application / subroutine.
OFS.SOURCE record.

OFS Request Manager

The OFS.REQUEST.MANAGER is the main processing routine of the OFS module. It is the heart of
the OFS module and has a generic logic to work across various TEMENOS T24 applications and
enquiries. The actual processing of the message including updating / querying the T24 database is
handled by this routine. Almost all the OFS processing of requests end here.
The OFS.REQUEST.MANAGER does the following:
Receives the request message from one of the OFS module routines (subroutine call).
Determines the format of request (OFS / GTS / XML).
Calls the appropriate message parser based on the format of the message.
Validates the syntax and the structure of the message.
Validates the contents of the message like Application / Enquiry / Subroutine names, function
appearing in the message, operation requested like (process / validate).
Checks the access rights for the user (SMS) based on the processing mode used. By
simulating14 a manual effort, OFS.REQUEST.MANAGER makes it possible for the message
being processed to pass through the same level of SMS checks that would otherwise have
been done when a user tries to effect that transaction manually.
Determines the type of request (Application / Enquiry / Subroutine).
Builds the selection criteria and call OFS.ENQUIRY.MANGER is request is found to be an

Enquiry request.
Calls the subroutine given in the request if it is found to be a Subroutine request.
Calls the application and passes the data to the application using the common variable
R.NEW if the request is found to be an Application request. However, before this it also
checks the status of the TEMENOS T24 server (offline / online). If TEMENOS T24 system is
online it allows updates to database through Applications, otherwise only the option to view
the records (See function) is allowed. If offline queuing is set then the requests are put in a
queue to be processed later. If the system is online then the Application and version supplied
in the request are validated. Once this is found to be valid the environment for calling the
application like record locking, ID, version (if any) etc are set.
Passes the reply message to the caller application / subroutine.
Calls to various user exits (subroutines) - MSG.PRE.RTN and MSG.POST at the appropriate
stages.
OFS.SOURCE record.
Performs audit of messages to (request / response) OFS.REQUEST.DETAILS if a value “Y” is

set in MAINT.MSG.DETS field of the related OFS.SOURCE record.
14
OFS.REQUEST.MANAGER sets up appropriate variables and invokes the application’s template program. All
TEMENOS T24 programs like EX handle requests from OFS the same way, as they would when a user inputs a
transaction.

OFS Connection Manager

The TEMENOS Connector uses the OFS.CONNECTION.MANAGER to send request message to
TEMENOS T24 server and receive back responses. The OFS.CONNECTION.MANAGER can also be
used from a TEMENOS T24 classic client (using a telnet client to connect to TEMENOS T24 server) to
post OFS request messages to TEMENOS T24 and get back responses. Though the latter method of
invoking the OFS.CONNECTION.MANAGER is not recommended for production use, it may be
extremely useful for simulating and debugging OFS messages during a development / testing phase.
The OFS.CONNECTION.MANAGER does the following:
Initializes the TEMENOS T24 environment & common variables for the processing
applications / subroutine to work correctly.
Reads the OFS.SOURCE record detail.
Receives messages from the TEMENOS Connectors / from console through user input in a
TEMENOS T24 classic client.
Passes the request message to the OFS.SESSION.MANAGER to perform the required

processing.
Passes the reply message returned, to the caller.
Checks for a signal to stop initiated by getting a string “EXIT” or “QUIT” from the TEMENOS
Connectors / from console through user input in a TEMENOS T24 classic client.
OFS.CONNECTION.MANAGER has been replaced with tSS from R6 onwards. tSS offers
the same functionality as OFS.CONNECTION.MANAGER.

OFS Session Manager

The OFS.SESSION.MANAGER is called by the OFS.CONNECTION.MANAGER to manage the OFS
sessions of TEMENOS T24 Browser clients. The OFS.SESSION.MANAGER handles OFS requests
coming from TEMENOS T24 Browser clients, forwards them to the TEMENOS T24 server for
processing and sends back the response.
The OFS.SESSION.MANAGER does the following:
Gets the request message from OFS.CONNECTION.MANAGER (subroutine call).
Checks for tokens15 (from TEMENOS T24 Browser Sessions).
Determines the type of request and the format.
Handles TEMENOS T24 Browser sessions (create / destroy) and manages operations.
Validates the TEMENOS T24 Browser requests.
Checks the access rights (SMS).
Parses the Browser XML messages.
Checks functions / applications. Locks records (if required)

processing.
Creates the required response messages
Passes the reply message returned to the caller.
15
For information on tokens refer to the “TEMENOS T24 Non Stop” document.

8. OFS Message Syntax

The OFS requires messages to be in its syntax. The syntax of the OFS is a native way to represent
transaction, enquiry and subroutine type requests in TEMENOS T24 server. The OFS syntax for
various types of requests is given below:
Transaction request
Operation Options User Transaction Message

, , Information , ID , Data
Fig 11. OFS Transaction Request Syntax structure
The syntax structure of OFS transaction type request messages is shown above. All the main portion
of the message syntax for transaction type requests is shown in the above diagram. Each portion of
the message is separated by a comma (,). The portions are explained as under:
OPERATION:
The operation portion of the message structure specifies the TEMENOS T24 application to be run by
the OFS. E.g. FUNDS.TRANSFER, CUSTOMER, SECTOR etc. Application here is not restricted to
just standard TEMENOS T24 applications but also include locally built TEMENOS T24 applications.
This portion is mandatory. Note that the OFS transaction requests cannot be used to update live files
(similar to user input).
OPTIONS:
The option portion of the message structure specifies the TEMENOS T24 version, function and
process type flag that must be used by OFS, where the version is the version of the application above,
TEMENOS T24 function to be used with the application (like input – I / authorize - A, delete -D,
reverse - R) and process type flag is PROCESS or VALIDATE. The version, function and process
flags are all optional.
If a version is not supplied the application is used directly. Note that the comma (,) version will not be
used as default. Also, a comma (,) version supplied in the message will be treated as a Non-version
run resulting in record(s) placed in INAU (not authorized) state. Hence a version name must be
supplied if the transaction is meant to be self-authorizing16.
If a function is not supplied then it is assumed to be input.
PROCESS denotes that the message is to be committed to the database and VALIDATE denotes that
all normal processing takes place without actually updating the database. If no option is specified then
PROCESS is taken as default.
16
The NO.OF.AUTH field of the supplied version record must be set to ‘0’ (zero).

Optionally, from TEMENOS T24 R4 release onward, the GTS.CONTROL17 value can also
be supplied in this portion of the message. If supplied, this will override the GTS.CONTROL
settings in the VERSION record.
Similarly, from TEMENOS T24 R4 release onward, the NO.OF.AUTH can also be supplied
in this portion of the message. If supplied, this will override the NO.OF.AUTH settings in the
VERSION record.
Each subdivided part of the options must be separated by a forward slash (/).
USER INFORMATION:
The user information portion of the message structure contains the TEMENOS T24 user that will
perform the transaction. This portion is divided in to user sign on name, password and optionally
company code where:
User sign on name – is the valid TEMENOS T24 sign on name to perform the request
Password – is the password for the user sign on name supplied.
Company – the company name is useful in case of a multi-company setup. In such a case the
company name supplied indicates the company to enter the transaction. If no company information is
supplied then the first company specified in the user profile will be taken as default.
The user information may not be required in some modes of operation (e.g. GLOBUS mode, IBI
transactions)18. The User name, Password and Company code are separated by a forward slash (/)
character (e.g. INPUT/123456/US000001).
TRANSACTION ID:
The transaction ID portion of the message structure contains the transaction number / key for the
applications that are run. The transaction ID is technically the ID of record in the file used in the
transaction. The transaction ID is optional for new transactions if the underlying application is
designed to allow this. In such a case where it is allowed the ID’s may be automatically generated by
the application. The transaction ID is mandatory for See / Authorize / Delete / Print functions. The
transaction ID can also contain an optional Message ID for the message.
MESSAGE DATA:
The message data portion of the message structure contains the data required to create or update the
transaction. The message data portion of the message can be repeated for each field separated by a
comma (,).
Field 1 Field 2 Field 3 Field n

, , ,
Fig 12. OFS Transaction Request – Message Data Syntax structure
17
For detailed information on the GTS.CONTROL, read the “GTS.CONTROL” sub section under the “Controls for
OFS Processing” section, that follows.
18
While using batch mode processing, password need not be supplied. While using Globus mode the currently
signed on user (OPERATOR) is used irrespective of the user name and password supplied in the message.

It is also further subdivided in to 4 different parts as shown in the diagram
Field Multi Sub Field

Name : value : value = content
number number
Fig 13. OFS Transaction Request – Field Data Syntax structure
Where:
Field Name – denotes the name of the field of the application. The field name should be in the
STANDARD.SELECTION record of the application.
Multi value number – denotes a specific multi-value number incase the field is a multi-value field. If
no number is given the first multi-value is assumed.
Sub value number – denotes a specific sub-value number within the multi-value incase the field is a
sub-value field. If no number is given the first sub-value is assumed.
Field content – denotes the content to be added to a specific field the name of which is specified in
the Field Name part mentioned above. The value supplied will be validated by the application.
Each subdivided part of the message data must be separated by a comma (,).
If ‘NULL’ is specified as field data, OFS will blank the field of all data. This should not be used to
remove multi-values or sub values. As with any data entry / modification in OFS, the validation rules
must be observed. Should a mandatory entry field be set to NULL then an error would be generated.
To remove multi-value or sub value fields a minus sign (-) should be entered into the field data. Only
the first field need be specified as a minus to remove a sub or multi value set. If a comma (,) character
is required within the field content then it should be replaced by the ‘?’ (Question mark). All mandatory
fields of the underlying application have to be filled either directly from the message or through the
version (version routines / default) or through OFS pre process user exits. The message data portion
is mandatory for input functions and should contain atleast one field.
For Transaction request message examples click here

Transaction response
Transaction Message Success / Retuned

ID / ID / Fail , Message
Indicator Data
Fig 14. OFS Transaction Response Syntax structure
Normal response syntax from OFS for a transaction request is shown above. A normal response
contains:
TRANSACTION ID – The transaction ID contains either the value supplied for the transaction in the
request or the value that is automatically generated by the TEMENOS T24 application (when no value
is supplied in the request).
MESSAGE ID – The Message ID contains the value of Message ID if supplied in the request.
SUCCESS / FAIL INDICATOR – The success / fail indicator flag indicates the status of the transaction
request processed. OFS returns one of the following values:
1 – Successful transaction.
-1 – Errors encountered during processing.
-2 – Override condition(s) encountered during processing.
-3 – TEMENOS T24 server is offline
RETURNED MESSAGE DATA – A successfully processed message will contain all the fields
populated in the transaction. The format is same as that of the request message data. However for am
unsuccessful transaction the returned message data has a slightly different format.
Field Multi Sub Error

Name : value : value = Message
number number
Fig 15. OFS Transaction Request – Return Error Message Syntax structure
Where:
Field Name – Is the name of the field where an error is returned. The field name is as in the
STANDARD.SELECTION record of the application.
Multi value number – If an error has occurred in a multi value field the multi value field number is
returned. No value is retuned in case of single value fields.
Sub value number – If an error has occurred in a sub value field the sub value field number is
returned. No value is retuned in case of single value fields.
Error Message – The error message returned for the field (associated multi value and sub value if
field is a multi value / sub value field) is returned here.

Special Transactions
FOREX contracts and Loans and deposits contracts may involve input to more than one application in
TEMENOS T24. The OFS module also supports such transactions. These are classified as special
transaction messages in OFS, where the input can be supplied to the main application and a related
application (or sample application but two different records in case of swap contracts), in one single
message. Further explanation is provided below:
FOREX Swaps – Foreign exchange swaps require that information be provided for both legs of a
swap within a single message; in this case information for the first leg is separated from information for
the second leg by an underscore (_). This applies to the multi value number, sub value number, and
field data parts of the message.
Loans and Deposits – A Loans and Deposits contract with a payment schedule requires the
information for the linked application LD.SCHEDULE.DEFINE. This can be done by adding the field
information for LD.SCHEDULE.DEFINE to the Message Data portion of the Loans and deposits
message, separated by 2 forward slashes (//).
When using OFS to update LD.LOANS.AND.DEPOSITS with LD.SCHEDULE.DEFINE, the
GTS.CONTROL field on both versions must be set to 1 where overrides are accepted and errors
placed on hold.

Example Transaction request and response messages19
The example messages shown here may have spaces in between fields (Message Data
portion) for alignment purposes. Make sure to remove any spaces (except the ones in the
Field content) before trying out these messages in your TEMENOS T24 environment. The
message contents, like user name, password and versions may also require some changes
depending upon the setup of your TEMENOS T24 environment.
To revisit “Transaction request” / “Transaction response” sections click on the image placed in
the right corner of the header.
Customer Record Input Request:
CUSTOMER,OFS/I/PROCESS,SRIVATS.1/1234567/US0010001,100707,MNEMONIC::=OFSMSG1,SHORT.
NAME:1:1=OFS1,NAME.1:1:1=OFS USER,STREET:1:1=T24 STREET,TOWN.COUNTRY::=INDIA,
SECTOR::=9900,INDUSTRY::=9900,NATIONALITY::=IN,RESIDENCE::=IN,LANGUAGE::=1
Notice that a VERSION of CUSTOMER application named OFS is supplied in the above
example. Also notice that the function input (I) and an ID are supplied in the message.
Customer Record Input Response:
100707/TCS0306600004/1,MNEMONIC:1:1=OFSMSG1,SHORT.NAME:1:1=OFS1,NAME.1:1:1=OFS USER,
STREET:1:1=T24 STREET,TOWN.COUNTRY:1:1=INDIA,SECTOR:1:1=9900,ACCOUNT.OFFICER:1:1= 85,
INDUSTRY:1:1=9900,TARGET:1:1=999,NATIONALITY:1:1=IN,CUSTOMER.STATUS:1:1=5,RESIDENCE:1:1
=IN,LANGUAGE:1:1=1,CLS.CPARTY:1:1=NO,CURR.NO:1:1=1,INPUTTER:1:1=35_SRIVATS___OFS_TCS,
DATE.TIME:1:1=0412210709,AUTHORISER:1:1=35_SRIVATS_OFS_TCS,CO.CODE:1:1=US0010001,DEPT
.CODE:1:1=1
Funds Transfer Input Request:
FUNDS.TRANSFER,,SRIVATS.1/1234567,,TRANSACTION.TYPE:=AC,DEBIT.ACCT.NO:=46116,DEBIT.CU
RRENCY:=EUR,DEBIT.AMOUNT:=2000,CREDIT.CURRENCY:=EUR,CREDIT.ACCT.NO=19623
Notice that a function and a VERSION for FUNDS.TRANSFER application are NOT supplied
in the above example. While an input function (I) will be assumed by OFS, a comma (,)
VERSION will NOT be used. Also notice that an ID for the FUNDS.TRANSFER transaction is
not supplied in the message.
19
Make sure to read “Transaction response” section before seeing response message examples.

Funds Transfer Input Response:
FT03066001000001/TCS0306600001/1,TRANSACTION.TYPE:1:1=AC,DEBIT.ACCT.NO:1:1=46116,CURRE
NCY.MKT.DR:1:1=1,DEBIT.CURRENCY:1:1=EUR,DEBIT.AMOUNT:1:1=2000.00,DEBIT.VALUE.DATE:1:1=
20030307,CREDIT.ACCT.NO:1:1=19623,CURRENCY.MKT.CR:1:1=1,CREDIT.CURRENCY:1:1=EUR,CRED
IT.VALUE.DATE:1:1=20030307,PROCESSING.DATE:1:1=20030307,CHARGE.COM.DISPLAY:1:1=NO,COM
MISSION.CODE:1:1=DEBIT PLUS CHARGES,CHARGE.CODE:1:1=DEBIT PLUS CHARGES,
PROFIT.CENTRE.CUST:1:1=100657,RETURN.TO.DEPT:1:1=NO,FED.FUNDS:1:1=NO,POSITION.TYPE:1:
1=TR,AMOUNT.DEBITED:1:1=EUR2000.00,AMOUNT.CREDITED:1:1=EUR2000.00,CREDIT.COMP.CODE:
1:1=US0010001,DEBIT.COMP.CODE:1:1=US0010001,LOC.AMT.DEBITED:1:1=1940.81,LOC.AMT.CREDIT
ED:1:1=1940.81,CUST.GROUP.LEVEL:1:1=99,DEBIT.CUSTOMER:1:1=100657,CREDIT.CUSTOMER:1:1=1
045,DR.ADVICE.REQD.Y.N:1:1=Y,CR.ADVICE.REQD.Y.N:1:1=Y,CHARGED.CUSTOMER:1:1=1045,TOT.R
EC.COMM:1:1=0,TOT.REC.COMM.LCL:1:1=0,TOT.REC.CHG:1:1=0,TOT.REC.CHG.LCL:1:1=0,RATE.FIXIN
G:1:1=NO,TOT.REC.CHG.CRCCY:1:1=0,TOT.SND.CHG.CRCCY:1:1=0,STMT.NOS:1:1=VAL,OVERRIDE:1:
1=EXREMFORM/FT*501 FROM 100657 NOT RECEIVED,RECORD.STATUS:1:1=INAU,CURR.NO:1:1=1,
INPUTTER:1:1= 32_SRIVATS___OFS_TCS1, DATE.TIME:1:1=0412200653,
CO.CODE:1:1=US0010001,DEPT.CODE:1:1=1
Notice that the transaction ID automatically generated by the FUNDS.TRANSFER application,

in the reply. Also notice that the record is only in unauthorized state (RECORD.STATUS is
INAU), evidence that a comma or a zero authorizer version is not used by OFS by default!
Funds Transfer Authorize Request:
FUNDS.TRANSFER,/A,SRIVATSAN.1/1234567,FT03066001000002
Notice that only the ID of the already input transaction (in unauthorized status) is supplied in
the above example, when a authorize function (A) is supplied. Also notice that there is no
Message Data portion in the message.
Funds Transfer Authorize Response:
IT.VALUE.DATE:1:1=20030307,PROCESSING.DATE:1:1=20030307,COMMISSION.CODE:1:1=DEBIT PLUS
CHARGES,CHARGE.CODE:1:1=DEBIT PLUS CHARGES,PROFIT.CENTRE.CUST:1:1=1045,
RETURN.TO.DEPT:1:1=NO,FED.FUNDS:1:1=NO,POSITION.TYPE:1:1=TR,AMOUNT.DEBITED:1:1=EUR20
00.00,AMOUNT.CREDITED:1:1=EUR2000.00,DELIVERY.OUTREF:1:1=D20041221000354229300-900.1.1
DEBIT ADVICE,DELIVERY.OUTREF:2:1=D20041221000354229301-910.2.1 CREDIT
ADVICE,CREDIT.COMP.CODE:1:1=US0010001,DEBIT.COMP.CODE:1:1=US0010001,LOC.AMT.DEBITED:
1:1=1940.81,LOC.AMT.CREDITED:1:1=1940.81,CUST.GROUP.LEVEL:1:1=99,DEBIT.CUSTOMER:1:1=104
5,CREDIT.CUSTOMER:1:1=100657,DR.ADVICE.REQD.Y.N:1:1=Y,CR.ADVICE.REQD.Y.N:1:1=Y,CHARGE
D.CUSTOMER:1:1=100657,TOT.REC.COMM:1:1=0,TOT.REC.COMM.LCL:1:1=0,TOT.REC.CHG:1:1=0,TOT
.REC.CHG.LCL:1:1=0,RATE.FIXING:1:1=NO,TOT.REC.CHG.CRCCY:1:1=0,TOT.SND.CHG.CRCCY:1:1=0,A
UTH.DATE:1:1=20030307,STMT.NOS:1:1=135050003542291.00,STMT.NOS:2:1=1-
2,OVERRIDE:1:1=EXREMFORM/FT*501 FROM 1045 NOT RECEIVED, CURR.NO:1:1=1,
INPUTTER:1:1=32_SRIVATS___OFS_TCS,DATE. TIME:1:1=0412211144,
AUTHORISER:1:1=35_SRIVATSAN_OFS_TCS,CO.CODE:1:1=US0010001,DEPT.CODE:1:1=1

Account Record Input Request (with wrong field content):
ACCOUNT,OFS/I/PROCESS,SRIVATS.1/1234567/US0010001,,CUSTOMER::=100708,CATEGORY::=1001,
ACCOUNT.TITLE.1::=T24 OFS ACCOUNT1,SHORT.TITLE::=OFSACCT1,MNEMONIC::=OFSAC1,
CURRENCY::=USD
Account Record Input Response:
90198/TCS0306600013/-1/NO,CUSTOMER:1:1=MISSING CUSTOMER - RECORD
In the above example, a CUSTOMER that does not exist is supplied to create an ACCOUNT
record, in the request message. This is done to illustrate the errors returned in an OFS
response message.
Customer Record Input Request (with missing field):
CUSTOMER,OFS/I/PROCESS,SRIVATS.1/1234567/US0010001,100707,MNEMONIC::=OFSMSG1,SHORT.
NAME:1:1=OFS1,NAME.1:1:1=OFS USER,STREET:1:1=T24 STREET,TOWN.COUNTRY::=INDIA,
SECTOR::=9900,INDUSTRY::=9900,NATIONALITY::=IN,LANGUAGE::=1
Customer Record Input Response:
100707/TCS0306600003/-1/NO,RESIDENCE:1:1=INPUT MISSING
In the above example, the field content for RESIDENCE field is not supplied to illustrate the errors
returned in an OFS response message.
Funds Transfer Reversal Request (with VALIDATE):
FUNDS.TRANSFER,/R/VALIDATE,SRIVATSAN.1/1234567,FT03066001000002
Notice that only the ID of the already input transaction (in unauthorized status) is supplied in
the above example, when a reverse function (R) is supplied. Also notice that there is no
Message Data portion in the message. Also notice that a VALIDATE is supplied in the Options
portion, meaning that normal processing takes place without actually updating the database.

Funds Transfer Reversal Response:
IT.VALUE.DATE:1:1=20030307,PROCESSING.DATE:1:1=20030307,COMMISSION.CODE:1:1=DEBIT PLUS
CHARGES,CHARGE.CODE:1:1=DEBIT PLUS CHARGES,PROFIT.CENTRE.CUST:1:1=1045,
RETURN.TO.DEPT:1:1=NO,FED.FUNDS:1:1=NO,POSITION.TYPE:1:1=TR,AMOUNT.DEBITED:1:1=EUR20
00.00,AMOUNT.CREDITED:1:1=EUR2000.00,DELIVERY.OUTREF:1:1=D20041221000354229300-900.1.1
DEBIT ADVICE,DELIVERY.OUTREF:2:1=D20041221000354229301-910.2.1 CREDIT ADVICE,
CREDIT.COMP.CODE:1:1=US0010001,DEBIT.COMP.CODE:1:1=US0010001,LOC.AMT.DEBITED:1:1=1940
.81,LOC.AMT.CREDITED:1:1=1940.81,CUST.GROUP.LEVEL:1:1=99,DEBIT.CUSTOMER:1:1=1045,CREDIT
.CUSTOMER:1:1=100657,DR.ADVICE.REQD.Y.N:1:1=Y,CR.ADVICE.REQD.Y.N:1:1=Y,CHARGED.CUSTO
MER:1:1=100657,TOT.REC.COMM:1:1=0,TOT.REC.COMM.LCL:1:1=0,TOT.REC.CHG:1:1=0,TOT.REC.CH
G.LCL:1:1=0,RATE.FIXING:1:1=NO,TOT.REC.CHG.CRCCY:1:1=0,TOT.SND.CHG.CRCCY:1:1=0,AUTH.DA
TE:1:1=20030307,STMT.NOS:1:1=VAL,OVERRIDE:1:1=EXREMFORM/FT*501 FROM 1045 NOT
RECEIVED,RECORD.STATUS:1:1=RNAU,CURR.NO:1:1=1,INPUTTER:1:1=32_SRIVATS___OFS_TCS,DA
TE.TIME:1:1=0412211144,AUTHORISER:1:1=35_SRIVATSAN_OFS_TCS,CO.CODE:1:1=US0010001,DEPT
CODE:1:1=1
Special transactions – FOREX Swap contract Input Request:
FOREX,OFS,SRIVATS.1/1234567,,DEAL.TYPE=SW,COUNTERPARTY::=100076,CURRENCY.BOUGHT::=
USD,AMOUNT.BOUGHT::=25000,CURRENCY.SOLD::=GBP,SPOT.RATE::=1.7,DEAL.DATE::=20030310,V
ALUE.DATE.BUY::=20030310_1M,FORWARD.RATE::=_1.55,REVALUATION.TYPE:_1:=_IN,NOTES:1_1="fi
rst leg"_"second leg",NOTES:_2:_"second-line"
Notice that the input is supplied to fields of 2 legs of the FOREX contract. Also notice that the
inputs to the 2 records (legs) are separated by an underscore (_), indicating to OFS that the
data before the underscore (_) belongs to the first leg and the data after, to the second leg of
the swap contract.
Notice the field VALUE.DATE.BUY has spot date for first leg and forward date for second leg.
Also notice the forward rate information is only required for the second leg, so the first leg
information is left blank. Also the input to the field NOTES, will populate the first multi value for
both legs, leave the first leg second multi value blank and populate the second multi value of
the second leg.

Special transactions – FOREX Swap contract Input Response:
FX0306900006/TCS0306900015/1,DEAL.TYPE:1:1=SW,COUNTERPARTY:1:1=100076,DEALER.DESK:1:1
=01,CURRENCY.MARKET:1:1=1,CURRENCY.BOUGHT:1:1=GBP,AMOUNT.BOUGHT:1:1=14705.88,VALU
E.DATE.BUY:1:1=20030410,CURRENCY.SOLD:1:1=USD,AMOUNT.SOLD:1:1=22794.11,VALUE.DATE.SEL
L:1:1=20030410,SPOT.RATE:1:1=1.70,FORWARD.RATE:1:1=1.55,SWAP.BASE.CCY:1:1=GBP,LIMIT.REFE
RENCE.NO:1:1=1030.01,POSITION.TYPE.BUY:1:1=TR,POSITION.TYPE.SELL:1:1=TR,DEAL.DATE:1:1=20
030310,REVALUATION.TYPE:1:1=IN,SPOT.DATE:1:1=20030312,BASE.CCY:1:1=GBP,SPOT.LCY.AMOUN
T:1:1=25000.00,SWAP.REF.NO:1:1=FX0306900005,SWAP.REF.NO:2:1=FX0306900006,INT.RATE.BUY:1:1
=6.375,INT.RATE.SELL:1:1=-103.8005918475107,OUR.ACCOUNT.PAY:1:1=26937,OUR.ACCOUNT.
REC:1:1=26767,DEL.DATE.BUY:1:1=20030410,DEL.AMOUNT.BUY:1:1=14705.88,DEL.DATE.SELL:1:1=200
30410,DEL.AMOUNT.SELL:1:1=22794.11,CPARTY.CORR.NO:1:1=100318,ACTIVITYCODE:1:1=1010,CON
FIRM.SENT:1:1=D20050110000344031000,BUY.LCY.EQUIV:1:1=-25000.00,SEL.LCY.EQUIV:1:1=22794.11,
BUY.DAILY.ACC.L:1:1=10.34,BUY.ACC.TDATE.L:1:1=0.00,BUY.DAILY.ACC.F:1:1=2.57,BUY.ACC.TDATE.F
:1:1=0.00,SEL.DAILY.ACC.L:1:1=-65.72,SEL.ACC.TDATE.L:1:1=0.00,SEL.DAILY.ACC.F:1:1=-65.72,SEL.
ACC.TDATE.F:1:1=0.00,SWIFT.COMMON.REF:1:1=DRESKX0155XXXXXX,CATEGORY.CODE:1:1=20030,
ACCOUNT.OFFICER:1:1=90,FED.FUNDS:1:1=C,SEND.CONFIRMATION:1:1=NORMAL,SEND.PAYMENT:1
:1=NORMAL,SEND.ADVICE:1:1=NORMAL,NOTES:1:1=second leg,TOTAL.INT.BOUGHT:1:1=74.49,TOTAL.
INT.SOLD:1:1=-1905.98,EQUIV.INT.BOUGHT:1:1=299.91,EQUIV.INT.SOLD:1:1=-1905.98,INT.BASIS.
BOUGHT:1:1=E,INT.BASIS.SOLD:1:1=B,TRANSACTION.TYPE:1:1=SW,NETTING.STATUS:1:1=N,AMORTI
SE.POSITION:1:1=NO,SWAP.PL.FWD.POS:1:1=NO,SOD.MAT:1:1=NO,CLS.DEAL:1:1=NO,OVERRIDE:1:1=
Negative rate used,OVERRIDE:2:1=Spot rate exceeds tolerance by &{9.68%,OVERRIDE:3:1=NO.LINE}NO
LINE ALLOCATED,CURR.NO:1:1=1,INPUTTER:1:1=34_SRIVATS___OFS_TCS,DATE. TIME:1:1=
0501101111,AUTHORISER:1:1=34 SRIVATS OFS TCS,CO.CODE:1:1=US0010001,DEPT.CODE:1:1=1
Notice the reply contains only the second leg. This is because, technically it is the last
transaction (last record update) performed by the OFS though there was only one request.
Notice that the field SWAP.REF.NO contains the reference (transaction ID) of the first leg, thus
indicating the first leg transaction was also successful.
Special transactions – Loans and Deposits Input Request (with schedules):
LD.LOANS.AND.DEPOSITS,OFS,SRIVATS.1/1234567,,CUSTOMER.ID::=50043,CURRENCY::=USD,AMOU
NT::=5000,FIN.MAT.DATE::=20040601,CATEGORY::=21030,INTEREST.RATE::=4.00,CAPITALISATION::=
NO,ISSUE.PRICE::=50,AUTO.SCHEDS::=NO,DEALER.DESK::=00,DEFINE.SCHEDS::=YES//CURRENCY:1
:1=USD,FORWARD.BACKWARD::=4,BASE.DATE.KEY::=3,SCH.TYPE:1:1:=I,DATE:1:1:=20040601,CURRE
NCY:2:1=USD,SCH.TYPE:2:1:=P,DATE:2:1:=20040601,AMOUNT:2:1:=5000
Notice that the input is supplied to fields of 2 applications – namely LD and schedules. Also
notice that the input to the 2 applications is separated by 2 forward slashes (//), indicating to
OFS that the first part of the message belongs to LD.LOANS.AND.DEPOSITS and the second
part to LD.SCHEDULE.DEFINE.

Special transactions – Loans and Deposits Input Response (with schedules):
LD0306900014/TCS0306900010/1,CUSTOMER.ID:1:1=50043,CURRENCY:1:1=USD,CURRENCY.MARKET
:1:1=1,AMOUNT:1:1=5000.00,BUS.DAY.DEFN:1:1=US,VALUE.DATE:1:1=20030310,FIN.MAT.DATE:1:1=20
040601,LIMIT.REFERENCE:1:1=9900.01,CATEGORY:1:1=21030,DRAWDOWN.ACCOUNT:1:1=20087,INT.
RATE.TYPE:1:1=1,INTEREST.BASIS:1:1=B,INT.PAYMT.METHOD:1:1=1,INTEREST.RATE:1:1=4,FIRST.DA
Y.ACCRUAL:1:1=YES,CAPITALISATION:1:1=NO,TOT.INTEREST.AMT:1:1=249.44,LIQUIDATION.CODE:1:
1=1,LIQUIDATION.MODE:1:1=AUTOMATIC,POSITION.TYPE:1:1=TR,DELIVERY.LINK:1:1=1,PRIN.LIQ.AC
CT:1:1=20087,INT.LIQ.ACCT:1:1=20087,CHRG.LIQ.ACCT:1:1=20087,MIS.ACCT.OFFICER:1:1=5,FEDERAL
.FUNDS:1:1=NO,AGREEMENT.DATE:1:1=20030310,STATUS.CONTROL:1:1=AUTOMATIC,STATUS:1:1=C
UR,DRAWDOWN.ISSUE.PRC:1:1=5000.00,DRAWDOWN.NET.AMT:1:1=5000,ISSUE.PL.AMOUNT:1:1=0,IS
SUE.PRICE:1:1=100,ISSUE.ACCRUAL:1:1=NO,REIMBURSE.PRICE:1:1=100,REIMBURSE.AMOUNT:1:1=5
000.00,REIMBURSE.ACCRUAL:1:1=NO,FEE.PAY.ACCOUNT:1:1=20087,DRAWDOWN.ENT.DATE:1:1=200
30310,AUTO.SCHEDS:1:1=NO,DEFINE.SCHEDS:1:1=YES,SEND.PAYMENT:1:1=Y,SEND.CONFIRMATIO
N:1:1=Y,CONTRACT.GRP:1:1=2,YIELD.METHOD:1:1=NO,SETTLEMENT.MARKET:1:1=1,CONVERSION.T
YPE:1:1=MID,LAST.DAY.ACCRUAL:1:1=NO,DEFAULTED.VALUE:1:1=YES,DEALER.DESK:1:1=00,NEGATI
VE.RATE:1:1=NO,STMT.NO:1:1=VAL,OVERRIDE:1:1=ACCT.UNAUTH.OD}Unauthorised overdraft of & & on
account &.{USD}126000}20087{USD{126000{20087{50043{401{{,RECORD.STATUS:1:1=INAU,CURR.
NO:1:1=1,INPUTTER:1:1=34_SRIVATS___OFS_TCS,INPUTTER:2:1=34_SRIVATS___OFS_TCS,DATE.TIM
E:1:1=0501100932,CO.CODE:1:1=US0010001,DEPT.CODE:1:1=1//CURRENCY:1:1=USD,FORWARD.BAC
KWARD:1:1=4,BASE.DATE.KEY:1:1=3,SCH.TYPE:1:1=I,SCH.TYPE:2:1=P,DATE:1:1=20040601,DATE:2:1=
20040601,AMOUNT:2:1=5000.00,CYCLED.DATES:1:1=20040601,CYCLED.DATES:2:1=20040601,RECOR
D.STATUS:1:1=INAU,CURR.NO:1:1=1,INPUTTER:1:1=34_SRIVATS___OFS_TCS,INPUTTER:2:1=34_SRIV
ATS___OFS_TCS,DATE.TIME:1:1=0501100932,CO.CODE:1:1=US0010001,DEPT.CODE:1:1=1
Notice that the response contains data from 2 applications – namely LD and schedules. Also
notice that the data to the 2 applications separated by 2 forward slashes (//), indicating that the
part before the forward slashes (//) belongs to LD.LOANS.AND.DEPOSITS and the part after
to LD.SCHEDULE.DEFINE.

Enquiry request
ENQUIRY. User Enquiry Message

SELECT , , Information , Name , Data
Fig 16. OFS Enquiry Request Syntax structure
The syntax structure of OFS Enquiry type request messages is shown above. Each portion of the
request message is separated by a comma (,). The portions are explained as under:
ENQUIRY.SELECT:
The first portion of an enquiry type request must always be ENQUIRY.SELECT. The
ENQUIRY.SELECT is actually a TEMENOS T24 application that is used to run queries and return the
data.
USER INFORMATION:
The user information portion of the message structure is same as that in the transaction request type
explained above.
ENQUIRY.NAME:
The enquiry name portion of the message structure must contain the name of the TEMENOS T24
Enquiry that will be run. The Enquiry name supplied here must be a valid TEMENOS T24 enquiry (i.e.
must be found in the ENQUIRY application of TEMENOS T24). This portion of the message is
mandatory.
MESSAGE DATA:
The message data portion of the enquiry message structure contains the selection criteria passed to
the enquiry. The message data portion of the message can be repeated for each selection criteria
separated by a comma (,).
Selection Selection Selection Selection

Criteria 1 , Criteria 2 , Criteria 3 , Criteria n
Fig 17. OFS Enquiry Request – Message Data Syntax structure
Each selection criteria is also further subdivided in to 3 different parts as shown in the diagram
Selection Operand Field

Field : = Value
Fig 18. OFS Enquiry Request – Selection criteria Syntax structure

Where:
Selection Field – denotes the name of the field of that must be either a field in the
STANDARD.SELECTION for the file name specified in FILE.NAME field of the ENQUIRY application
or a value set in SELECTION.FLDS field of the ENQUIRY application.
Operand – denotes the operand that must be used for selection for the value specified in the
SELECTION.FLDS field of the ENQUIRY application. The operands can be EQ, NE, GE, GT, LE, LT,
UL, LK and NR.
Field Value – denotes the data value for the values specified in the SELECTION.FLDS (field of the
ENQUIRY application) and the operand for selection.
Each subdivided part of the message data must be separated by a comma (,).
Also notice the two commas (,,) between the ENQUIRY.SELECT and User information portions of the
message structure. This denotes that the OPTIONS portion must not be used for enquiry type
requests.
For Enquiry request message examples click here

Enquiry response
Header Column Returned

Caption : Details = Data
Details
Fig 19. OFS Enquiry Response Syntax structure
Normal response syntax from OFS for an enquiry request is shown above. Each portion is further
subdivided.
HEADER CAPTION DETAILS:

The Header Caption portion is subdivided as shown in the diagram below.
Header / Header
Caption = Text / ,
Identifier
Fig 20. OFS Enquiry Response – Header / Caption Details Syntax structure
Header / Caption Identifier – This contains an identifier to determine which element of the header /
caption is being defined. May be alphanumeric defined in the underlying ENQUIRY.
Header Text – The Header Text contains the text for the corresponding identifier.
Each repeating series of header definitions is separated by a forward slash (/) character.
COLUMN DETAILS:
The Column Details portion is subdivided as shown in the diagram below.
Column Column Column

Identifier : Format : Label / ,
Type
Fig 21. OFS Enquiry Response – Column Details Syntax structure
Column Identifier – This contains the column identifier, which can be a name or a number. Contains
the OPERATION field value in the underlying ENQUIRY
Column Format Type – This c

ontains the type of data contained in the column. This information can be used for formatting. Possible
types include:
DATE – Formatted using standard date formats
AMOUNT – Formatted to an amount with decimal format
Column Label – This contains the field label as specified in the FIELD.LBL of the underlying
ENQUIRY. In the absence of an entry in FIELD.LBL , column label defaults to the value of column
identifier.
Each series of column details is followed by a forward slash (/) character.
RETURNED DATA:
The Returned Data portion is subdivided as shown in the diagram below.
Row
Tab ,
Value
Column n
Fig 22. OFS Enquiry Response – Return Data Syntax structure
Row Value Column – Each row will be comprised of a number of columns defined in the previous
element of the message data.
For each column the value will be returned separated by a tab character.
Each row is separated by a comma (,).

Example Enquiry request and response messages20
The example messages shown here may have spaces in between fields (Message Data
portion) for alignment purposes. Make sure to remove any spaces (except the ones in the
Field content) before trying out these messages in your TEMENOS T24 environment. The
message contents, like user name and password may also require some changes depending
upon the setup of your TEMENOS T24 environment.
To revisit “Enquiry request” / “Enquiry response” sections click on the image placed in the right
corner of the header.
Currency List Request:
ENQUIRY.SELECT,,SRIVATS.1/1234567,CURRENCY-LIST
Notice that the Message Data portion is not supplied in the above example. The CURRENCY-
LIST is the name of the ENQUIRY to be run.
Currency List Response:
,,"ATS" "Austrian Schilling ","AUD" "Australian Dollars ","BEF" "Belgian Franc

","CAD" "Canadian Dollar ","CHF" "Swiss Franc ","DEM" "Deutsche Mark
","DKK" "Danish Krone ","ESP" "Spanish Peseta ","EUR" "Euro
","FIM" "Finnish Markka ","FRF" "French Franc ","GBP" "Pound Sterling
","GOL" "BULLION ","GRD" "Greek Drachma ","HKD" "Hong Kong Dollar
","IEP" "Irish Punt ","ITL" "Italian Lira ","JPY" "Japanese Yen
","LBP" "Lebanese Pounds ","LUF" "Luxembourg Franc ","NLG" "Netherlands
Guilder ","NZD" "New Zealand ","PLA" "PLATINUM ","PLN"
"Polish Zloty ","PTE" "Portuguese Escudo ","SEK" "Swedish Krone
","SGD" "Singapore Dollars ","SIL" "SILVER ","USD" "US Dollar
","XEU" "Euro ","ZAR" "South African Rand "
Customer Position Enquiry Request (with selection):
ENQUIRY.SELECT,,SRIVATS.1/1234567,CUSTOMER.POSITION,CUSTOMER.NO:EQ=300102
Notice that a dynamic selection condition - CUSTOMER.NO equals (EQ) “300102” is supplied
in the above example.
20
Make sure to read “Enquiry response” section before seeing response message examples.

Customer Position Enquiry Response (with selection):
HEADER=@ID/HEADER=F DISP.CUST/HEADER=F CUSTOMER/HEADER=F ACCT.OFFICER,

MODULE::MODULE/TXN.REF::TXN.REF/DISPLAY.NARRATIVE::DISPLAY.NARRATIVE/DEAL.CCY::DEAL.
CCY/DISP.AMT::DISP.AMT/MARGIN.DISP::MARGIN.DISP/FORWARD.IND::FORWARD.IND/COLL.RGHT.C
OVER::COLL.RGHT.COVER/COLL.RIGHT::COLL.RIGHT,"AC" "36005" "ABC ACCTS USD1 " "USD"
" 38,090.00 " "" "" " " " ","300102" "ABC ACCOUNTANTS PLC LTD
","1000" "THEO ELS ","" "" " ACCRUED INTEREST 512.76" "" "" "" ""
" " " ","AC" "36013" "ABC ACCTS USD2 " "USD" " 0.00 " "" "" "
" " ","" "" " ACCRUED INTEREST 6.44" "" "" "" "" " " "
","AC" "36048" "ABC USD CASH POOL ACCT " "USD" " 15,122,432.80 " "" "" " " "
","" "" " ACCRUED INTEREST" "" "" "" "" " " " ","AC" "36021" "ABC
ACCTS USD SAV1 " "USD" " 5,000,000.00 " "" "" " " " ","" "" "
ACCRUED INTEREST""" "" "" "" " " " ","AC" "36037" "ABC ACCTS USD
SAV2 " "USD" " 2,000,000.00 " "" "" " " " ","" "" " ACCRUED
INTEREST" "" "" "" "" " " " ","TOTAL VALUE IN LOCAL CCY" "
22,160,522.80 "
Customer List Request (with wrong selection):
ENQUIRY.SELECT,,SRIVATS.1/1234567,CUSTOMER-LIST,ACCOUNT.NO:EQ=1234
In the above example, a selection field (ACCOUNT.NO), that is invalid for the ENQUIRY is
supplied to illustrate the errors returned in an OFS response message.
Currency List Response:
,,"No records were found that matched the selection criteria”,” SELECTION FIELD ACCOUNT.NO NOT
FOUND IN STANDARD SELECTION FOR FILE MNEMONIC CUSTOMER
LIAB Enquiry Request (with missing mandatory selection):
ENQUIRY.SELECT,,SRIVATS.1/1234567,LIAB
In the above example, a mandatory selection field (LIABILITY.NUMBER), for the ENQUIRY is
not supplied to illustrate the errors returned in an OFS response message.
LIAB Enquiry Response:
LIABILITY.NUMBER - MANDATORY INPUT

Routine request
Custom User Custom

Routine , , Information , , Data
Name
Fig 23. OFS Routine Request Syntax structure
The syntax structure of OFS routine type request messages is shown above diagram. The portions of
the request message are comma (,) separated. The portions are explained as under:
CUSTOM ROUTINE NAME:

The Custom Routine Name is the name of the subroutine that must be called by OFS. A valid
subroutine name must be supplied for routine request type messages. The routine name must have a
PGM.FILE record entry with the TYPE field value set to “S” or “M”.
USER INFORMATION:
The user information portion of the message structure is same as that in the transaction request type
explained above.
CUSTOM DATA:
The custom data portion of the message structure is optional and has any string that must be passed
as an argument to the Custom Routine Name mentioned above.
The custom subroutine must be built with 2 arguments, one for input and other for output. The
subroutine must be compiled without errors, in the TEMENOS T24 server environment used.
Also notice the two commas (,,) between the Custom Routine name, User information and Custom
Data portions of the message structure. This denotes that the OPTIONS and TRANSACTION ID
portions is not used for routine type requests.
For Routine request message examples click here

Routine response
Custom Return
Data
Fig 24. OFS Routine Response Syntax structure
There is no standard syntax structure laid down by the OFS for routine type responses.
CUSTOM RETURN DATA:

The Custom Return Data is the optional output string the custom built subroutine may return. This is
nd
actually the final (returned) value of the 2 argument of the subroutine (after the call). Though this is
optional it is highly recommended that your subroutine return a meaningful value to avoid any
problems that may arise otherwise.

Example Routine request and response messages21
To illustrate the Routine request, a small subroutine is provided. Make sure to copy and
compile (EB.COMPILE) the given subroutine in your TEMENOS T24 environment and create
a PGM.FILE entry as shown, before trying out these messages. The message contents, like
user name and password may also require some changes depending upon the setup of your
TEMENOS T24 environment.
To revisit “Routine request” / “Routine response” sections click on the image placed in the
right corner of the header.
To revisit “Subroutine source code” box click on the image placed on the right side of the
header.
Subroutine source code (jBASE / jBC):
SUBROUTINE T24.ECHO.ROUTINE(Y.REQUEST, Y.RESPONSE)

!***********************************************************************************
! Subroutine to return the string passed thru the Y.REQUEST argument)
! Arguments:
! Y.REQUEST - contains the incoming string
! Y.RESPONSE - contains the echo'ed back string
!***********************************************************************************
!
IF Y.REQUEST NE '' THEN ; * Check for emptiness
Y.RESPONSE = "Received from OFS : " : Y.REQUEST ; * Talk back !
END ELSE
Y.RESPONSE = "Did not receive anything from OFS" ; * Tell ‘em !
END
!
RETURN
!
END
Notice that the illustrated subroutine has two arguments – one for input and second for output.
This is a must, failing which a “SUBROUTINE_PARM_ERROR22” will be encountered. Also
notice the return message passed back to the caller (in our case OFS).
21
Make sure to read “Routine response” section before seeing response message examples.
22 ®
For detailed information on “SUBROUTINE_PARM_ERROR” refer to jBASE manuals.

PGM.FILE record for the subroutine:
Type set to “S”
Fig 25. PGM.FILE Record for subroutine T24.ECHO.ROUTINE
Create a PGM.FILE record for the subroutine - T24.ECHO.ROUTINE as shown in the above.
Notice the value “S” setup in “Type” field of the PGM.FILE indicating that it is a Subroutine.
Subroutine request (with Custom Data portion):
T24.ECHO.ROUTINE,,SRIVATS.1/1234567,,Hello T24
Notice that the custom subroutine created – T24.ECHO.ROUTINE is supplied in the Custom
Routine Name portion of the message. Also notice the Custom Data portion supplied as an
argument to the subroutine.
Subroutine response:
Received from OFS : Hello T24

Notice that the string returned by OFS, is the string assigned to the output argument (variable)
– Y.RESPONSE, in the custom subroutine – T24.ECHO.ROUTINE. This shows that the
Custom Data portion supplied in the request message is passed to the subroutine through the
incoming argument (variable) – Y.REQUEST.
Subroutine request (without Custom Data portion):
T24.ECHO.ROUTINE,,SRIVATS.1/1234567
Notice that the Custom Data portion is not supplied in the above given example message,
indicating that the subroutine does not receive any value in the incoming argument (variable) –
Y.REQUEST.
Subroutine response:
Did not receive anything from OFS
Notice that since no string is passed to the custom subroutine – T24.ECHO.ROUTINE, the
above given string is received.

9. I_GTS.COMMON – OFS Common variables

The I_GTS.COMMON contains the common variables of the OFS module. Inserting this in the
programs makes them available for use during the OFS processing. For instance, a subroutine
attached in MSG.PRE.RTN field of OFS.SOURCE can make use of the common variables of the OFS
module by inserting the I_GTS.COMMON file. Following a list of some important common variables
found inside this insert file along with their purpose:
GTSACTIVE – Flag to indicate if OFS is used for the message being

processed
OFS$SOURCE.ID – ID of the OFS.SOURCE record that is currently being used
OFS$SOURCE.REC – Dynamic array containing the OFS.SOURCE record that is
currently being used
OFS$GLOBMAN.ACTIVE – Flag to indicate if OFS Globus mode
(OFS.GLOBUS.MANAGER) is used for the message being
processed

10. Controls for OFS Processing

The OFS processing can be controlled using some settings available at the VERSION /
VERSION.CONTROL level. These settings control the processing behavior of OFS such as handling
of validation errors, overrides and what to do when a record with same ID exists in the NAU file (NAU
processing). The following section explains the various controls available and how they can be used.
GTS.CONTROL
This is a field in VERSION and VERSION.CONTROL applications, which can be used to control the
outcome of an OFS transaction in case it is faced with an error message and / or an override message
from the application being processed. Any one of the following values is allowed:
Null (Reject errors / Approve overrides):

When no value is specified in this field, validation errors will result in the record being rejected, the
OFS data record will be returned with details of the error message. Overrides will be accepted by
default, the overrides will be returned in the populated OFS data record.
1 (Errors on HLD / Approve Overrides):

When a value “1” is specified in this field, validation errors will place the record on hold, the OFS data
record will be returned with the error messages. Overrides will be accepted by default, the values
approved will be returned in the populated OFS record.
2 (Errors Rejected / Overrides in HLD):

When a value “2” is specified in this field, validation errors will result in the record being rejected, the
OFS data record will be returned with the error messages. Overrides will result in the record being
placed on hold.
3 (Errors in HLD / Overrides HLD):

When a value “3” is specified in this field, validation errors will place the record on hold, the OFS data
record will be returned with the error messages. Overrides will result in the record being placed on
hold; the OFS data record returned will store the override message.
4 (Hold Only):
When a value “4” is specified in this field, OFS will place all records in HLD status immediately, no
further validation or processing will take place.
When specifying this value at the VERSION.CONTROL application, if the value in this field is
not present in the corresponding field in VERSION record, then the value is appended to the
corresponding field in the VERSION record.
Additionally, the following fields are present in the VERSION.CONTROL application as associated
multi-values including / along with the GTS.CONTROL field.

GTS.VALUE
The values specified in this field will be used to check against the environment variable specified in
GTS.TYPE (see next field) to determine if the GTS.CONTROL value will be included in the VERSION.
E.g. If GTS.TYPE has USER>COMPANY.CODE then the value in GTS.VALUE should contain a valid
COMPANY code such as US0010001.
GTS.TYPE
This field allows the user to specify the environment variables. The system will use these variables to
check against the value specified in GTS.VALUE. If it matches then the field will be included in the
version, provided GTS.INC.EXC is set to “INCLUDE”. The following rules apply:
It can be Application>fieldname (e.g. USER>COMPANY.CODE) where the application can be

USER or COMPANY only.
It can also be a subroutine, for which the following conditions apply:
– When a subroutine needs to be called, then the subroutine name should be prefixed
with an @ symbol
– The subroutine entered should exist in PGM.FILE with PGM.TYPE = 'S'
– The APPLICATION should exist in field APPR.FOR.SUBR in the PGM.FILE record for
the subroutine.
GTS.INC.EXC
This field allows the values “INCLUDE” or “EXCLUDE”. Given that the condition in GTS.VALUE and
GTS.TYPE is satisfied,
If this field is set to INCLUDE then the field specified in GTS.CONTROL will be set as GTS
control in the Version.
If this field is set to EXCLUDE then the field specified in GTS.CONTROL will not be set as
GTS control in the Version.

NAU.PROCESSING
This is a field in VERSION application that facilitates to specify the optional functionality for processing
of transactions via OFS where $NAU record exists. In essence, this field tells OFS of what it should do
when a record with same ID as passed in OFS message, exists in the $NAU file of the application.
The following are the values allowed and their meaning:
0 – Reject messages where an NAU record exists.

1 – Overwrite NAU record with OFS data, i.e. fields from the OFS record will be written to the
NAU record. If the VERSION has 0 authorizers and the user associated with the OFS
message, is the only user on the NAU record then process as normal. If the Users are not the
same, write the OFS field data onto the NAU record and write the record to the unauthorized
file.
2 – Accept Reversal as Deletion (or deletion of NAU record + reversal of live record if live
record exists), if an NAU record exists.
3 – Apply both option 1 and option 2 to this version, i.e. If OFS transaction is an Input then
process as per option 1. If OFS transaction is Reversal process as per option 2.
When this field is left empty then, OFS would approve the override “YOU OVERTAKE WORK OF
ANOTHER INPUTTER” and overlay the record passed in the message over the existing NAU record
and authorize (as permitted by the NO.OF.AUTH).
NOFS – Preventing updates through OFS

The field ADDITIONAL.INFO of PGM.FILE application can used to specify any special attributes or
characteristics that a program or batch process must have. It is possible to block applications from
being used with OFS by any user. This may be done by specifying the value “NOFS” in the
ADDITIONAL.INFO field of the PGM.FILE for the application to be blocked.
As the PMG.FILE application controls various aspects of the running of applications, changes should
only be made with the utmost caution. While specifying “.NOFS” in the ADDITIONAL.INFO field will
simply prevent the use of OFS on that application, other changes could damage the integrity of the
system.

11. Inter application OFS calls

Inter application OFS calls were previously were made through OFS.GLOBUS.MANAGER. An
application could thus directly send OFS message to another application using
OFS.GLOBUS.MANAGER. This API has been deprecated from R5 release onwards. An API called
OFS.POST.MESSAGE has been introduced to facilitate inter-application OFS calls.
OFS.POST.MESSAGE
Syntax:
OFS.POST.MESSAGE(Y.OFS.MESSAGE, OFS.MSG.ID, OFS.SOURCE.ID, OPTIONS)
Explanation:
• Application name, record id and field information's will be passed through the first argument
Y.OFS.MESSAGE
• OFS.SOURCE.ID must be the id of a record in OFS.SOURCE with type GLOBUS

The VERSION or VERSION.CONTROL routine calls OFS.POST.MESSAGE, passing the
OFS.SOURCE record to use and one or many OFS messages (multiple OFS messages are usually
delimited by a value mark - VM). OFS.POST.MESSAGE writes the request out to the
OFS.MESSAGE.QUEUE file, and sends the record key as the response to the calling routine.
OFS.MESSAGE.QUEUE is the trigger table for OFS.MESSAGE.SERVICE.
OFS.MESSAGE.SERVICE
OFS.MESSAGE.SERVICE is a standard T24 service with its own workload profile. Ensure that the
OFS.MESSAGE.SERVICE is started by committing the TSA.SERVICE record with the
SERVICE.CONTROL set to AUTO. And yes, TSM service must also be running.

Fig 26: TSA.SERVICE ENTRY for OFS.MESSAGE.SERVICE
A sample TSA.WORKLOAD .PROFILE record for the OFS.MESSAGE.SERVICE is shown below
Fig 27: TSA.WORKLOAD.PROFILE for OFS.MESSAGE.SERVICE
Notice the use of a single agent for this profile
This service picks up the message and processes through OFS.PROCESS.MANAGER. Once
processed, the record is removed from OFS.MESSAGE.QUEUE and posted to
OFS.RESPONSE.QUEUE with the same key. The record will contain an OFS response success/fail
flag in the first field and the actual OFS response in the 2nd field.

OFS.RESPONSE.QUEUE
A second service, OFS.RESPONSE.QUEUE, purges the OFS.RESPONSE.QUEUE file according to

the minutes entered into the ATTRIBUTE.VALUE field on the TSA.SERVICE record. If a record is
older than the time in ATTRIBUTE.VALUE, it will be deleted.
Fig 28: TSA.SERVICE entry for OFS.RESPONSE.QUEUE
The ATTRIBUTE.TYPE and ATTRIBUTE.VALUE fields are not validated as they are free
form fields to be used by TSA.SERVICE records to contain any value that a service may
require.
For OFS.RESPONSE.QUEUE, the duration (in minutes) is entered into the

ATTRIBUTE.VALUE field. If a numeric value is not entered into this field, records will not be
purged from the OFS.RESPONSE.QUEUE file when this service is run.
This service has a workload profile similar to that of OFS.MESSAGE.SERVICE. A sample profile is
shown below
Fig 29: TSA.WORKLOAD.PROFILE entry for OFS.RESPONSE.QUEUE

Sample
Let us look at a sample scenario to illustrate inter-application calls.
Normally, an address record is created for each customer when a new customer is authorized. But ,
suppose there is a need to maintain two addresses for each customer; how, then do we create a
second address record? This can be done using an auth routine attached to the version of
CUSTOMER, which would populate DE.ADDRESS with the details of the second address, when the
CUSTOMER record is authorized. This auth routine should do the following;
• Check if the customer record being authorized is a new customer record

• Get the value for the second address through a local reference field.
– Use LOCAL.TABLE & LOCAL.REF.TABLE for local ref field
• Form a record for the DE.ADDRESS file with the short name, name.1, name.2 and
street.address.The first 3 fields should be extracted from the corresponding fields in the
customer record and street.address from the local reference field.
• Form the id of the DE.ADDRESS file
• Write the record formed into the DE.ADDRESS file using the routine OFS.POST.MESSAGE
How do we form the id of the second DE.ADDRESS record?

• DE.ADDRESS records have ids usually created in the following format
– company-id.C-customer-id.PRINT.1
• We would then need to create an id in the format
– Companycode.C-CustomerNo.PRINT.2
– Eg: US0010001.C-100069.PRINT.2
How do we get the current COMPANY id?

• We use the common variable ID.COMPANY

Subroutine source code (jBASE / jBC):
SUBROUTINE V.TRG.AUTH.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
$INSERT I_F.DE.ADDRESS
GOSUB INIT
GOSUB OPENFILES
GOSUB PROCESS
RETURN
*
INIT:
FN.CUS = 'F.CUSTOMER'
F.CUS = ''
Y.ADDRESS = ''
RETURN
OPENFILES:
CALL OPF(FN.CUS,F.CUS)
RETURN
PROCESS:
IF R.OLD(1) = '' THEN ;* If it is a new record being authorised
* Form the id of the DE.ADDRESS record
Y.DE.ADDRESS.ID = ID.COMPANY:'.C-':ID.NEW:'.PRINT.2‘
Y.ADDRESS = R.NEW(EB.CUS.LOCAL.REF)<1,7>
Y.OFS.REC=“DE.ADDRESS,,INPUTT/654321,":Y.DE.ADDRESS.ID:",SHORT.NAME=":R.NEW(EB.
CUS.SHORT.NAME):",NAME.1=":R.NEW(EB.CUS.NAME.1):",NAME.2=":R.NEW(EB.CUS.NAME.2)
:", STREET.ADDR=":Y.ADDRESS
OFS.MSG.ID="“
OFS.SOURCE.ID=“TRG.OFS.GLOBUS“
OPTIONS="“
CALL OFS.POST.MESSAGE (Y.OFS.REC, OFS.MSG.ID, OFS.SOURCE.ID, OPTIONS)
END
RETURN
END

TRG.GLOBUS.OFS is a GLOBUS type OFS record
(EB.CUS.LOCAL.REF)<1,7> . Verify the position of the LOCAL.REF field on your T24 area
Test this solution as follows
• Create and add a local reference field called ADDRESS2 to CUSTOMER

• Note the position of this field
• Create a version of the CUSTOMER application with all the mandatory fields and the local ref
field ADDRESS2
• Enter the subroutine shown in the previous page, compile and catalogue it
• Attach the subroutine to the Auth.Rtn field of the CUSTOMER version.
• Enter a new customer record using the version
• Authorise the record
• Check if OFS.MESSAGE.QUEUE has been updated
• Start the following services
• TSM
• OFS.MESSAGE.SERVICE
• Check if the message has been removed from OFS.MESSAGE.QUEUE
• Check if you have the response in OFS.RESPONSE.QUEUE

APPENDIX A – Common OFS error messages

Various error messages may be encountered during processing messages using the OFS module.
This section deals with most common set of error messages that may be encountered.
NOTE: The list of errors covered here is not exhaustive. Also this section does not
cover the validation / other errors related to / thrown by the applications / enquiries /
subroutine supplied in the OFS messages. For such errors refer to their respective user
guides
Error messages related to the OFS module could be broadly classified in to 3 categories as follows:
Message related errors

These errors are encountered when there are problem(s) with the format of the request messages. To
overcome these errors the request messages have to be analyzed carefully and corrected to satisfy
the format requirements 23 laid down by the OFS modules. The following is the list of common
message related error messages.
APPLICATION / OPERATION MISSING:

This error message is encountered when the request message is either empty or does not contain the
name of the application / subroutine / Enquiry select (in case of enquiry messages), in the first portion
of the request message. To overcome this, supply the required name in the first portion of the request
message.
NO SIGN ON NAME SUPPLIED DURING SIGN ON PROCESS:

This error message is encountered when the request message does not contain the TEMENOS T24
user sign on name / password in the User information portion of the request message. To overcome
this, supply a valid TEMENOS T24 user name and password in the User information portion of the
request message.
The User information portion may not be required in some modes of operation. For example,
while using batch mode processing, password need not be supplied. While using Globus
mode the currently signed on user (OPERATOR) is used irrespective of the user name and
password supplied in the message
System related errors

The TEMENOS T24 Server returns these errors when there are restrictions to processing. The
restrictions may be due the status of the TEMENOS T24 Server at the time of processing – i.e.
OFFLINE or due to restrictions with in the application used in the transaction e.g. application used is
an invalid program type. The following is the list of common system related error messages.
23
Format requirements are covered in the “OFS Message Syntax” section.

<Message ID>/<Transaction ID>/-3/OFFLINE:

This error message is encountered when the TEMENOS T24 Server is in offline status at the time the
request message is received by it. In this stage inputs / updates to the database will not be allowed.
The request message has to be resent to TEMENOS T24 Server when it comes back online.
<Application Name> INVALID APPLICATION FOR OFS PROCESSING:

This error message is encountered when the field ADDITIONAL.INFO of the PGM.FILE record for the
application is set to NOFS. This may, in most cases be a restriction set by the designer / developer of
the application intentionally, on purpose. Check with the designer / developer of the application if
possible to learn more about the application and why updates using OFS was restricted.
File / I/O related errors

These errors are encountered when there are problem(s) relating to a file or an I/O operation in the
TEMENOS T24 Server. An error may due to problems in opening or reading a file. The following is the
list of common File / I/O related error messages.
Could not open <file name>:

This error message is encountered when the file open operation has failed on the TEMENOS T24
Server. To overcome this, check the name of the application supplied in the request message. Also
see if the required file exists and is readable (check for permissions / data corruption). After these
investigations if the file is found wanting and creating the file is appropriate, create one.
MISSING STANDARD SELECTION RECORD FOR <Application Name>:

This error message is encountered when a record for the application supplied in the request message
does not exists in the STANDARD.SELECTION file. To overcome this, check the name of the
application supplied in the request message. Also see if a STANDARD.SELECTION record for the
supplied application exists and is readable (check for permissions / data corruption). After these
investigations if a record is found to be required and creating a record is appropriate, create one.


T24 Ofs

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

T24 Ofs

Hochgeladen von

Copyright:

Verfügbare Formate

This page is different from the print version of this document.

Open Financial Service

Version Date Description Consultant

Information in this document is subject to change without notice.

Copyright 2007 TEMENOS Headquarters SA. All rights reserved.

First published: 2005

Copyright © 2004 TEMENOS HOLDINGS NV

TEMENOS™, TEMENOS T24™, TEMENOS GLOBUS™, TEMENOS ™, ™ are registered trademarks

TEMENOS Training Publications Temenos Education Centre, Chennai

TEMENOS Training Publications Temenos Education Centre, Chennai

TEMENOS Training Publications Temenos Education Centre, Chennai

Scope of this document

Who should read this

 This document is not intended to be used as a sales manual.

TEMENOS Training Publications Temenos Education Centre, Chennai

– Numbered footnotes are provided wherever deemed necessary to aid understanding.

– Indication notes are marked in bold italics and prefixed with a

– Main informational notes are marked in italics and prefixed with a

– Syntax / commands and source codes are given in colored boxes.

Software and their versions

Additionally the following software may be used optionally.

TEMENOS Training Publications Temenos Education Centre, Chennai

 Request – Response based approach

 Provides various modes of operations – Batch, Online, Globus (inter-application

 Provides real-time and batch transaction and interrogation (Enquiry) capabilities to

 Provides options to customize message processing through user-defined subroutines

 Support for Multi-value and Sub-value data

 Support for multi-company processing

 Messages accepted only in OFS and GTS syntax

 Support for XML format messages

 Supports logging of messages and provides error message details

 Downward compatible with Globus Transaction Server (GTS)

 Available for all platforms for which TEMENOS T24 is available

 Provides options for offline store and forward of messages

 Optional audit trail for each message processed

 Validating transactions in TEMENOS T24 standard and local applications, without

TEMENOS Training Publications Temenos Education Centre, Chennai

TEMENOS Training Publications Temenos Education Centre, Chennai

Files Messages Offline queue

Connection Session Online Queue Globus Request Enquiry

Open Financial Service

Retail Private Treasury Corporate Core

TEMENOS T24 Applications / Versions, Enquires and Subroutines

TEMENOS T24 Server

TEMENOS T24 Database

TEMENOS Training Publications Temenos Education Centre, Chennai

3. OFS Message Types

TEMENOS Training Publications Temenos Education Centre, Chennai

Files Offline queue

Open Financial Service

Applications / Versions, Enquires and Subroutines

TEMENOS T24 Server

TEMENOS T24 Database

TEMENOS Training Publications Temenos Education Centre, Chennai

The EB.AUTO.PROCESS record is updated from OFS.SOURCE - when an OFS.SOURCE record is

Once the connection is established the OFS.ONLINE.MANAGER5 will be started automatically as a

The connections (phantom processes) are started automatically by OFS.START.ONLINE.COMMS. A

TEMENOS Training Publications Temenos Education Centre, Chennai

EB.AUTO.INIT.PROCESS (Login / .profile)

Communication initiation (OFS.START.ONLINE.COMMS)

Open Financial Service

Applications / Versions, Enquires and Subroutines

TEMENOS T24 Database

This document is not intended to be used as a sales manual.

Request – Response based approach

Provides various modes of operations – Batch, Online, Globus (inter-application

Provides real-time and batch transaction and interrogation (Enquiry) capabilities to

Provides options to customize message processing through user-defined subroutines

Support for Multi-value and Sub-value data

Support for multi-company processing

Messages accepted only in OFS and GTS syntax

Support for XML format messages

Supports logging of messages and provides error message details

Downward compatible with Globus Transaction Server (GTS)

Available for all platforms for which TEMENOS T24 is available

Provides options for offline store and forward of messages

Optional audit trail for each message processed

Validating transactions in TEMENOS T24 standard and local applications, without