1

2
You can observe that the information shown above is marked as
function, application name etc., These information are accessible by
T24 programs.

3
There are pre-defined common variables in T24 using which such
information from the client browser. is made accessible to code on the
server.

4
Let us understand how data is accessed / modified and validated in a
T24 application. When using applications in T24, we have noticed that
many fields have data validations. How does the code executing behind
the scenes have access to what we see on the screen? When the user
enters an ID, how does the application access that information?
Common variables are used throughout T24 and Template
programming is no exception. Let us take a look at the vital common
variables that are required to create applications in T24.

5
Let us take a look at the important common variables that we must know when
creating applications in T24.

ID.NEW

ID.OLD

ID.NEW.LAST

R.NEW()

R.OLD()

R.NEW.LAST()

All the above mentioned common variables are defined in I_COMMON.

R.NEW, R.NEW.LAST AND R.OLD are three important common variables . When the
validate, commit or authorise button is clicked, these three variables are populated.
R.NEW is populated with the record on the screen. R.NEW.LAST is populated with
the corresponding record from $NAU table if available and R.OLD is populated with
the corresponding record from $HIS table if available. $DEL table record if it exists, will
not get populated in any common variable. ID.NEW, ID.NEW.LAST, ID.OLD contains
the corresponding ID’s of the record (As is obvious the same ID is stored in these
three variables. The purpose of these three ID variables are discussed later)

6
When a request for input is given to T24, For eg AC.DEBIT.CARD I F3, just
before the .RECORD method executes, RECORD.READ routine populates
the COMMON variables R.NEW, R.NEW.LAST & R.OLD with the record from
the corresponding tables(if available). The contents in R.NEW is then
refreshed on the client browser and these variables are cleared.
These COMMON Variables are re-initialised when the user clicks on validate
or commit or authorise on the form, and then the processing method is
invoked.
In the scenario in the slide,
ID.NEW – contains ID of the new Debit Card Record
R.NEW – is a dimensioned array that is populated with the debit card record
from the web-page on commit.
R.NEW takes the format of the underlying application. R.NEW is declared in
I_COMMON as R.NEW(C$SYSDIM), where C$SYSDIM is a common variable
equated to 500 in I_COMMON. 500 is sufficient as no T24 application has
more than 500 fields. However a size of 500 is required as fields can be
multivalued at runtime. C$SYSDIM will have to be re-initialised when this
arithmetic changes in the future.
Once the validation and other processing codes are executed, contents of
R.NEW is written to the $NAU file. In the above example R.NEW(1) refers to
the first field of the DEBIT CARD application and so on. Do not use field
position, use the alias field name instead from the insert.
Eg.,R.NEW(AC.DC.DEBIT.CARD.NO)

7
The DEBIT CARD record committed earlier is currently in the INAU status in the $NAU
table. This record is picked up and refreshed on the browser, when the user issues
the command AC.DEBIT.CARD A DBC1308100033. In this case, R.NEW.LAST is
populated with the record from $NAU table. Since this record has to be displayed on
the browser, R.NEW is also populated with this record. The record is sent in the
response to the browser and the variables are refreshed.

On clicking the Authorise button, the following common variables are re-initialised

R.NEW contains the record from the browser

R.NEW.LAST gets populated with the record from the $NAU table.

ID.NEW & ID.NEW.LAST contains the corresponding ID of the record which is the
same ID. A value in ID.NEW.LAST enables you to check programmatically that the
record in R.NEW has an existing unauthorised version.

After the execution of the processing logic if any, R.NEW is written into the Live table.

If required, R.NEW can be manipulated programmatically before its written onto the
LIVE table. R.NEW.LAST is also a dimensioned array defined in I_COMMON as
R.NEW.LAST(C$SYSDIM). The ID corresponding to the record in this variable is
stored in ID.NEW.LAST, also a common variable defined in I_COMMON.

8
The current status of the DEBIT CARD record is LIVE. When this record is opened for
amendment in T24 and committed, the common variables that come into play are
ID.NEW, R.NEW and ID.OLD, R.OLD. R.NEW is populated with the amended record
from the browser & R.OLD is populated with the LIVE record from the LIVE table.
Please note that the original Live record is in R.OLD and the amended record is in
R.NEW

R.OLD retains the record copy before the amendment. Contents of R.NEW(which
contain the amendments) are then written into the $NAU table. At this stage, the
previously authorized record is in LIVE and the amended record is in $NAU with an
INAU status.

(Amendment of an authorised record is possible only if the application allows it; some
contract based applications do not allow to edit an authorised record).

A value in ID.OLD enables you to confirm programmatically that the currently opened
record has a previously authorized record.

Note:- On authorization of an unauthorised record, the $NAU record is deleted and

9
If the unauthorised record is opened for amendment, then the record
from $NAU file is displayed on the form for the user to modify. On
amendment and commit, the modified record from the form is populated
in R.NEW. The unauthorised record goes to R.NEW.LAST and the
original LIVE record goes into R.OLD. On completion of the processing
code for commit, the values from R.NEW is over-written on the existing
record in the $NAU table.

10
If the unauthorised record is deleted using the D function, then R.NEW
is populated with the record on the browser. The unauthorised record
goes to R.NEW.LAST and the original LIVE record goes into R.OLD.
R.NEW is then written into $DEL file with the ID format <Transaction
reference of unauthorized record>;<Date and Time in milliseconds>.

11
Like the previous case, all three variables are initialised, if you authorize
an amendment to an already authorized record. As shown in the slide,
the record from the form is populated in R.NEW, the INAU record is
populated in R.NEW.LAST and the previously authorized Live record is
populated in R.OLD. ID.NEW, ID.NEW.LAST and ID.OLD contains the
same record id. Contents of R.NEW is then written to the Live table and
R.OLD is written to $HIS table with id as ID.OLD;<CurrNo> where
CurrNo is the sequence no which keeps track of the current version of
the history record.

12
13
14
15
OPERATOR will be used for updating audit fields in a record. The
common variable OPERATOR holds the id of the active user in the
current session. It is not possible to get the list of users logged in the
system.

The USER.ID of the current USER logged in to T24 and his user profile
is loaded in the common variable R.USER. R.USER is declared as a
dynamic array in I_COMMON. Every time T24 needs to perform an
SMS check, instead of reading the USER record, it refers to this
variable. If the user has USER.SMS.GROUP attached, the values of
USER.SMS.GROUP is embedded in the appropriate fields in R.USER

16
R.COMPANY is a dimensioned array

17
R.SPF.SYSTEM – is a Dynamic array which stores the SPF SYSTEM
record

18
19
1.When you input a record in any Application in T24 and On validation it can
generate Errors and Overrides
1.1 Error Messages: Such type of messages are displayed -
Due to data not being input in mandatory fields
Due to incorrect data input
Due to incorrect relationship between field name and the data that is
input.
In case of Error Messages, you need to correct the data input in the particular
fields and commit the transaction again.
A record is not saved till all errors are corrected.

1.2 Override Messages: These are warning messages, at least most of the
time. A user may accept or reject override. If accepted, T24 saves the record
and the override message is stored as part of it in the field OVERRIDE. If you
do not want to accept the Override, you may either put the record on hold to
correct it later or amend the record and commit it again.

20
Its not advised to hard code error messages for two reasons – the same
error message may be required to be displayed in other applications
and in the language preference set by the bank. Hence create a record
for the error message in EB.ERROR and provide this ID in E as shown
in the code snippet. You do not have to explicitly call ERR as it is
implicitly called in THE.TEMPLATE

The requirement is coded in .ID method

21
When using Classic, error messages in T24 are displayed adjacent to the
erroneous field. In Browser, the error messages are displayed with the field
numbers displayed as a link, clicking on which takes the focus to the
erroneous field. Errors can be trapped from anywhere within the life cycle of a
transaction. To display errors adjacent to the appropriate field use AF, AV &
AS. AF is used to refer to the Field Position, AV points to the multivalue
position and AS to the sub value position.

In the example shown Course and Attributes are an associated multi-value

1)Set AF to the field position no of Attributes field. You may use the field alias
name from the related insert file to identify the field position no.

2)Set AV = 2 and AS = 2

3)Raise the error(you will learn to do this in the subsequent slides)

All exceptions raised, appear as errors on the users screen for correction.
T24 will proceed to the next step only on correction of all these errors.

22
Notice the error variable used here is ETEXT instead of E and there is
an explicit call to STORE.END.ERROR. E is used to code for
exceptions, in all methods that gets invoked before the record is
displayed to the user. ETEXT is an advanced error variable which
facilitates display of error messages beside the specific field which
raised the exception. AF in the code denotes the field position where
the error message must be displayed.

The requirement is coded in the .VALIDATE method.

23
In the example shown Class, Name and position are an associated
multivalue set. Name and position are an associated subvalue value
set within the multivalue set. The code snippet sets AF to Class which
is the field for which the validation is being done. Since the field is a
multivalue field, AV is set in a loop. The value entered in the class field
is checked for sequential numbering in the form of 1,2,3…. If the
sequence is violated, it raises an error. The point to note here is that
the error is raised against that multivalue of Class which fails the
validation(Class.2).

Note : Only the required rows in R.NEW is shown in the figure

24
When the loop executes the second time,

AV = 2 and R.NEW(AF)<1,AV> = 3. Therefore, the condition

“ R.NEW(AF)<1,AV> <> AV “ is satisfied and the error is raised against

Note : Only the required rows in R.NEW is shown in the figure

25
The code snippet checks that only two ranking positions are allowed in
a class i.e., Name and Position set is not subvalued more than twice.

Note : Only the required rows in R.NEW is shown in the figure

26
Note the usage of TEXT common variable, instead of E or ETEXT. And
that, the subroutine STORE.OVERRIDE(CURR.NO) is called for
overrides. E, ETEXT and TEXT are common variables defined in
I_COMMON.

The given code is written in the .OVERRIDES method

27
CALL ERR is implicitly called by THE.TEMPLATE.

28
29