VERSION ROUTINES

DateOf Issue Version Changes By

2001 1.0 Initial Alagammai
Palaniappan
2002 1.1 jBASE Alagammai
Changes Palaniappan
2002 1.2 Infobasic Alagammai
Program Palaniappan
ming
changes
July 2004 1.3 G14 Alagammai
changes Palaniappan

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.
Version Routines

Table of Content
Table of Content ................................................................................................................................... 2
Introduction........................................................................................................................................... 3
Version routines.................................................................................................................................... 3
Validation Routine ............................................................................................................................. 3
Input Routine..................................................................................................................................... 3
Authorization Routine ........................................................................................................................ 3

Temenos Training Publications Page 2 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Introduction
VERSION is a standard T24 application, which allows users to create customized screens for input,
authorization, display etc. It may also be used to automate the replacement of data on records. In fact
T24 comes with many useful VERSION records for the majority of T24 applications. It is also possible
to add local sub-routines, which can be used for field, input and authorization validation. These small
programs will allow even greater customization of T24 by the user.

Version routines
There are three different types of routines that can be attached to a version. Each one of them is
attached at different levels and has a specific functionality. The three different types of version
routines available are:

Validation Routine
Input Routine
Authorization Routine

Validation Routine
These routines, as the name implies validate data entered in a particular field (it can also be used to
default values into a particular field) and is specified in the field VALIDATION.FLD in the Version
Application. These routines get invoked after a user presses the ‘TAB’ key (Return key can also be
used in case of Desktop or classical mode) in the field to which the routine has been attached. These
routines get invoked when record is committed as well.
Make entries for these routines in the PGM.FILE with the type set to ‘S’ and attach them to the field
VALIDATION.RTN in the Version. The name of the field to which this routine needs to be attached to
should be specified in the field VALIDATION.FLD.
For field level validations to work in browser the respective field should be set as HOT.FIELD in the
version.

Example 1
Create a version for the Funds Transfer application with the following fields. As soon as the Debit
Account Number is entered the appropriate currency has to get defaulted in the Currency field. Make
the Currency field a NOINPUT field.

Fields that need to be part of the version

Transaction Type
Debit Account Number
Debit Currency
Debit Amount
Debit Value Date
Credit Account Number
Credit Currency

Temenos Training Publications Page 3 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Solution 1
Step 1
Create a version for the Funds Transfer application with the above mentioned fields. Ensure that you
make the DEBIT.CURRENCY field a ‘NOINPUT’ field.

Step 2
The requirement is to populate the Debit Currency with the currency of the account that has been
entered in the Debit Account Number field. The above requirement requires a subroutine that needs to
be attached to the field Debit Account Number in the version.

Note : All validation routines will get invoked when the record is committed as well. If the user
does not want these routines to be invoked at the committing stage, then the common
variable MESSAGE, defined in I_COMMON needs to be made use of. This is a dynamic array
that holds the current function.

Example : When the record is committed this variable would hold ‘VAL’. When a record is put
on hold, this variable would hold ‘HLD’. When a record is authorized this variable would hold
‘AUT’ etc.

Algorithm
Extract the account number entered in the field Debit Account Number
Using the account number, read the Account file
Extract the relevant Account record
From the extracted record, extract the currency of the account and display it in the field Debit Currency
in the Version.

COMI
Is a dynamic array defined in I_COMMON that contains the last entered value in any
application/version.

ID.NEW
Dynamic array that contains the id of the currently opened record. Defined in I_COMMON file.

R.NEW
It is a dimensioned array that has been defined in the file I_COMMON. It holds the copy of the
currently opened record in any application in T24. Always use ‘( )’ brackets while referring to variables
inside a dimensioned array as opposed to ‘<>” which we use for dynamic arrays. This dimensioned
array has been dimensioned to contain 500 dynamic arrays. The definition for R.NEW in the
I_COMMON file is as follows.

R.NEW(C$SYSDIM) where C$SYSDIM = 500

Temenos Training Publications Page 4 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

R.OLD
It is a dimensioned array that has been defined in the I_COMMON file. It holds a copy of an
authorized record when it is opened for amendment. The definition for R.OLD in the I_COMMON file is
as follows.

R.OLD(C$SYSDIM)

ID.OLD
Is a dynamic array that holds the id of the record held in R.OLD

R.NEW.LAST
R.NEW.LAST is a dimensioned array that will hold a copy of an unauthorized record when it is opened
for amendment. The definition for R.NEW.LAST in the I_COMMON file is as follows.

R.NEW.LAST(C$SYSDIM)

ID.NEW.LAST
Is a dynamic array that holds the id of the record held in R.NEW.LAST

Temenos Training Publications Page 5 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

HOT.FIELD
While Desktop was used as the front end for T24, all field validations would get triggered on pressing
tab or return on a particular field. With the advent of Browser as the front end, there exists a stateless
connection between the client (Browser) and T24. Hence, it would be very expensive on the system to
perform field validations for all fields. Hence, a concept called ‘hot fields’ was introduced.

When Browser is used as the front end, field level validations will take place only if the field is set as a
hot field. Defining a field as a Hot Field, automatically sends a validation request to the server on
change of data. Hot fields are shown with a next to them.

Care should be taken when defining fields as hot fields. Only fields for which field level validation is
absolutely mandatory should be defined as hot fields. T24 anyway validates all fields when the record
is committed.

To specify a field as a hot field, the version to which it belongs must be amended. The field “ATTRIBS”
should be set to “HOT.FIELD” to signify that validation should be run when this field is exited.

Temenos Training Publications Page 6 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

*Version subroutine that will populate the debit currency based on the
*Debit Account Number.
SUBROUTINE V.TRG.VAL.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.ACCOUNT
$INSERT I_F.FUNDS.TRANSFER

IF MESSAGE NE ‘VAL’ THEN

Y.ACCT.NO = COMI
Y.ACCT.CUR = ‘’
FN.ACCOUNT = ‘F.ACCOUNT’
F.ACCOUNT = ‘’
CALL OPF(FN.ACCOUNT,F.ACCOUNT)
CALL F.READ(FN.ACCOUNT,Y.ACCT.NO,R.ACCT.REC,F.ACCOUNT,ERR1)
Y.ACCT.CURR = R.ACCT.REC<AC.CURRENCY>
R.NEW(FT.DEBIT.CURRENCY) = Y.ACCT.CUR
CALL REBUILD.SCREEN
END
RETURN
END

Note : In the above example, the variable MESSAGE is checked to see if it contains the value ‘VAL’. If
it does, then it denotes that the record is being committed. This routine will hold no meaning when
invoked at the committing stage as we are extracting the value of DEBIT ACCOUNT NUMBER from
COMI. COMI will be NULL when committing a record and thus the check on the variable MESSAGE is
incorporated.

Temenos Training Publications Page 7 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Step 3
Compile and catalogue the subroutine. Make an entry in the PGM.FILE with the type as ‘S’ and attach
it to the Validation.Rtn(prefixed with an ‘@’ symbol) in the version. Set the attributes field for Debit
account Number as Hot Field. Ensure that you specify ‘DEBIT.ACCT.NO’ in the field Validation.Fld.

Output:

Debit currency is
automatically defaulted
on pressing tab in the
field Debit.Acct.no

The symbol denotes that the field Debit Acct No is a hot field.

Input Routine
These routines as the name implies get invoked just prior to committing a transaction in the
unauthorized stage. Multiple routines can be attached at this stage. Routines called at this stage may
be used to provide additional checking or override processing. At this point of the transaction all
standard default and validation processing would have taken place.
Input routines get invoked even when the record is put on hold. Therefore, if these routines need not
be invoked when the record is put on HOLD, then use the variable MESSAGE(already discussed) and
check if the record is being committed or being put on hold and then proceed with the necessary
processing. Attach them to the field INPUT.RTN in the Version

Example 3
Create a version for the FT application in which when the user presses F5 to commit the record, a
check has to be made to see whether the Debit Account Currency and the Credit Account Currency
are the same. If not an error message “Debit and Credit Account currency mismatch”, has to be
displayed.

Temenos Training Publications Page 8 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Solution 3

Step 1
Create a version for the FT application by name FT,INPUT with all the mandatory fields.

Step 2
Create a subroutine that will extract the Debit Account Currency and the Credit Account Currency from
the version, check if they are the same, if not flash an error message.

Algorithm
Extract the value of the Debit Currency and the Credit Currency from R.NEW, as R.NEW is the
dimensioned array that contains a copy of the currently opened record.Check if the extracted values
matches, else flash the above mentioned error message.

STORE.END.ERROR
This is a T24 subroutine that is capable of displaying an error message stored in a common variable
ETEXT. Therefore, the variable ETEXT always needs to be populated with the error message before
this subroutine is called. ETEXT has also been defined in the file I_COMMON.

ETEXT = “Error Message”

CALL STORE.END.ERROR

In the above example, the message ‘Error Message’ would be displayed by the routine
STORE.END.ERROR.

AF, AV and AS
These are dynamic arrays defined in I_COMMON that can hold the physical field number, multi value
and sub value position (of fields) respectively. Setting these variables before calling
STORE.END.ERROR would result in the display of these error messages adjacent to the field which
caused the error.

Example
AF = 1
AV = 1
AS = 1

ETEXT = “Error”
CALL STORE.END.ERROR

Temenos Training Publications Page 9 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Will cause the error message to be displayed adjacent to the field ‘1.1.1’.
When referring to single value fields, it would suffice if you set just AF to the physical field number.
When referring to multi value fields, it would suffice if you set AF and AV to the physical field number
and multi value position.

*Version input routine that checks if the debit and the credit currency are
*equal. Else flashes an error message
SUBROUTINE V.TRG.INP.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.FUNDS.TRANSFER
IF MESSAGE NE ‘HLD’ THEN
Y.DEBIT.CUR = R.NEW(FT.DEBIT.CURRENCY)
Y.CREDIT.CUR = R.NEW(FT.CREDIT.CURRENCY)
IF Y.DEBIT.CUR NE Y.CREDIT.CUR THEN
*Setting the position of AF to 5 so that the error
*message would be displayed adjacent to field number
*5(DEBIT.CURRENCY)
AF = FT.DEBIT.CURRENCY ; * Note that the field name has been
* used instead of field number
ETEXT = “Credit Acct Ccy Debit Not Eq Credit Ccy”
CALL STORE.END.ERROR
END
END
RETURN
END

Step 3
Compile and catalogue the subroutine and attach the subroutine to the field ‘INPUT.ROUTINE’ in the
version.

Authorization Routine
This is a routine that gets executed at the authorization stage of a transaction. Multiple routines may
be defined. Routines called at this stage may be used to update local files. At this point of the
transaction all standard default and validation processing will have taken place. This routine is invoked
after a write is made to the buffer meaning that changes made to R.NEW will not reflect in the record
unless an WRITE is made explicitly. In this case, a call to F.WRITE should not be succeeded by a call
to JOURNAL.UPDATE as this would be taken care of by T24 core. Attach them to the field AUTH.RTN
in the Version

Temenos Training Publications Page 10 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Example 4

As a part of core T24, whenever a customer record is authorized, a record is created in the
DE.ADDRESS file. This file is used by the Delivery module in T24 and stores the address of the
customer as in the customer file. This address is used when advices need to be sent to the customer.

Sample DE.ADDRESS id : US0010001.C-100001.PRINT.1

Where
US0010001 : Company code of the company that the customer belongs to
C-100001 : ‘C’ denotes Customer and followed by the customer id
PRINT.1 : Denotes the print carrier. Denotes that the address stored in this record should be used
when the advice is printed and mailed to the customer.

If a customer wishes to receive his advices in 2 different locations(some advices need to be sent to his
residence and some to his office address), then we would normally create an additional record in the
DE.ADDRESS file with the following id

US0010001.C-100001.PRINT.2

The PRINT.2 denotes that this is the second PRINT address of the customer.

The above mentioned process of creating an additional address record for customer needs to be
automated.

Add a new local reference field called ADDRESS.2 to the Customer application. When a new
customer record is authorised, a record should be created in DE.ADDRESS with the id
COMPANY CODE.C-CUSTOMER NO.PRINT.2. The values in the fields short name, name.1, name.2
and ADDRESS.2 (local reference field) should be written to the DE.ADDRESS record with the above
mentioned id.

Solution 4
Step 1
Create the necessary subroutine.

Algorithm
Check if the customer record being authorized is a new customer record
Form a record for the DE.ADDRESS file with the short name, name.1, name.2 (all the above
mentioned 3 fields should be extracted from the customer record being authorized.), street and town
country (get the value from the local reference field ADDRESS.2)

Temenos Training Publications Page 11 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Form the id of the DE.ADDRESS file and write the record formed into the DE.ADDRESS file.

ID.COMPANY
This is a dynamic array that is defined in the I_COMMON file which holds the id of the current
company.

*Version authorization routine that will enable the user to

*add a new record in DE.ADDRESS while authorizing a new customer
*record.

0001 SUBROUTINE V.TRG.AUTH.RTN

0002 $INSERT I_COMMON
0003 $INSERT I_EQUATE
0004 $INSERT I_F.CUSTOMER
0005 $INSERT I_F.DE.ADDRESS
0006 *
0007 GOSUB INIT
0008 GOSUB OPENFILES
0009 GOSUB PROCESS
0010 RETURN
0011 *
0012 INIT:
0013 FN.CUS = 'F.CUSTOMER'
0014 F.CUS = ''
0015 Y.ADDRESS = ''
0016 RETURN
0017 *
0018 OPENFILES:
0019 CALL OPF(FN.CUS,F.CUS)
0020 RETURN
0021
0022 PROCESS:
0023 IF R.OLD(1) = '' THEN ;* If it is a new record being
authorised
0024
0025 * Form the id of the DE.ADDRESS record
0026
0027 Y.DE.ADDRESS.ID = ID.COMPANY:'.C-':ID.NEW:'.PRINT.2'
0028
Temenos Training Publications Page 12 of 14 March 2004
T3ATT – R05 – 1.0
Version Routines

0029 Y.ADDRESS = R.NEW(EB.CUS.LOCAL.REF)<1,7>

0030
0031
Y.OFS.REC=“DE.ADDRESS/I/PROCESS,TRAIN03/654321,”:Y.DE.ADDRESS.ID:”,”:BRANCH
NAME=R.NEW(EB.CUS.SHORT.NAME):”,”:DE.ADD.NAME.1=R.NEW(EB.CUS.NAME.1):”,”:DE
.ADD.NAME.2=R.NEW(EB.CUS.NAME.2):”,”:DE.ADD.STREET.ADDRESS= Y.ADDRESS"
0032 OFS.MSG.ID=""
0033 OFS.SOURCE.ID="GCS"
0034 OPTIONS=""
0035 CALL OFS.POST.MESSAGE(Y.OFS.REC,OFS.MSG.ID,OFS.SOURCE.ID,OPTIONS)
0036 END
0037
0038 RETURN
0039 END

When the above piece of code is attached to a version, the supplied OFS message will get written on
to a file named F.OFS.MESSAGE.QUEUE. This is the IN queue from where the service
OFS.MESSAGE.SERVICE picks up the data and processes.
Once the message is processed, the response is written on to an out queue named
F.OFS.RESPONSE.QUEUE.

The service OFS.MESSAGE.SERVICE is a multi threaded service and needs to be started like any
other service. It also requires the tSM to be up and running.

Sample IDs:

Message ID returned by OFS.POST.MESSAGE : 138770008052455.00

F.OFS.MESSAGE.QUEUE (In Queue): 138770008052455.00-TRG

(Where TRG is the OFS.SOURCE ID)

F.OFS.RESPONSE.QUEUE (Out Queue): 138770008052455.00.1

A service named OFS.RESPONSE.QUEUE is now available in T24. This service is used to purge all
messages in F.OFS.RESPONSE.QUEUE provided they have been in the queue longer than the
number of seconds specified in the field ATTRIBUTE.VALUE in the TSA.SERVICE record for
OFS.RESPONSE.QUEUE.

Step 2
Create a version of the Customer application with all the mandatory fields, compile and catalogue the
subroutine and attach it to the version.

Step 3
Input a customer record. Sign off and sign in as another user and authorize the record using the
version to which you have attached the routine.

Temenos Training Publications Page 13 of 14 March 2004

T3ATT – R05 – 1.0
Version Routines

Temenos Training Publications Page 14 of 14 March 2004

T3ATT – R05 – 1.0