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

This learning unit will enable

PRG5.BasicVersionRoutines – R14 1
 After completing this learning unit, you will be able to:

•Explain the need for version routines

PRG5.BasicVersionRoutines – R14 2
 1. The VERSION utility is used to customize an application in T24. Not only do
Versions allow you to create customized screens, hide fields that are not required,
default values in the fields, make normal fields as no input fields, make non
mandatory fields mandatory etc, they also allow you to attach local routines that
can enhance the way an application works based on client requirements.

2. Routines that are attached to the VERSION application in T24 are called Version
Routines. There are many types of version routines. This learning unit will teach
you three basic types of version routines.

An example will give you a clear picture of what a version routine is. In the actual
FUNDS.TRANSFER application, DEBIT.CURRENCY is a mandatory field and has
to be input by the user. But what if you want this field to be defaulted once you
enter a value in the field DEBIT.ACCT.NO and tab out? How can you achieve
this? By writing local code. Where will you attach this code? Can you attach it to
the FT application? No, so this is where Version routines comes into picture. You
can write a routine to pick up the currency of the account given in
DEBIT.ACCT.NO field from the ACCOUNT application and write it into the filed
DEBIT.CURRENCY. You have to attach this routine in the version record of the
FT application.

PRG5.BasicVersionRoutines – R14
R12 3
 Now that you have an idea of what a version routine is, from where do you think the
values will be picked up and processed in the routines? Can the routine directly
access the value input in the fields in the record?
No.
Version routines act on the values that are held in the common variables. The values
input in the fields of a record will be stored in different common variables. Most of the
common variables used in T24 are defined in a file named I_COMMON under T24.BP
Version routines use different common variables which are initialized at different points
in time. All the subroutines in T24 must have insert statement to include I_COMMON
and I_EQUATE.

PRG5.BasicVersionRoutines – R14
R12 4
 The ID of the record that is currently open is held by a common variable ID.NEW
which is a Dynamic array. A dynamic array is a data structure that can be resized and
allows elements to be added or removed. All variables in JBASE Basic are by default
dynamic arrays unless defined as dimensioned.

When the record is closed or committed or authorized the value in this variable gets
flushed.

PRG5.BasicVersionRoutines – R14 5
 The variable R.NEW holds the record of an application that is currently in use. Once
the record is committed, the value in this variable gets cleared. ID.NEW holds the ID of
the currently opened record, while R.NEW holds the actual record. ‘R’ in the variable
name stands for ‘Record’.

It is defined in I_COMMON as DIM R.NEW(C$SYSDIM) since it is a dimensioned

No application in T24 has more than 500 fields, so the size of R.NEW is restricted to
500. The day it exceeds 500, the value in C$SYSDIM should be increased
accordingly.

Each position in a dimensioned array in T24 in turn is a dynamic array.

PRG5.BasicVersionRoutines – R14 6
 For example when a user creates a new CUSTOMER record, the variables ID.NEW
and R.NEW will hold the ID and the actual record respectively. Once the record is
committed, data is flushed from the variables ID.NEW and R.NEW.

PRG5.BasicVersionRoutines – R14 7
 1. If an unauthorized record exists for the currently opened record in any
application, this variable will hold the ID of the unauthorized record.
2. This variable is a Dynamic array
3. The ID of the live and unauthorized record will be the same. This variable
enables us to know, programmatically whether or not an unauthorized record
exists for the currently opened record.

PRG5.BasicVersionRoutines – R14 8
 1. R.NEW.LAST variable holds the actual unauthorized record if any for the
currently opened record ID in any application. It holds the last saved
unauthorized record. ID.NEW.LAST holds the ID of the unauthorized record for
the currently opened record if it exists, while R.NEW.LAST holds the actual
unauthorized record.
2. This is a Dimensioned array which comprises of 500 dynamic arrays
3. This variable is defined in I_COMMON as DIM R.NEW.LAST(C$SYSDIM)

PRG5.BasicVersionRoutines – R14 9
 If the user opens the CUSTOMER record 111178 in authorization mode, R.NEW will
hold the actual record opened and R.NEW.LAST will hold the unauthorized record
pertaining to the currently opened record. In this particular example, both these
variables will hold the copy of the same record. When the record is authorized, data is
flushed from the variables ID.NEW , R.NEW, ID.NEW.LAST and R.NEW.LAST.
Values from R.NEW only are written into the database when record is authorized.

PRG5.BasicVersionRoutines – R14 10
 1. This variable holds the ID of the authorized record if exists for the currently opened
record in any application. This variable is a Dynamic array
2. ID.OLD enables you to check programmatically whether or not the currently
opened record has an already authorized record.

PRG5.BasicVersionRoutines – R14 11
 1. The variable R.OLD holds the actual authorized record if any for the currently
opened record ID in any application. ID.OLD holds the ID of the authorized
record for the currently opened record if it exists, while R.OLD holds the actual
authorized record.
2. This is a Dimensioned array which comprises of 500 dynamic arrays
3. This variable is defined in I_COMMON as DIM R.OLD(C$SYSDIM)

PRG5.BasicVersionRoutines – R14 12
 When the user amends the authorized CUSTOMER record 111178, by changing the
SECTOR field, R.OLD will have the old authorized record where as R.NEW will hold
the amended customer record. Any changes are only reflected in R.NEW. When the
record is committed, data is flushed from the variables ID.NEW , R.NEW, ID.OLD and
R.OLD.

PRG5.BasicVersionRoutines – R14
R12 13
 If the user open existing INAU record 11178 which has a previously authorized record,
in authorization mode, then R.NEW will hold the currently opened record,
R.NEW.LAST will hold the last saved unauthorized copy of the record and R.OLD will
hold the last authorized copy. Once the record is authorized, data is flushed from all
the variables. Values from R.NEW only are written into the database when record is
authorized. The old authorized record R.OLD with SECTOR 1000 is moved to history
file with the ID as 111178;1.

PRG5.BasicVersionRoutines – R14
R12 14
 • Validation routines as the name implies are used to validate data entered in a
record in any application. All the variables that you have just learnt can be used to
write a validation routine.
• These routines can also be used to default values into fields on committing the
record.
• For the validation routine to get executed, the name of the routine must be
specified in the field VALIDATION.FLD in the particular version record for an
application.
• Validation routine is triggered on clicking the validate button in a record.
• This routine also gets invoked after a user presses the ‘Tab’ or the ‘Enter’ key from
a field which is set as a hot field.
What do you mean by a hot field? How can you set a field in an application as a hot
field?

PRG5.BasicVersionRoutines – R14
R12 15
 In this task you will learn to create a version, write a validation routine and attach it to
the version.
1. Create a version for the FUNDS.TRANSFER application with the following fields
TRANSACTION.TYPE
DEBIT.ACCT.NO
DEBIT.CURRENCY
DEBIT.AMOUNT
DEBIT.VALUE.DATE
CREDIT.ACCT.NO
CREDIT.CURRENCY
2. Set the field DEBIT.CURRENCY as NOINPUT field. This field should get auto
populated based on the value entered in DEBIT.ACCT.NO

PRG5.BasicVersionRoutines – R14 16
 The first step is to create a version record for the FT application with the necessary
fields and set the field DEBIT.CURRENCY as NOINPUT field.

PRG5.BasicVersionRoutines – R14
R12 17
 The next step is to write a subroutine to 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.
Extract the account number entered from the field DEBIT.ACCT.NO. Using the
account number entered, read the ACCOUNT file and extract the relevant record.
From the record, extract the currency of the account and display it in the field
DEBIT.CURRENCY.
Compile and catalog the subroutine using EB.COMPILE
Make an entry in EB.API application for the version routine.
Note – Call to REBUILD.SCREEN not required for this routine to work on the Browser.
It is required for it to work in the CUI of T24.

PRG5.BasicVersionRoutines – R14
R12 18
 The third step is to make an entry in EB.API application for the version routine. Set the
field PROTECTION.LEVEL to NONE and the field SOURCE.TYPE to BASIC and
authorize the record. The ID of the record should be the name of the subroutine.
Attach the routine to the field DEBIT.ACCT.NO in the version record in the fields
VALIDATION.RTN and VALIDATION.FLD

PRG5.BasicVersionRoutines – R14
R12 19
 The validation routine written earlier gets triggered on tabbing out of DEBIT.ACCT.NO
field. However R.NEW in the line of code
Y.ACCT.NO = R.NEW(FT.DEBIT.ACCT.NO) will not contain the value
in Debit Acct No field which is the last value entered. R.NEW
will get populated with Debit Acct No only on committing the
record. The validation routine gets triggered once again on
commit and Debit Currency gets auto populated in the record as
shown.

PRG5.BasicVersionRoutines – R14 20
 When you check the debugger mode on commit, you can see how the values in the
common variable R.NEW changes from time to time. It first takes the account number
that is input by the user, reads the ACCOUNT record gets the currency and populates
it in the validation routine. After you commit the record in Browser, it goes to debug
mode, from where can you actually see the values in the common variables.

PRG5.BasicVersionRoutines – R14
R12 21
 What if you want to validate a value in a particular field just after you tab out of it?
1. To achieve this, when Browser is used as the front end, field level validations will
take place only if a field is set as a hot field. Set up the field ATTRIBS in the
VERSION application as HOT.FIELD to define any field in an application as hot
field.
2. Hot field are shown with a fire symbol next to them.
3. Defining a field as a hot field, automatically sends a validation request to the
server on changing the value in a field. Once you tab out of a hot field after
inputting a value in Browser, the validation routine is triggered.

Now can you continue using the variable R.NEW to get value into the field when you
set a field as HOT.FEILD?

PRG5.BasicVersionRoutines – R14
R12 22
 COMI is the common variable that is to be used when you set a field as a HOT.FIELD
in Browser. COMI holds the last input field value in a record. This variable is a
dynamic array defined in I_COMMON. Values get flushed when the record is exited or
committed or authorized.

PRG5.BasicVersionRoutines – R14
R12 23
 You can use the previous task to understand the use of the common variable COMI.
The first step is to create a version record for the FT application with the necessary
fields and set the field ATTRBIS to HOT.FIELD for DEBIT.ACCT.NO and the field
DEBIT.CURRENCY as NOINPUT field.

PRG5.BasicVersionRoutines – R14
R12 24
 A copy of the routine used previously can be modified to use the common variable
COMI instead of R.NEW.
If you do not use the same routine name you will have to create an EB.API entry
accordingly.

Note – Call to REBUILD.SCREEN not required for this routine to work on the Browser.
It is required for it to work in the CUI of T24.

PRG5.BasicVersionRoutines – R14
R12 25
 After you enter the debit account number and click the tab button, the currency will be
defaulted in the field DEBIT.CURRENCY

PRG5.BasicVersionRoutines – R14
R12 26
 When you set a field as HOT.FEILD, the variable COMI takes the last input value in a
field. If you can analyze the difference between using COMI and R.NEW, COMI takes
the value immediately after input whereas R.NEW takes in the value only after the
record is committed.

PRG5.BasicVersionRoutines – R14
R12 27
 Though COMI is used during field validation , it is insignificant during commit phase.
COMI can be used is the cross validation routine (R5) or .VALIDATE routine of an
application

When a record is commit, for every field in the application, the validation routine
attached at the current application version (if any) would be triggered which is then
followed by either FIELD.INPUT/FIELD.MULTI.INPUT/OFS.FIELD.INPUT as the case
may be. These routines consider that the variable COMI holds the latest updated field
value and assigns the value to R.NEW. Hence if it is required to default any value for a
field from the version routine, one should use COMI.

PRG5.BasicVersionRoutines – R14 28
PRG5.BasicVersionRoutines – R14
R12 29
 An input routine can be used to provide additional checking on the values input.
• Input routine gets invoked just prior to committing a transaction in the unauthorized
stage. They are invoked prior to the final update of files at the unauthorized stage
of a transaction.
• These routines are invoked after all standard default and validation processing is
done.
• Input routine gets invoked even if the record is put on hold
• Routines at this stage may be used to perform additional checking or override
processing
• Input routines are attached in the field INPUT.ROUTINE in the VERSION
application. This is a multi value field and therefore multiple routines can be
attached at this stage. The text to be entered in this field should be a valid
subroutine name that can be executed.

PRG5.BasicVersionRoutines – R14
R12 30
 • When the Input Routine is invoked, the common variable COMI is not be
available to extract any value.
• R.NEW should be used to extract necessary information from a record.
• Many user defined error messages can be part of an input routine. To display
error message, the common variable ETEXT is used.
• STORE.END.ERROR is a T24 subroutine that is capable of displaying the error
message stored in ETEXT.
Syntax is ETEXT = <“ERROR MESSAGE”>
CALL STORE.END.ERROR
By default, STORE.END.ERROR will display the error message in the left top corner
of the browser screen. The variables ‘AF’ which holds the field position, ‘AV’ which
holds the multi value position and ‘AS’ which holds the sub value position defined in
I_COMMON are used to display the error message next to a particular field in
CLASSIC mode. In BROWSER mode only if these variables are set, the system will
display the field name pertaining to which the error was generated.

PRG5.BasicVersionRoutines – R14
R12 31
 In this task you will learn to write an input routine and attach it to the version.
1. When a user commits a record in a version of the FUNDS.TRANSFER application,
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
CURRENCY NOT EQUAL” has to be displayed

2. Fields that need to be displayed as part of the version are

TRANSACTION.TYPE
DEBIT.ACCT.NO
DEBIT.CURRENCY
DEBIT.AMOUNT
DEBIT.VALUE.DATE
CREDIT.ACCT.NO
CREDIT.CURRENCY

PRG5.BasicVersionRoutines – R14
R12 32
 The first step is to create a version record for FT with all the necessary fields. This
learning unit does not teach you how to create a version.

PRG5.BasicVersionRoutines – R14
R12 33
 The next step is to write a subroutine that will extract the debit and credit currency,
compare the values and throw an error if the values are not equal. Compile and
catalog the routine.

PRG5.BasicVersionRoutines – R14
R12 34
 The third step is to make an entry in EB.API application for the version routine. Set the
field PROTECTION.LEVEL to NONE and the field SOURCE.TYPE to BASIC and
authorize the record. The ID of the record should be the name of the subroutine.

Attach the routine in the version record in the field INPUT.ROUTINE

PRG5.BasicVersionRoutines – R14
R12 35
 If the debit and credit currency are not equal, the error message is displayed.

PRG5.BasicVersionRoutines – R14
R12 36
 When you get into debug mode, you can actually see how the variables are assigned
values. Note that the field number assigned to the variable ‘AF’ is the field number in
the actual application and not in the version. Note that when the currency is not the
same, the value is populated into the variable ‘ETEXT’.

PRG5.BasicVersionRoutines – R14
R12 37
 • 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.

PRG5.BasicVersionRoutines – R14
R12 38
 You will now learn to create an authorization routine.
1. 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

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

PRG5.BasicVersionRoutines – R14
R12 39
 The first step is to create a VERSION record for the FT application

PRG5.BasicVersionRoutines – R14
R12 40
 The second step is to create a flat file under the HOME directory.

CREATE.FILE TEMENOS.TRAINING TYPE=UD

PRG5.BasicVersionRoutines – R14
R12 41
 The third step is to write a routine that will extract the required values from the record
and write to the flat file. Use the command OPENSEQ to open the file.

PRG5.BasicVersionRoutines – R14
R12 42
 Use the command WRITESEQ to append the data to the file. If the routine fails to
update the file, then the error message should be displayed. Compile and catalog the
routine.
Note that the variable R.NEW still contains the record and has not yet been flushed to
the database. So, though you can modify R.NEW in an authorization routine, it is not
recommended as all the validations on the record are already complete.

PRG5.BasicVersionRoutines – R14
R12 43
 The third step is to make an entry in EB.API application for the version routine. Set the
field PROTECTION.LEVEL to NONE and the field SOURCE.TYPE to BASIC and
authorize the record. The ID of the record should be the name of the subroutine.
Attach the routine in the version record in the field AUTH.ROUTINE

PRG5.BasicVersionRoutines – R14
R12 44
 Input an FT record in the version and authorize the record.

PRG5.BasicVersionRoutines – R14
R12 45
 Note the contents of the flat file. It holds the record created using the FT version.

PRG5.BasicVersionRoutines – R14
R12 46
 This workshop will help you to write an authorization routine.
Once a record in a version of the CUSTOMER application is authorised, the following
details from the transaction need to be extracted and written on to a flat file named
TEMENOS.XX.CUS.INTERFACE for interface purposes.
XX – Is your name
ID of the record in the flat file needs to be the Customer ID
Following field’s values need to be stored in the flat file all delimited
with a single space
Mnemonic
Sector
Nationality
Language
The above operation needs to be done only if the record being authorised is a new
customer record

PRG5.BasicVersionRoutines – R14
R12 47
 Apart from adding customized routines in version at different levels, it also possible to
control the number of authorizers required to authorise the transaction using this
version. The field NO.OF.AUTH in VERSION allows us to define the number of
authorizer required. The value defined in this field is stored in the common variable
AUTH.NO.

If “0” is defined, then we don’t need a separate action to authorise the transaction. The
commit action will also perform the authorisation. The record is automatically written to
the live file.

If “1” is defined, then we need to perform the “authorise” action.

If “2” is defined, the transaction needs to be authorised twice. After the first
authorisation the RECORD.STATUS of the record will be INA2.

PRG5.BasicVersionRoutines – R14
R12 48
 There are two important common variables to related to versions.

1) PGM.VERSION - This variable holds the active version in use.

2) R.VERSION – This variable is a dimension array which holds the record of the
current version in use.

PRG5.BasicVersionRoutines – R14
R12 49
 1. QUESTION : The value of the common variable C$SYSDIM is equal to 500
TRUE
FALSE
2. QUESTION : R.NEW.LAST holds the ID of the unauthorized record for the currently opened record.
TRUE
FALSE – Holds the actual record
3. QUESTION : ID.OLD holds the ID of the last authorized record.
TRUE
FALSE
4. QUESTION : HOT field should be set in VERSION application
TRUE
FALSE
5. QUESTION : COMI holds the last input field value
TRUE
FALSE
6. QUESTION : ETEXT holds the override message to be generated
TRUE
FALSE – Error message
7. QUESTION : All validation routines should have an entry in the EB.API application
TRUE
FALSE
8. QUESTION : Input routine is invoked on committing a record in authorized stage
TRUE
FALSE – Unauthorized stage
9. QUESTION : STORE.END.ERROR is a routine used to display the error message
TRUE
FALSE

PRG5.BasicVersionRoutines – R14
R12 50
 In this learning unit/course, you learnt about the basic version routines in T24

You will now be able to:

PRG5.BasicVersionRoutines – R14
R12 51
PRG5.BasicVersionRoutines – R14 52