Welcome to the learning unit on Advanced Version Routines in T24.

In this learning
unit you will learn about the use of advanced version routines, when they are invoked
and what common variables can be manipulated in them.

PRG11.Advanced VersionRoutines-R14 1
 The conventions used in this learning unit are,

1.Applications in T24 are represented in bold uppercase letters.

2.The fields in the applications are mentioned in uppercase letters.

3. This learning unit is example based. First an example output will be shown then you
will be taught the steps to create the Enquiry. At the end of each section a workshop is
given to test your level of understanding.

PRG11.Advanced VersionRoutines-R14 2
 At the end of this learning unit you will be able to

1. Explain what is a version routine

2. Explain the different types of version routines

PRG11.Advanced VersionRoutines-R14 3
 1,2 The VERSION application allows you to create customised screens in T24 for
various applications. These customised screens makes the work more simpler to the
user. Using versions values can be defaulted into fields. In addition to this you can also
add local subroutines to version

2. These subroutines perform tasks like field input, validation and authorisation. These
subroutines are attached to specific fields in the version and they are triggered at
various stages.

PRG11.Advanced VersionRoutines-R14 4
 There are various version routines available in T24. The different types are as follows:

1. Auto Field Routine

2. Validation Routine

3. Input Routine

4. Authorization Routine

5. Check Id Routine

6. Check Record Routine

7. After Unauth Routine

8. Before Auth Routine

PRG11.Advanced VersionRoutines-R14 5
 1. You will first learn about Auto Field Routine. 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 ‘Auto 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’.

PRG11.Advanced VersionRoutines-R14 6
 The stated task aims at teaching you the working principle of Auto Field Routine. The
requirement for the task is as follows:

1. Create a local reference field for the ACCOUNT application called TOT.USD.ACC

2. Create a version for the ACCOUNT application . Fields to be part of the version are

2.1All mandatory fields of the ACCOUNT application

2.2 Local reference field TOT.USD.ACC

3. The field TOT.USD.ACC will denote the total number of USD accounts created till
date

PRG11.Advanced VersionRoutines-R14 7
 Now you will analyse the algorithm for the given task ,

STEP 1: Create a local reference field to display the total number of USD accounts

STEP 2: Create the version for the ACCOUNT application. Attach the local reference
field to your version

STEP 3: Write the subroutine to calculate the total number of USD accounts and
populate the value in the local reference field

STEP 4: Compile the routine and catalog the subroutine

STEP 5: For the subroutine , make an entry in PGM.FILE

STEP 6 : Attach the subroutine to the field ‘Aut New Content’ in the VERSION
Application

Now you will code the subroutine.

PRG11.Advanced VersionRoutines-R14 8
 Write the code for the subroutine. In the subroutine, a routine called GET.LOC.REF is
invoked to get the field position of the local reference field. It is stored in the variable
called LOC.POS. Parameters to be passed to this routine are 1) Application name 2)
Local reference field name 3) the variable that will return the field position of the local
reference field.

Then you execute a select statement to find out the total number of USD accounts
using the EB.READLIST routine. The standard now is to use DAS instead of
EB.READLIST which will be taught during Template Programming . The result is
stored in the parameter NO.OF.REC.

Finally the value in NO.OF.REC is returned to the local ref field. Compile and catalog
the subroutine.

PRG11.Advanced VersionRoutines-R14 9
 1. Make an entry in the PGM.FILE application for the compiled subroutine. Id to this
application will be your subroutine name.
2. Use the routine in the VERSION to auto populate value for the local reference field,
TOT.USD.ACC

PRG11.Advanced VersionRoutines-R14 10
 1. The field position of your local reference field is returned as 1

2. The total number of account records that satisfy the given condition is displayed as
928

PRG11.Advanced VersionRoutines-R14 11
 Here you see the values of the record stored in an array R.NEW. R.NEW(20) holds the
value of your local reference field.

Note : R.NEW 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.

PRG11.Advanced VersionRoutines-R14 12
 Here you see a record opened using the version. The total number of USD accounts is
displayed in the local reference field.

PRG11.Advanced VersionRoutines-R14 13
PRG11.Advanced VersionRoutines-R14 14
 Next you will learn about ID Routines.

1. ID Routine as the name implies is used to manipulate the id of the record.

2. ID routine gets executed as soon as the id of the record is entered by the user.
Any special manipulation can be done on the id using this routine.

3. ID routine is attached to the field ID.RTN in the version

4. ID routines need to have an entry in EB.API application

PRG11.Advanced VersionRoutines-R14 15
 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

PRG11.Advanced VersionRoutines-R14 16
 Lets look into the algorithm now,

STEP 1: Create the version for the ENQUIRY application

STEP 2: Your subroutine should not modify the default enquiries in T24

STEP 3: Write a subroutine to prefix the id of the enquiry with ‘TEM.TRG’

STEP 4: Validate the length of the id. If the id length exceeds 30 characters then an
error message should be displayed

STEP 5: Compile and catalogue the subroutine

STEP 6: Make relevant entries in EB.API application

STEP 7: Attach it to the field ID.RTN of the version application

Now lets write the code.

PRG11.Advanced VersionRoutines-R14 17
 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.

PRG11.Advanced VersionRoutines-R14 18
 Attach the subroutine to the ID.RTN field in the version.

PRG11.Advanced VersionRoutines-R14 19
 When you debug the code you could see the values stored for the common variables
APPLICATION and COMI.

PRG11.Advanced VersionRoutines-R14 20
 Here is an enquiry created using the version. You could see the id prefixed with
TEM.TRG, and blocks ids with more than 30 characters.

PRG11.Advanced VersionRoutines-R14 21
PRG11.Advanced VersionRoutines-R14 22
 You will now be introduced to Check record routine in T24.

1. Check record routine is used to alter field attributes or to default values into fields

2. This routine is called after the ID is entered and validated

3. Check record routine gets invoked when the functions I(Input), D(Delete),
A(Authorise) and R(Reverse) are used.

4. This routine is attached to the field CHECK.REC.RTN of the version

5. Check record routines need to have an entry in EB.API

PRG11.Advanced VersionRoutines-R14 23
 The stated task teaches you about Check Record Routine in T24.

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

2. Using the version ,the user should be allowed to open only account records that
belong to CATEGORY 6001. Write a subroutine to perform the validation

PRG11.Advanced VersionRoutines-R14 24
 Lets now design the algorithm for the given requirement,

STEP 1: Write a subroutine to check the CATEGORY

STEP 2: Create an entry in EB.API for the subroutine

STEP 3: Create the version for the ACCOUNT application

STEP 4: Check the id of the version that is opened currently by the user

STEP 5: User should be allowed to open only those accounts that belong to
CATEGORY 6001

PRG11.Advanced VersionRoutines-R14 25
 Remember the user should be allowed to open only those account records that
belongs to CATEGORY 6001.The given subroutine validates the value of the
CATEGORY field as required.

PRG11.Advanced VersionRoutines-R14 26
 CHECK.REC.RTN – Now to attach the routine to your version record use the field
CHECK.REC.RTN.

PRG11.Advanced VersionRoutines-R14 27
 1. Account 1575 belongs to CATEGORY 6001. Lets try to open the account record
using the version

2. The same account record is displayed using the version ACCOUNT,NEW

3. Now lets try to open an account record that does not belong to CATEGORY 6001
using the same version. The account record displayed here belongs to
CATEGORY 6000.

4. When you try to open the account record using the version, an error message gets
displayed

PRG11.Advanced VersionRoutines-R14 28
PRG11.Advanced VersionRoutines-R14 29
 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

PRG11.Advanced VersionRoutines-R14 30
 You will now learn about Before Auth Routine in T24.

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 authorisation 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 authorisation 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

PRG11.Advanced VersionRoutines-R14 31
 This task teaches you the Before Auth Routine in T24. The requirement is as follows:

1. Create a version for the ACCOUNT application

2. Create a local reference field to display the total number of accounts for a particular
customer. Attach the local reference field to the version

3. Whenever the user authorises a new account for a particular customer, the total
number of accounts should be populated in the local reference field

Note: The user should only be allowed to authorise newly created account records and
not the amended ones.

PRG11.Advanced VersionRoutines-R14 32
 In the subroutine perform a check that validates the application and the type of the
version that is used.

PRG11.Advanced VersionRoutines-R14 33
 Obtain the customer id and populate the value in the variable Y.CUSTOMER.ID. Using
the customer id find out the total number of accounts that he holds. The total number
of accounts is populated in the local reference field TOT.ACC.

Note: The above stated tasks should only be performed when a new account record is
authorized. Therefore you should also check the CURR.NO of the record

PRG11.Advanced VersionRoutines-R14 34
 The created local reference field should be part of your version.

BEFORE.AUTH.RTN – Attach the compiled routine to the field BEFORE.AUTH.RTN

of the version

Note: - In Field No.5 we gave the value LOCAL.REF-1 assuming that this application
is having only one Local reference field, in case if more than one Local Reference is
available then according to the position the LOCAL.REF value has to be changed like
LOCAL.REF-2,LOCAL.REF-3 etc.

PRG11.Advanced VersionRoutines-R14 35
 Using the version ACCOUNT,OPEN authorize an account record.

Note: The customer number is 111569 and the CURR.NO is 1

PRG11.Advanced VersionRoutines-R14 36
 1. When you debug the code you could very well see the value stored in the variable
Y.CUSTOMER.ID. The customer number 100357 is stored in the variable
Y.CUSTOMER.ID.

2. Also a value two gets populated in the local reference field TOT.ACC as shown in
the screen shot. The customer 100357 has only two accounts and this is verified
using the application CUSTOMER.ACCOUNT

PRG11.Advanced VersionRoutines-R14 37
 The variable R.NEW holds the entire record in the form of a dynamic array.

PRG11.Advanced VersionRoutines-R14 38
 The authorised account record is displayed here. The local reference field TOT.ACC
holds the value as two. The value in CURR.NO field is 1

PRG11.Advanced VersionRoutines-R14 39
 Now lets try to authorise an amended account record. The CURR.NO for the account
record is 5. Hence when you use the version to authorise the account record an
ACCESS DENIED error message gets displayed to the user.

PRG11.Advanced VersionRoutines-R14 40
PRG11.Advanced VersionRoutines-R14 41
 It is possible to update records in any other local application from versions. This can
be done at different stages (input, before auth, before unauth) in the version routines.
The OFS message needs to be formed in the version routine and passed to the core
API - OFS.POST.MESSAGE. This API will update the request in
OFS.MESSAGE.QUEUE. The service OFS.MESSAGE.SERVICE needs to be started.
This service will pick the records from OFS.MESSAGE.QUEUE, process the message
and puts the response in OFS.RESPONSE.QUEUE. The source type of the
OFS.SOURCE record should be GLOBUS.

The common variable OFS$SOURCE.REC holds the record of current OFS.SOURCE

record. It is also possible to find out whether any request is coming thru browser or not
by making use of the variable OFS$BROWSER. The next task to be performed is
stored in the common variable OFS$NEXT.COMMAND.

PRG11.Advanced VersionRoutines-R14 42
 1. True

2. True

3. True

4. False

5. False

PRG11.Advanced VersionRoutines-R14 43
 1. Auto Field Routines are used to manipulate the content of a field before display

2. ID routines are used to manipulate the id of the record.ID routine gets executed as
soon as the id of the record is entered

3. Check record routine is used to alter field attributes or to default values into fields.
It is invoked after the id is entered and validated

4. After Unauth Routine is used to edit a record written to the $NAU file. This routine
is invoked once you commit the record

5. Before Auth Routine is invoked during the authorisation stage of an INAU record

PRG11.Advanced VersionRoutines-R14 44
 In this session you have learnt about advanced version routines in T24.You will be
able to

1.Explain what is a version routine

2.Explain the different types of version routines

3.Create Autom Field Routine

4.Analyse the working concept of ID Routine

5.Analyse the working concept of After Auth Routine and Before Auth Routine

PRG11.Advanced VersionRoutines-R14 45
PRG11.Advanced VersionRoutines-R14 46