1. Welcome to the “Version Routines” learning unit.

This learning unit will enable you

to understand the different version routines in T24.

Basic Version Routines-R14 1

Basic Version Routines-R14 2
A version is a variation of the original application. For eg, a FUNDS.TRANSFER I F3,
will display over 100 fields for input. A user may or in many cases may not require all
these 100+ fields at the time of transaction input. Thus it would be helpful to create a
customised screen according to the users requirement. This can be achieved using
VERSION application. When you design a version, you cannot remove the mandatory
fields. Thus you can create a version with only the mandatory fields in
FUNDS.TRANSFER application or as many as desired apart from the mandatory
fields.

Can you view data using versions?

Versions behave like the application itself, but only looks different. Thus all functions
can be used with a version. Versions work with all functions of T24

Basic Version Routines-R14 3

Basic Version Routines-R14 4
All applications in T24 are designed with extensibility as a feature. T24 allows creation
of versions and versions are provided with exit points - points where a user defined
routine can be attached/invoked. The application exits from the usual flow, does what
the custom routine says, and then depending on the flow comes back to its original
flow again. Sometimes called as trigger points.
Code can be written in a version to achieve
Validations based on the record ID – Further checks can be performed on
the record ID and the request processed or denied. The current ID cannot be
modified. Common variables available – ID.NEW, ID.OLD, ID.NEW.LAST.
Three routines are available to do this each with a different purpose – ID
Routine, Check record routine and Auto field routine
Field Validations - Additional field validations can be performed using
validation routines. Existing validations cannot be changed.
Record Validations - Additional record level validations can be performed
and overrides can be generated. These validations are written in Input
routines
Processing after commit of a record - Information can be written onto other
files using After Unauth routines
Checks during authorization
Additional checks can be performed before authorization using Before
auth routines.
New files can be written using authorisation routines.

Basic Version Routines-R14 5

The stages during which the routines are invoked in the Page Life Cycle is shown in
the slide. For eg Before Auth Routine is invoked before .AUTHORISE and
authorisation routine after .AUTHORISE

Basic Version Routines-R14 6

Let us discuss each of these routines in detail

Basic Version Routines-R14 7

The stated task teaches you about ID Routines in the VERSION application. The
requirement for the task is as follows :

1. Create a version for the ENQUIRY application with all the mandatory fields

2. Manipulate the id of the enquiries created using the version

3. The ID should be prefixed with text ‘TEM.TRG’ to denote that the enquiry was
created or opened using the above specified version

4. The Ids of enquiries that begin with a ‘%’ or a Enquiry-LIST should not be
modified

5. The ID length should not exceed 30 characters. If it does, then an error

“Temenos Trg restricts ID length to 30 Characters” should be displayed to the
user

Basic Version Routines-R14 8

Basic Version Routines-R14 9
Basic Version Routines-R14 10
APPLICATION – APPLICATION is a T24 common variable defined in I_COMMON
that holds the current application that has been opened by the user.

COMI – COMI is a common variable in T24 that holds last input data. Every time when
you tab out of a field, the data that you input in the field is available in the common
variable.

Compile and catalog the subroutine.

You can notice in the output of the version ENQUIRY,OPEN that the ID is prefixed
with TEM.TRG. You can use the same version

Basic Version Routines-R14 11

Basic Version Routines-R14 12
Create a version for the ACCOUNT application with the fields required

Create a subroutine that validates the value of the CATEGORY field as required.

Attach the routine to your version record use the field CHECK.REC.RTN.

Make an entry in EB.API.

Basic Version Routines-R14 13

The difference between the Check record routine and Auto field routine is clear from
the example scenarios. Auto Field routine is used to manipulate Field data at the time
of display of the record to the user.

Basic Version Routines-R14 14

1. Auto Field Routines are used to manipulate the content of a field before displaying
it to the user

2. Auto Field Routines are used for editing a record before displaying to it the user

3. These routines are executed after the id of the record is supplied by the user and
the corresponding record is fetched from the file, but before the record can be
displayed

4. These routines are to be attached to the field ‘Aut New Content’ in the Version
Application. The name of the routine should be prefixed with an @ symbol when
attaching it to the field. These subroutines should have an entry in PGM.FILE with
PGM.TYPE = 'S' and a corresponding entry in EB.API. These subroutines get
executed for the associated field specified in ‘Autom Field No’.

Basic Version Routines-R14 15

Populate the currency of the account in the field DEBIT.CURRENCY once you tab out
of the field after entering the value in the field DEBIT.ACCT.NO.

Basic Version Routines-R14 16

Field Level validation in unauthorized stage done by Validation routine and Input
routine .

Basic Version Routines-R14 17

Basic Version Routines-R14 18
Basic Version Routines-R14 19
You will now learn about After Unauth Routine in T24.

1. After Unauth Routine is used to edit a record written to the $NAU file

2. After Unauth Routine is invoked once you commit the record.

3. Therefore any changes made to R.NEW will not be reflected as it has already been
written to the $NAU file. If any change needs to be made to the record in the $NAU file
at this stage, then a separate write needs to be executed. Do not call
JOURNAL.UPDATE as this is taken care by core T24.

4,5 After Unauth Routine is attached to the field AFTER.UNAU.RTN in the version
prefixed with an @ symbol. After Unauth Routine need to have an entry in EB.API
application

Basic Version Routines-R14 20

Basic Version Routines-R14 21
Basic Version Routines-R14 22
1. Before Auth Routine allows you to do some processing before writing the record to
the live file

2. Before Auth Routine is invoked during the authorization stage of an INAU record

3. Before Auth Routine is invoked before the version’s Auth routine. The order of
execution is BEFORE.AUTH routine, AUTHORISATION routine, then record is written
to the live file.

4, 5 Auth Routine and Before Auth Routine are invoked before the authorization stage.
The difference between Auth Routine and Before Auth Routine is that Before Auth is
invoked before a F.WRITE is made to the live file. This means that, even at this stage
the value of any field can be modified. However, AUTH.RTN gets invoked after
F.WRITE is made to the file. This means that changes made to R.NEW will not reflect
in the record unless an F.WRITE is made explicitly in the case of Auth routine.

6. These routines need to have an entry in EB.API

7. Before Auth Routines are attached to the field BEFORE.AUTH.RTN of the Version
prefixed with an @ symbol

Basic Version Routines-R14 23

Once a record in a version of the FUNDS.TRANSFER application is authorized, the
following details from the transaction need to be extracted and written on to a flat file
named TEMENOS.TRAINING for interface purposes all delimited with a single space

DEBIT.ACCT.NO

CREDIT.ACCT.NO

DEBIT.VALUE.DATE

DEBIT.AMOUNT

DEBIT.CURRENCY

ID of the record in the flat file should be the ID of the FT record

Basic Version Routines-R14 24

• Authorization routine gets executed at the authorization stage of a transaction.
This routine gets invoked just prior to the final update of files.

• Routine called at this stage can be used to update local files

• Before this routine is invoked, all standard default and validation processing would
have taken place.

• Authorization routine is attached in the VERSION application in the field

AUTH.ROUTINE. The name of the routine should be an existing program that is
executable.

• This routine is invoked after a write is made to the buffer. Any changes made to
R.NEW will not reflect in the record unless a WRITE is made explicitly.

• In this case, a call to F.WRITE should be made first even before

JOURNAL.UPDATE is called as this is taken care of by T24 core.

Basic Version Routines-R14 25

VERSION.CONTROLis a T24 application that provides flexibility when creating screen
versions.
This application allows users to group VERSION records and to control field attributes
based on defined conditions.
The user is able to use these features in conjunction with the VERSION application.
VERSION.CONTROL is an addition to the VERSION application. It does not replace
the VERSION application.
One VERSION.CONTROL record can be linked to multiple VERSION records via the
VERSION.TYPE field on VERSION.
If the record id in VERSION.CONTROL is the application name itself, then the routines
specified here are applied to the application

Basic Version Routines-R14 26

Basic Version Routines-R14 27
Basic Version Routines-R14 28