At The End of The Session You Will Have Adequate Knowledge To Understand

Objectives
At the end of the session you will have
 Adequate knowledge to understand

 How applications work in T24
 Adequate knowledge to create

 Applications in T24 version R7 and above
 Applications in T24 version R5 and below
 Adequate knowledge to
 Write code to raise accounting entries, overrides, errors, validations
 Create Multi threaded subroutines
Slide 1
Day 1
 An introduction to TEMPLATE programming
 Understanding the TEMPLATE subroutine
Slide 2
What Is An Application In T24?
 T24 Applications
 Allows input of data
 Stores data in database
 Performs a business functionality
 Example: Funds Transfer, Money Market
 T24 Tables
 Allows input of data
 Stores data in database
 Holds static data used by other applications
 Performs no business functionality on its own
 Example: Category, Currency
Slide 3
Applications in T24
 There are different kinds of applications in T24

 H type
 U type
 L type
 T type
 W type
 At database level depending on the kind above, there can be

 A $HIS file (Data)
 A $NAU file (Data)
 A Live file (Data)
 A ]D file (Dict)
Slide 4
Functions in T24
 There are different functions that can be used with these applications
 I Input
 A Authorise
 S See
 L List
 V Verify
 C Copy
 D Delete
 R Reverse
 H History Restore
 2 Second Authoriser
 P Print
Slide 5
Application Classification
 Applications can be either

 CUS
 FIN
 INT
 Other classifications available too, but have properties of one of the above
 Naming conventions for database files
 CUS – F<MNE>.<APPLICATION>{$<SUFFIX}
 FIN – F<MNE>. <APPLICATION>{$<SUFFIX}
 INT – F. <APPLICATION>{$<SUFFIX}
Slide 6
Definitions from T24
 What is an Application in T24?

 An application in T24 allows input of data and performs some business
processing too.
 What is a Table in T24

 A table too stores data, static data that can be used by one or more
applications
 What is a Product?
 One or more applications and tables that work together to perform a
business functionality
Slide 7
Before Creating An Application
 We must decide a name for our application
 What type of application (H, U, L, T, W)
 What classification (CUS, FIN, INT)
 We must decide what functions are going to be permitted
 We must decide fields

 Data types
 Max, Min Characters
 Field Names
 Extra validations of data
 Other related file updates
 What is the business functionality to be built in

Slide 8
Application flow in T24 – Always the same
1. Enter Application Name
T24 checks if a VALID Application is entered.
2. Enter Function and ID
When data is entered and we hit enter, T24 validates it as a function.
When we enter data and hit the edit button, the function is taken as I and the
data is validated as an ID of the application
3. Open record
Checks if record exists with same ID, if yes read from file and load into cache
If record does not exist, open new record for user.
4. Enter Data and Commit
Validates data, raises errors or overrides and saves record in database
5. Authorise Record
If everything is OK, save changes in the database, update other applications if

required
Send advices to customer (if any)
Slide 9
We have decided
Business Functionality
When and What we must do
Other Features
-Functions My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
T24 Application Flow
Slide 10
Code…
 If we want to develop an application in T24, do we have to start writing

code from scratch?
 NO NO NO
 There are two core subroutines called TEMPLATE and

THE.TEMPLATE that we must use to create an application
 That’s why this course is called TEMPLATE PROGRAMMING 
Slide 11
What now…
Business Functionality
When and What we must do
METHODS
Other Features
-Functions My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
Properties defined in TEMPLATE
T24 Application Flow

THE.TEMPLATE
Slide 12
Common Variables
 Variables in T24
 Global
 Local
 Most variables used in TEMPLATE programming can be found in

I_COMMON
 Application / Product specific common variables also available

 I_ENQUIRY.COMMON
 I_GTS.COMMON etc
 Must include I_ file in all code
 $INSERT I_File - will look for I_ file in current directory, GLOBUS.BP and
bnk.run
 $INCLUDE <Dir> I_File– must specify the directory in which file is present
Slide 13
A Must Know
 Following common variables need to be understood before we attempt to

create version routines
 ID.NEW
 ID.OLD
 ID.NEW.LAST
 R.NEW()
 R.OLD()
 R.NEW.LAST()
 All the above mentioned variables are common variables defined in

I_COMMON.
Slide 14
What Happens When A New Record Is Created In T24?
 User creates new CUSTOMER record using CUSTOMER I F3

 When record is committed…
ID.NEW : 123456 ID.NEW.LAST - NOT USED ID.OLD - NOT USED
R.NEW R.NEW.LAST R.OLD

Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100 NOT USED NOT USED
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :
Slide 15
ID.NEW
 Common variable defined in I_COMMON
 Contains the ID of the currently opened record in any application
 When the record is closed or committed or authorised the value in this

variable gets flushed.
Slide 16
R.NEW
 Dimensioned array which comprises of 500 dynamic arrays
 Holds the currently opened record in any application
 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’
Definition as seen in I_COMMON : DIM R.NEW(C$SYSDIM)

Where C$SYSDIM = 500
 Inference : Since the size of R.NEW is now restricted to 500 it implies that
no application in T24 has more than 500 fields. The day it exceeds 500,
C$SYSDIM’s value will be increased
Slide 17
When Happens When A Record Is Authorized?
 User opens INAU record to authorise it
ID.NEW : 123456 ID.NEW.LAST – 123456 ID.OLD – Not Used

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 Sector : 1100 Not Used
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : INAU Record Status :INAU
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED
Slide 18
ID.NEW.LAST
 If an unauthorized record exists for the currently opened record in any

application, this variable will hold the ID of the unauthorized record
 You may ask, ‘Will the ID of a live record and a unauthorized record
ever be different?”
 No. This variable enables us to know, programmatically whether an
unuathorised record exists for the currently opened record
Slide 19
R.NEW.LAST
 Holds the currently opened record in any application
 ID.NEW.LAST holds the ID of the currently opened record’s unuathorised

record (if it exists), while R.NEW.LAST holds the actual unauthorized record
(If it exists). ‘R’ in the variable name stands for ‘Record’
Definition as seen in I_COMMON : DIM R.NEW.LAST(C$SYSDIM)

Slide 20
What Happens When An Authorized Record Is Amended?
ID.NEW : 123456 ID.NEW.LAST – NOT USED ID.OLD - 123456

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 1200 NOT USED Sector : 1100
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : Record Status :
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED
Slide 21
ID.OLD
 If an authorized record exists for the currently opened record in any

application, this variable will hold the ID of the authorized record
 This variable enables us to check programmatically whether the

currently opened record has a previously authorized record
Slide 22
R.OLD
 Holds the currently opened record’s previously authorized record (if

any) in any application
 ID.OLD holds the ID of the currently opened record’s authorised record

(if it exists), while R.OLD holds the actual live record (If it exists). ‘R’ in
the variable name stands for ‘Record’
Definition as seen in I_COMMON : DIM R.OLD(C$SYSDIM)

Slide 23
What Happens When A Change On An Authorized Record Is Authorized?
The old authorized record (With Sector 1100) goes to history (FBNK.SECTOR$HIS)
ID of the record in the history file will be 123456;1
Contents of R.NEW is written to the LIVE file
ID.NEW : 123456 ID.NEW.LAST - 123456 ID.OLD - 123456

Mnemonic : TRG Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD Street : RANGA ROAD
Sector : 1200 Sector : 1200 Sector : 1100
Target : 999 Target : 999 Target : 999
Customer Status : 1 Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN Nationality : IN
Residence : IN Residence : IN Residence : IN
Language : 1 Language : 1 Language : 1
Record Status : INAU Record Status : INAU Record Status :
Slide 24
Common Variables – I_COMMON
We must learn the use of these common variables before we continue
 V$FUNCTION – Holds the T24 function entered by the user
 MESSAGE – Allows inter routine or inter para communication by setting

process ‘state’ in this variable
 AF, AV, AS – Holds the field position, multi value position and sub value
position respectively
 E and ETEXT – Variables used to store error message to be displayed.

E is used by THE.TEMPLATE itself to display errors if any
 ID.COMPANY and R.COMPANY – Variable that holds the ID of the

company we are currently logged into and the COMPANY record is
loaded into R.COMPANY
Slide 25
Some more Common Variables
 R.USER - Loaded as soon as the user logs in, holds the USER profile
 OPERATOR – ID of the User currently logged in
 APPLICATION - Holds the name of the application currently in use. In

T24 only one application can be active at a given point in time
 LCCY, LNGG
 Holds Local Currency as defined in company
 Holds the language from the USER profile
 TODAY - Holds T24’s today (date)
 C$SYSDIM – Common variable equated to 500 in I_COMMON, used to

define the size of all dimensioned array common variables
Slide 26
The TEMPLATE Subroutine
Static Information or Properties of our application
 Use core subroutine TEMPLATE (GLOBUS.BP)
 We must decide a name for our application
 What type of application (H, U, L, T, W)
 What classification (CUS, FIN, INT)
 We must decide what functions are going to be permitted
 Why do we need to mention all this?

 To create additional components of an application
Slide 27
Other Component of an Application
 What does T24 do with all the properties of the application we define in
the TEMPLATE subroutine?
 There are other components of an application other than code
 PGM.FILE Entry
 Type of application
 Special properties (additional info)
 FILE.CONTROL Entry
 File suffixes available
 Classification
Slide 28
Other Component of an Application
 STANDARD.SELECTION Entry
 Actual field names
 Field properties
 Insert File - I_ File

 For programming
 Files at database level to store data

 To store data 
Slide 29
Getting Started
 DO NOT MODIFY the TEMPLATE subroutine in GLOBUS.BP
 Each application that we create, must have its own copy of the
TEMPLATE
jsh-->COPY FROM GLOBUS.BP TEMPLATE TO DBCARD.BP
jsh-->COPY FROM DBCARD.BP TEMPLATE, <NEW APPNAME>
 The above line must be modified to reflect <NEW APPNAME> as the

name of the subroutine
 Properties of an application are defined here
Slide 30
Table Objects
Table.name = 'XX.TABLE.NAME' ;* Full application name

Table.title = 'XX TABLE.NAME' ;* Screen title
Table.stereotype = 'H' ;* H, U, L, W or T
Table.product = 'XX' ;* Must be on EB.PRODUCT
Table.subProduct = ‘ ' ;* Must be on EB.SUB.PRODUCT
Table.classification = 'INT' ;* As per FILE.CONTROL
Table.systemClearFile = 'Y' ;* As per FILE.CONTROL
Table.relatedFiles = '' ;* As per FILE.CONTROL
Table.isPostClosingFile = '' ;* As per FILE.CONTROL
Table.equatePrefix = 'XX.YY' ;* Use to create I_F.EB.LOG.PARAMETER
Table.idPrefix = '' ;* Used by EB.FORMAT.ID if set
Table.blockedFunctions = '' ;* Space delimited list of blocked
functions
Table.trigger = '' ;* Trigger field used for OPERATION
style
Slide 31
How are the properties used?
 The ID of the FILE.CONTROL ,PGM.FILE and SS entry - Table.name
 The TYPE for the PGM.FILE record – Table.stereotype
 The SCREEN.TITLE in PGM.FILE record(Description) – Table.title
 The PRODUCT field in FILE.CONTROL and PGM.FILE – Table.product
 The CLASSIFICATION field in FILE.CONTROL – Table.classification
 The prefix for all fields in the I_ files – Table.equatePrefix
 Functions that are not allowed for the application –

Table.blockedFunctions
Slide 32
I_Table
 Contains all common variables used in table object
COMMON/OBJECT.TEMPLATE/Table.fieldNeighbourArray(C$SYSDIM),Table.name,
Table.title,
Table.stereotype,
Table.product,
Table.subProduct,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
Table.triggerField,
Table.classification,
Table.noInputFields,
Table.inputtableFields,
Table.lastApplication,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
Table.triggerField,
Table.lastCompany,
Slide 33
How is TEMPLATE and THE.TEMPLATE related?
 To launch an application, we type its name in the command prompt

 It is validated – VALIDATE.APPLICATION subroutine
• Checks PGM.FILE
 Calls RUN.APPLICATION which in turn calls

EB.EXECUTE.APPLICATION
 Calls subroutine with <APPLICATIONNAME>
 Subroutine APPLICATION name is nothing but a copy of TEMPLATE

with static properties, and the list of methods to be called
 EB.EXECUTE.APPLICATION also invokes THE.TEMPLATE
Slide 34
SUBROUTINE EB.EXECUTE.APPLICATION(APPLICATION.NAME)
Table.name = ''
CALL @APPLICATION.NAME
IF Table.name THEN
CALL THE.TEMPLATE ;* We need to call the central template routine
END ELSE
Table.lastApplication = "" ;* We've called a non central template
END
Note: In releases before R9, EB.EXECUTE.APPLICATION called the <Application>

Subroutine which in turn called THE.TEMPLATE
Slide 35
THE.TEMPLATE Subroutine
 The core subroutine used by every application in T24 since it contains

the execution flow
 An application’s business logic is broken up into individual subroutines,

called method.
 THE.TEMPLATE contains code to call or invoke these methods at the

right time
Slide 36
Methods in Template Programming
 The business logic of an application is not part of TEMPLATE or

THE.TEMPLATE
 It is split up into methods
 There are 11 methods available for use
 THE.TEMPLATE determines the order of execution
 Methods are nothing but individual subroutines called from

THE.TEMPLATE
 Must follow naming convention APPNAME.METHODNAME
Slide 37
Methods
 Where are method names defined?
 Are they hard coded?
Slide 38
I_METHODS.AND.PROPERTIES
 Common variable to define method names
 Methods with different names ignored
Slide 39
 T24’s convention is to represent each position C_ROUTINES array by

a name not a number
Slide 40
Methods in Template Programming
 INITIALISE
 FIELDS
 FUNCTION
 ID
 RECORD
 VALIDATE
 PREVIEW
 OVERRIDES
 PROCESS
 AUTHORISE
 RUN
 This is also the order in which they are executed by THE.TEMPLATE
Slide 41
Day 2
 Understanding THE.TEMPLATE flow
Slide 42
THE.TEMPLATE
 Pattern of Execution of an application
 MUST NOT BE MODIFIED
 Advantage of having THE.TEMPLATE

 We can maintain code consistency and code standard
 Enables rapid code development, no need to start from scratch
Slide 43
Behind the Scenes – THE.TEMPLATE
Launch Application from Command Prompt
 Initialise
 The first method to be executed when an application is launched
 Fields
 The next method to be executed
Input Record ID and press Enter (Function defaulted to I)
 Function
 This is executed after a function is entered by the user. If no function is
entered, the default is Input.
 ID
 Executed after the function entered is validated. Validated ID, can modify ID
if required
Slide 44
 Record
 Executed before the record requested (existing or new) is displayed to the
user
Record requested is displayed (existing or new)

Data is input / modified, then Commit
 Validate
 After values are defaulted (if any) all data is validated
 Preview
 After data is validated, a delivery preview is available
 Overrides
 Overrides if any are generated now
Slide 45
 Process
 If all overrides are accepted, then this method is called before the record is
written to the $NAU file
Record is written to $NAU NOW
Authorise button is clicked
 Validate
 All data is validated twice, once during commit and once during authorise
 Authorise
 This is executed after the Authorise button is clicked
Record is written to LIVE NOW

Run
 This is executed if the function used is Verify
Slide 46
Using the Template Methods – Common Variables Available
 INITIALISE
 Anything that needs to be done as soon as an application is launched can be
done here. It is not a mandatory method
 FIELDS
 This is the method in which an applications fields are defined. This is a
mandatory method as an application must have at least one field
 FUNCTION
 Code that need to be executed depending on the function entered,
manipulation of the function itself can be done here (V$FUNCTION)
 ID
 Special editing to the ID entered, special validations to the ID (ID.NEW)
 RECORD
 Editing of the requested record before display to the user (R.NEW,
R.NEW.LAST,R.OLD)
Slide 47
Using the Template Methods
The methods listed here are executed after Commit is clicked
 VALIDATE
 Special validation of data
 R.NEW, R.NEW.LAST, R.OLD, E, Subroutine ERR
 OVERRIDES
 Overrides if any, must be raised here
 R.NEW, R.NEW.LAST, R.OLD, ETEXT, Subroutine STORE.OVERRIDE
 PROCESS
 Processing that has to be done before the record is written to the $NAU file
Limits
Accounting
Charges
Slide 48
Using the Template Methods
The methods listed here are executed after Authorise is clicked
 AUTHORISE
 Processing to be done before record is written into LIVE file
Accounting
Delivery
Updating associated applications
 RUN
 This method is called only for W type applications that use the Verify
function
Slide 49
What Can Applications In T24 Do?
 The ability to have custom validations for data entered other than the
validations performed by the IN2 routines that are invoked because of the
data type of a field.
 The ability to be customised (add extra functionality) by clients if required
 The ability to raise overrides and errors
 The ability to generate delivery advices (1 or more)
 The ability to raise accounting entries
 The ability to raise charges
 The ability to add / remove fields
 Associated COB processing if required
Slide 50
Digging Deep - THE.TEMPLATE
 Launch an application from the prompt
 Core subroutine VALIDATE.APPLICATION called

 Checks PGM.FILE Entry
 Checks if application can be used in GUI
 Checks User SMS
 Checks valid token for browser
Slide 51
 RUN.APPLICATION is now called which in turn calls

 This calls a subroutine with the application name – nothing but the
subroutine which a copy of TEMPLATE
 EB.EXECUTE.APPLICATION also calls THE.TEMPLATE
 INITIALISE Method invoked first
 Application ready to receive input of function or ID
Slide 52
 On hitting enter, the application thinks we have entered a function and

validates that – FUNCTION method
 With any input, if we click the Edit button, it validates the data against
the ID of the application – ID method
Slide 53
 Core routine RECORD.READ called to fetch the requested record

 Searches in
 Search in the $NAU File for the application
 Search in the Live File for the application
 Search in the $HIS File for the application
 Else displays new record
 Before displaying record, RECORD method executed
 FIELD.INPUT and FIELD.DISPLAY are two core routines that take care
of displaying the application screen
 FIELD.MULTI.INPUT, FIELD.MULTI.DISPLAY routines available to deal

with multiple fields per line if using version
Slide 54
 Click Commit or Validate and then…

 Can move on only after correcting errors
 VALIDATE method
Slide 55
 Overrides come next

 No option to reject overrides, just change data and Commit again
 OVERRIDES method
Slide 56
 PROCESS method executed

 UNAUTH.RECORD.WRITE called to update $NAU file in database
 Constraint processing invoked if any – Used to set user defined conditions
and overrides
 STP processing done here if set – Used for automatic authorization
versions based on conditions
 Version routines invoked if using version
 Audit fields updated
 Existing INAU record over written if any
 Deals slips triggered if any
 Everything is going to be ok…
Slide 57
 Record opened for authorisation
 VALIDATE method
 AUTHORISE method
 AUTH.RECORD.WRITE called to update Live file

 Call version routines if any
 Update CONCAT files if any
 Update AUDIT fields
 Update JOURNAL
Slide 58
JOURNAL ???
 F.JOURNAL
 Used for recovery purposes before
 F.JOURNAL at any given time will only hold the last 20 transactions per user
 Replaced with jBASE Transaction Journaling
 F.WRITE writes to cache

 FWC, FWT, FWF
 JOURNAL.UPDATE flushes data to disk from cache
Note: F.JOURNAL will hold the transaction details only if the field INFO.JOURNAL in SPF is
set to YES.
Slide 59
Day 3 & 4
 Discuss the DEBIT CARD example
 Creating Fields in an Application
 Creating required applications
Slide 60
DEBIT CARD EXAMPLE
DEBIT CARD EXAMPLE
Slide 61
Debit Card Example
 Let us now create an application on our own - Read the Business

Specification now
 To provide the Debit Card feature in T24 we need to

 Create an application that will store all debit cards issued
 Create an application that will store parameter values
 Create an application that will store different types of debit cards available
 Create an application that will store all debit card transactions
 We must make sure to create a directory to keep the code that we are
going to write
jsh-->CREATE.FILE DBCARD.BP TYPE=UD
jsh-->COPY FROM GLOBUS.BP TO DBCARD.BP TEMPLATE
Slide 62
Debit Card Example
 To create any type of application, we must make a copy of the

TEMPLATE subroutine from GLOBUS.BP
jsh-->COPY FROM DBCARD.BP TEMPLATE,APPLICATIONNAME
 To create the fields for an application, we must make a copy of the

TEMPLATE.FIELDS subroutine from GLOBUS.BP
jsh-->COPY FROM GLOBUS.BP TO DBCARD.BP TEMPLATE.FIELDS
jsh-->COPY FROM DBCARD.BP TEMPLATE.FIELDS,APPLICATIONNAME.FIELDS
Slide 63
What we want to achieve…
Slide 64
What we want to achieve…
Slide 65
Defining Fields
 Fields of an application are defined in the .FIELDS methods
 Though not made mandatory, this method must exist, since an

application must contain at least one field
 This method is called after the .INITIALISE method
 Uses the common variables from I_COMMON

 F
 N
 T
 ID.F
 ID.N
 ID.T
 CONCATFILE
 CHECKFILE
 ID.CHECKFILE
 V
Slide 66
F Array
 Dimensioned array used to specify field name, multi-value status
 Used only for fields in an application, not the ID
 Normal Field
F(Field position) = ‘FIELDNAME1’
 Simple Multi value

F(Field position) = ‘XX.FIELDNAME2’
 Associated Multi value (with sub value)

F(Field position) = ‘XX<FIELDNAME1’
F(Field position) = ‘XX.XX<FIELDNAME2’
F(Field position) = ‘XX.XX>FIELDNAME3’
F(Field position) = ‘XX>FIELDNAME4’
Slide 67
F Array
 Language Multi value
F(Field position) = ‘XX.LL.FIELDNAME1’
 F Array equivalent used ONLY for ID of an application

ID.F = ‘DEBIT.CARD.ID’
Slide 68
N Array
 Dimensioned array used to specify

 Maximum Characters
 Minimum Characters
 Field validations attached
Syntax Used Description
’10’ Up to 10 characters allowed, no special editing will be done.
’35.2’ A maximum of 35 characters, but at least 2 must be entered (Mandatory

Field)
'006.6' Input must be 6 characters. Leading zeros will not be removed and the field
data will be validated at commit time.
Slide 69
ID.N
 N Array equivalent used to define ID properties only
ID.N = ‘16’
ID.N = ’16.1’ ; * .1 makes the field mandatory
Slide 70
T Array
 Dimensioned array that holds information about

 Data type
 List of possible values
 NOINPUT / NOCHANGE characteristics
 Justification
 HOT.FIELD, HOT.VALIDATE properties
 Has 10 sub fields to specify all field properties
 T(Field position)<1> - Data type to call IN2 routine

 T(FieldPosition)<1> = ‘A’ will call IN2A routine to validate the data entered
 T(Field position)<2> - List of input options if predefined

 T(FieldPosition)<2> = “Yes_No_Maybe”
 T(FieldPosition)<2> = ‘1001…5000’ will display all numbers from 1001 to 5000
Slide 71
T Array
 T(FieldPosition)<3> - NOINPUT/NOCHANGE/EXTERN
 NOINPUT – Field never available for input
 NOCHANGE – Field not inputtable after record is authorised
 EXTERN – Field is cleared if record is copied
 T(FieldPosition)<4> - Format Mask

 Data can be displayed differently, irrespective of how it is stored in the
database. The Mask character used is #
 T(FieldPosition)<5> - Justification
 Default Left justified, no need to specify T(FieldPosition)<5>
 Right justified (R) and center justified (C ) are the other 2 options
Slide 72
T Array
 T(FieldPosition)<6> - MACHINE to default to machine date instead of

T24 date
 Used in the USER application
 T(FieldPosition)<7> - TEXT to display a text box in the browser
 T(FieldPosition)<8> - NOMODIFY/NODELETE/NOEXPAND
 No Modification or changes allowed to multi value set after first authorisation
 Multi value set cannot be deleted after record is authorised
 Multi value set cannot be expanded further after authorisation
 T(FieldPosition)<9> - HOT.FIELD/HOT.VALIDATE/WEB.VALIDATE
 HOT.FIELD causes field to be validated immediately
 HOT.VALIDATE causes all fields to be validated
 WEB.VALIDATE triggers validation at web server level
Slide 73
Built-in Data Types
 T24 supports a lot of built-in standard data types
 Built-in data types are equated to standard names in an Insert file

called I_Datatypes
Slide 74
I_Datatypes
EQU T24_String TO 'T24.STRING'

EQU T24_BigString TO 'T24.BIG.STRING'
EQU T24_Text TO 'T24.TEXT'
EQU T24_TextWide TO 'T24.TEXT.WIDE'
EQU T24_Numeric TO 'T24.NUMERIC'
EQU T24_Date TO 'T24.DATE'
EQU T24_Portfolio TO 'T24.PORTFOLIO'
EQU T24_Account TO 'T24.ACCOUNT'
EQU T24_InternalAccount TO 'T24.INTERNAL.ACCOUNT'
EQU T24_Customer TO 'T24.CUSTOMER'
EQU T24_Frequency TO 'T24.FREQUENCY‘
EQU Field_Mandatory TO ',mandatory'

EQU Field_NoInput TO ',NOINPUT'
EQU Field_NoChange TO ',NOCHANGE'
EQU Field_Unique TO ',UNIQUE'
EQU Field_NoNulls TO ',NONULLS'
EQU Field_AllowNegative TO ',ALLOW.NEGATIVE'
COMMON/DataTypeCommon/DataType.list,
DataType.nArrays,
DataType.tArrays,
DataType.checkFiles
Slide 75
TableUtil.loadFieldTypes
 THE.TEMPLATE invokes TableUtil.loadFieldTypes which loads the id,

length and type depending on the basic data types
IF NOT(DataType.list) THEN
CALL TableUtil.loadFieldTypes
END
 DataType.list is a common variable in I_Datatypes, which holds the list

of data types
 The values populated by this subroutine are session specific
Slide 76
TableUtil.loadFieldTypes
 Loads each of the basic data types as given below
SUBROUTINE TableUtil.loadFieldTypes
id = "T24.STRING"
length = 35
type = "A"
file = ''
GOSUB addBasicType

addBasicType:
typePos +=1
DataType.list<typePos> = id
DataType.nArrays<typePos> = length
DataType.tArrays<typePos> = LOWER(type)
DataType.checkFiles<typePos> = file
RETURN
Slide 77
Field Definitions
Field Definitions
Slide 78
Defining Fields – API’s
 T24 supports a number of API’s are used to define fields.
 These API’s internally update the F, N and T arrays.
Slide 79
Table.defineId
 Defines the ID field
 ID.F, ID.N and ID.T are assigned
 Table.defineId(idName, dataType)
 It takes 2 parameters, the id name (ID.F item) and the data type of the
key
 The data type of the key can either be
 A standard data type defined in I_Datatypes in DataType.list
 Populate data type with values corresponding to N and T arrays
Slide 80
Table.defineIdProperties
 Defines the ID field
 ID.F, ID.N and ID.T are assigned
 Table.defineIdProperties(idName, dataType)
 Table.defineId invokes this API to define the fields.

SUBROUTINE EB.DEBIT.CARD.PARAMETER.FIELDS
dataType = ''
dataType<2> = 16.1
dataType<3> = ''
dataType<3,2> = 'SYSTEM'
CALL Table.defineId("DB.PARAMETER.ID",dataType)
Slide 81
Table.addField
 Adds a field with standard data types
 Table.addField(fieldName, fieldType, args, neighbour)
 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• fieldType - The standard T24 data type of the field
• args - Any arguments (mandatory, no input, etc.)
• neighbour - Reserved for future use.
 The various arguments possible are : Field_NoChange, Field_NoInput,
Field_Mandatory, Field_AllowNegative, Field_unique, Field_NoNulls
CALL Table.addField("XX.LL.DESCRIPTION",T24_String,‘‘,‘‘)
Slide 82
Table.addFieldDefinition
 Adds a field using the F, N and T definitions
 Table.addFieldDefinition(fieldName, fieldLength, fieldType, neighbour)

• fieldLength - The length of the field. “N” array item
• fieldType - The type of the field. “T” array item
• neighbour - Reserved for future use
CALL Table.addFieldDefinition("XX.LL.DESCRIPTION",35,‘A‘,‘‘)
Slide 83
Table.processArgs
 Processes the arguments passed to Table.addField API
 Assigns the N array and T array positions according to the arguments.
 Table.processArgs(args, nArrayItem, tArrayItem)

• args – the list of arguments passed to Table.addField.
• nArrayItem - The N array item to process
• tArrayItem - The T array item to process
Slide 84
Field.setAttributes
 Sets the N and T array
 Field.setAttributes(fieldLength, fieldType, neighbour)

• fieldLength : The N array item
• fieldType : The T array item
• neighbour : Reserved for future use
 Table.addField and Table.addFieldDefinition use this API to set the

N
and T arrays based on the parameters passed on to them
Slide 85
EB.LOOKUP
 T24 allows us to hard code drop down options for a field in the T array
 EB.LOOKUP now allows us to define dynamic drop down values
Slide 86
Table.addFieldWithEbLookup
 Add a field with a virtual table
 Used to create a field with a finite set of predefined options
 Table.addFieldWithEbLookup(fieldName, tableName, neighbour)

• tableName – The virtual table name used to access values in EB.LOOKUP
Application.
Slide 87
Table.addVirtualTableField
 Adds a field with a virtual table.
 Performs the same functionality as Table.addFieldWithebLookup,

except that the list of options are configurable.
 Table.addVirtualTableField(fieldName, tableName, args, neighbour)

• tableName – The virtual table name used to access values in EB.LOOKUP
Application.
• args - (optional) Any additional arguments (mandatory, no input, etc.)
Slide 88
Field.setDefault
 Sets the default value for the current field
CALL Table.addField("START.DATE",T24_Date,Field_NoInput,'')
CALL Field.setDefault(TODAY) ;* Assign default value
Slide 89
CHECKFILES
 Variable used to store Application Vet details for a field
 Only ID of record from CHECKFILE Application is defaulted into field
 Enrichment can be any field from the CHECKFILE Application
CHECKFILE(currentFieldPosition) = tableName : FM : enrichmenentField
Slide 90
Field.setCheckFile
 Adds a check file to a field
 Turns tableName(argument to Field.setCheckFile) into a checkfile argument

using the default enrichment field (DEFAULT.ENRICH field) set on standard
selection or the 1st field.
CALL Table.addField("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL Field.setCheckFile("CUSTOMER")
 For the field Customer, whatever is entered in validated against the

CUSTOMER application.
 This routine internally assigns.

CHECKFILE(currentFieldPosition) = tableName : FM : enrichmenentField
Slide 91
Table.addAmountField
 Adds amount field to the application
 Table.addAmountField(fieldName, currencyFieldName,args, neighbour)
fieldName - The name of the field to add. The "F" array item
currencyFieldName – Name of the field that holds the currency the field is held
in.
args – Any additional arguments (mandatory, no input, etc.)
neighbour – Reserved for future use
CALL Table.addAmountField("MAX.WITHDRAWAL.AMT",'CURRENCY','',' ')
Slide 92
Table.addOptionsField
 Adds a field with pre-defined set of options
 Table.addOptionsField(fieldName, options, args, neighbour)

options – The list of options separated by an ‘_’. The T(fieldposition)<2> item.
neighbour – Reserved for future use.
CALL Table.addOptionsField("WITHDRAW.SWIPE","S_W",'','')
Slide 93
Table.addYesNoField
 Adds a simple field that holds the value YES or blank
 Table.addYesNoField(fieldName, args, neighbour)

neighbour – reserved for future use
Slide 94
Table.setAttributeOnFields
 API to set a number of fields to be NOINPUT, NOCHANGE or inputtable
 Table.setAttributeOnFields(attribute, fieldList)

attribute - The attribute to set. One of NOINPUT, NOCHANGE or “ “
fieldList - The list of fields to set the attribute on. These are field numbers
 Loops through each field in fieldList and sets the atribute in the third field of the T
array. Loops through each field in fieldList and sets the atribute in the third field of
the T array
 More than one field can be set to one specified attribute.
Slide 95
Table.addReservedField
 All new applications must define a set of reserved fields that can be used
to add extra fields to the application without the need to change the
layout of the data
 The name of the reserved fields must be of the form RESERVED.1 etc.,
 Reserved fields can be added in 2 ways
CALL Table.addReservedField(“RESERVED.1”)
CALL Table.addField("RESERVED.1", T24_String, Field_NoInput,"")
Slide 96
Table.addDeliveryReferenceField
 Applications that raise delivery events must define a field to hold the
delivery references
 The name of this field should be DELIVERY.REF
 Delivery Reference fields can be added in 2 ways
CALL Table.addDeliveryReferenceField(neighbour)
CALL Table.addField(“XX.DELIVERY.REF", T24_String, Field_NoInput,"")
 It can be multi valued to hold delivery references for multiple parties

involved
Slide 97
Table.addLocalReferenceField
 Local reference fields allows T24 clients to add user definable fields to
the application.
 The name of this field should be LOCAL.REF
 Local reference fields can be added in 2 ways
CALL Table.addLocalReferenceField(neighbour)
CALL Table.addField(“XX.LOCAL.REF", T24_String, Field_NoInput,"")
Slide 98
Table.addStatementNumbersField
 Applications that raise accounting entries must define a field to hold the
entry ids that have been raised
 The name of this field should be STMT.NOS
 Statement Numbers field can be added in 2 ways
CALL Table.addStatementNumbersField(neighbour)
CALL Table.addField(“XX.STMT.NOS", T24_String, Field_NoInput,"")
Slide 99
Table.addOverrideField
 All applications MUST have a field to store overrides
 Override fields can be added in 2 ways
CALL Table.addOverrideField
CALL Table.addField(“XX.OVERRIDE", T24_String, Field_NoInput,"")
Slide 100
Table.setAuditPosition
 Sets the position of the audit fields when defining the field definition for
a table.
 This API uses ADD.COMMON.FIELDS to create audit fields and set

their position.
Slide 101
Audit Fields
 RECORD.STATUS – Holds status of record(INAU, IHLD, REVE etc.,). A live

record does not have any status
 Two other audit fields AUDITOR.CODE and AUDIT.DATE.TIME not populated

here – only when you use the Q function
Note: The order of definition of fields must be such that the overrides field is just before the audit fields
and the STMT.NOS field must precede the overrides field.
Slide 102
CONCAT Files
 CONCAT files help eliminate unnecessary selects
 Example - CUSTOMER.ACCOUNT
 When CONCAT file is specified for a field in the application, data from
field is ID to record in CONCAT file and ID.NEW is the data of the record
in CONCAT file
 Code to update CONCAT files is part of THE.TEMPLATE

CONCATFILE(FieldName) = ‘ID.OPTION’:FM:’APPLICATION.NAME’
 ID Options are AL, AR, NEW
 The CONCAT application must be created separately since that too is an

application in T24, only updates are automatic
Slide 103
Non Stop Compliance
 C$NS.OPERATION - Common variable defined in I_COMMON.
 It controls the behaviour of an application when the NS (Non Stop)

module is installed.
 This variable can be set to -
 ALL – Non stop allowed if module is installed. Meaning application will

behave normally even when COB is executing
 NEW – Only New deals allowed if NS is installed when COB is running
 NOD – NS complaint only if .NOD is mentioned in the application’s

PGM.FILE entry, where .NOD means No Dates record required for its
processing.
Slide 104
Workshop
 Copy the TEMPLATE subroutine for all DEBIT CARD related

applications
 Create the required fields for each of them using the API’s discussed
Slide 105
How to create additional components?
 We have created the fields for our application
 Do we have to manually create all the necessary additional

components to make our application work?
Slide 106
How to create additional components?
 No, EB.DEV.HELPER will do it for us…..
Slide 107
EB.DEV.HELPER
 Workfile Application to create

 PGM.FILE entry
 FILE.CONTROL entry
 I_ File(insert file in BP)
 STANDARD.SELECTION
 Create files at Database level
 Create DAS routines – discussed later on…
 Record ID is Application Name
 Verify record
 Say Y to all questions asked
Slide 108
When to create which additional component?
 If static properties have changed

 Rebuild PGM.FILE, FILE.CONTROL, DATABASE FILES if required
 If the field name has been changed

 Update I_File and SS
 If the field properties have been changed

 Update SS
 If a new field has been added

 Update I_File and SS
 If the application name has to be changed

 Update all components
Slide 109
Workshop
 Run EB.DEV.HELPER and create additional components for all the

applications created relating to DEBIT CARD
Slide 110
Day 5
 Validation and Workshops
Slide 111
Data Validations
Data Validations
Slide 112
Validating Data
 ID validation can be done in .ID method
 Data validation must be written in .VALIDATE method
 Overrides to be raised are also part of validating data, but must be

written in the .OVERRIDES method
 Extra validations (Client customization) can be done via Version

Routines
 Validation Routines
 Input Routines
 Authorisation Routines
 ID Routine
 Check Record Routine
 After UNAU Routine
 Before AUTH Routine
Slide 113
.RECORD Method – Debit Card Example – EB.DEBIT.CARD
POPULATE.COMMONS:
*Code to populate the value for security number
CALL ALLOCATE.UNIQUE.TIME(RESULT.TIME)
Y.TIME1 = FIELDS(RESULT.TIME,'.',1,1)
Y.TIME2 = FIELDS(RESULT.TIME,'.',2,1)
Y.TIME = Y.TIME1:Y.TIME2

*Get the value of the year from today's date
Y.YEAR = LEFT(TODAY,4)

*Form the Card number by concatenating year and unique time
Y.CARD.NUMBER = Y.YEAR:Y.TIME
IF R.NEW(DBC.SECURITY.NUMBER) EQ '' THEN
R.NEW(DBC.SECURITY.NUMBER) = Y.CARD.NUMBER
END
* Code to populate the value for End date
Y.END.DAY1 = LEFT(TODAY,4) ;* Get the year portion
Y.END.DAY1 = Y.END.DAY1 + 5 ;* Add five years
Y.END.DAY2 = RIGHT(TODAY,4)
Y.END.DAY = Y.END.DAY1:Y.END.DAY2 ;*Concatenate year, day & month

* Is RESULTING YEAR a leap year? No. How are we going to tell this in our code
* CDT is a T24 subroutine used to CALCULATE DATE, if we specify the *number of
calendar dates, it will give the date after so many *calendar days. So let’s do a
plus 1 day and a minus of one day to *get the actual day

CALL CDT("",Y.END.DAY,"+1C");
CALL CDT("",Y.END.DAY,"-1C")
IF R.NEW(DBC.END.DATE) EQ '' THEN
R.NEW(DBC.END.DATE) = Y.END.DAY
END
Slide 114
.RECORD Method – Debit Card Example – EB.DEBIT.CARD
 Fields are defaulted when a new record is opened
Slide 115
Error Messages
 Errors are generated before overrides
 Errors are generated when data is validated
 Code to raise errors can be written in the .VALIDATE method
 We use the common variable E to store error messages that must be displayed
or an ID to an existing record in EB.ERROR
 ERR is the core subroutine to display error messages
 When raising an error in for an ID in the .ID method, all we have to do is set
the error code or error message in the common variable E
 We do not have to call ERR as T24 calls it in THE.TEMPLATE
 If called, the error message is displayed after the record is opened
Slide 116
.VALIDATE Method – Debit Card Example – EB.DEBIT.CARD
 To access the data that is being input we will have to use

 R.NEW in our .VALIDATE method
VALIDATE:
* TODO - Add the validation code here.
* Set AF, AV and AS to the field, multi value and sub value and
* invoke STORE.END.ERROR
* Set ETEXT to point to the EB.ERROR.TABLE
*Validation for customer's valid account

Y.CUSTOMER = R.NEW(DBC.CUSTOMER)
Y.ACCOUNT = R.NEW(DBC.ACCOUNT)
CALL F.READ(FN.ACC,Y.ACCOUNT,R.ACCOUNT,F.ACC,CUS.ERR)
CUS.ID = R.ACCOUNT<AC.CUSTOMER>
IF Y.CUSTOMER NE CUS.ID THEN
AF = DBC.CUSTOMER ;* Name of the field
ETEXT = 'CUSTOMER ACCOUNT MISMATCH' ;* The error code
CALL STORE.END.ERROR ;* Needs to be invoked per error
END
Slide 117
.VALIDATE Method – Debit Card Example – EB.DEBIT.CARD
 Error Message displayed
Slide 118
Workshop
 Perform validations relating to – refer Tech Spec (all applications)

 .RECORD method
 .VALIDATE method
Slide 119
.AUTHORISE Method – Debit Card Example – EB.DEBIT.CARD
PROCESS:
CALL EB.DEBIT.CARD.TRANS.ACCOUNTING

Y.DATE = R.NEW(DBT.VALUE.DATE)
Y.CARD.NUM = R.NEW(DBT.CARD.NUMBER)
CALL F.READ(FN.DBC,Y.CARD.NUM,R.DBC,F.DBC,DBC.ERR)
Y.CUS = R.DBC<DBC.CUSTOMER>
Y.ACC = R.DBC<DBC.ACCOUNT>
Y.ATM.ID = Y.CUS:'-':Y.ACC:'-':Y.DATE

IF R.NEW(DBT.WITHDRAW.SWIPE) = 'W' THEN
CALL F.READ(FN.DCP,DCP.ID,R.DCP,F.DCP,DCP.ERR)
IF DCP.ERR EQ '' THEN
Y.MAX.AMT = R.DCP<DCP.MAX.WD.AMT>
END
CALL F.READ(FN.ATM,Y.ATM.ID,R.ATM,F.ATM,ATM.ERR)
IF R.ATM EQ '' THEN
Y.DRAWN.AMT = 0
END ELSE
Y.DRAWN.AMT = R.ATM<ATM.AMOUNT.UTILISED>
END
Y.AMOUNT = R.NEW(DBT.AMOUNT) + Y.DRAWN.AMT

IF Y.AMOUNT GT Y.MAX.AMT THEN
AF = DBT.AMOUNT
ETEXT = 'AMOUNT EXCEEDS MAX WITHDRAWAL AMOUNT'
CALL STORE.END.ERROR
END ELSE
CALL F.WRITE(FN.ATM,Y.ATM.ID,Y.AMOUNT)
END
END
Slide 120
.AUTHORISE Method – Debit Card Example – EB.DEBIT.CARD
 Live file updated, accounting entries raised
Slide 121
Workshop
 Refer to the Tech Spec and create

 .AUTHORISE method
for the applications that require it
Slide 122
Day 6 & 7
 Version Hooks
 Workshops
Slide 123
Version Routines
Version Routines
Slide 124
Version User Exits
 Extra functionality (Client customization) can be added via Version

Routines
 Validation Routines
 Input Routines
 Authorisation Routines
 ID Routine
 Check Record Routine
 After UNAU Routine
 Before AUTH Routine
Slide 125
What Are HOT.FIELDs?
 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.
 Use the ATTRIBS in the VERSION application should set the “HOT.FIELD”
property for a field.
 This is to signify that validation should be performed when this field is exited
(Tab or Enter key)
Slide 126
Validation Routine
 These routines, as the name implies validate data entered in a particular

field
 It can also be used to default values into fields
 It must be specified in the field VALIDATION.FLD in the Version Application.
 These routines get invoked after a user presses the ‘TAB’ key or the ‘Enter’
key.
 These routines get invoked when a record is committed as well.
 To trigger these routines at the field level, the set the field ATTRIBS to
‘HOT.FIELD’
Slide 127
Validation Routine - Task
Create a version for the Funds Transfer application with the

following fields.

 Transaction Type
 Debit Account Number
 Debit Currency
 Debit Amount
 Debit Value Date
 Credit Account Number
 Credit Currency
Once the Debit Account Number is entered the appropriate

currency has to get defaulted in the Currency field.
Make the Currency field a NOINPUT field.
Slide 128
Validation Routine - Solution
 Step 1
 Create the version with the necessary fields and set the field ATTRIBS to
HOT.FIELD for ‘DEBIT.ACCT.NO’. Only part of the version is displayed here
Slide 129
 Step 2
 Write a subroutine that will fetch the currency of the account entered in the
field DEBIT.ACCT.NO
 Ensure that this routine does not get triggered when the record is
committed. You know that all validation routines, by default, get triggered
when the record is committed as well
Slide 130
 Step 2 (Cont.)
 Some important common variables that you need to know to write the routine
 COMI
Holds the last input value in a record
Defined in I_COMMON
Dynamic array
Value flushed when the record is exited/committed/authorised
 MESSAGE
Defined in I_COMMON
Holds any one of the following values depending on the function used
VAL (Function Input)
AUT (Function Authorize)
HLD (Record placed on Hold)
Slide 131
 Step 2 (Cont.) Algorithm
 Check the value of MESSAGE and ensure that the record is still open
(Ensure that the record is not committed by the user)
 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
Slide 132
SUBROUTINE V.TRG.VAL.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.ACCOUNT
$INSERT I_F.FUNDS.TRANSFER
IF V$FUNCTION EQ ‘I’ 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.CUR = R.ACCT.REC<AC.CURRENCY>
R.NEW(FT.DEBIT.CURRENCY)=Y.ACCT.CUR ; *Place the extracted value in R.NEW
CALL REBUILD.SCREEN ; To refresh the screen with the new value
END
RETURN
END
Slide 133
 Compile and catalogue the subroutine and attach this routine.

 Make an entry in EB.API for version routines
 Set PROTECTION.LEVEL to NONE
 Set SOURCE.TYPE to BASIC
 Attach the routine to the field DEBIT.ACCT.NO in the version
 Currency defaults as required in the FT Application
Slide 134
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
Slide 135
Input Routine - Task
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 Account currency mismatch” has to be
displayed.
Fields that need to be displayed as part of the version

1. Transaction Type
2. Debit Account Number
3. Debit Currency
4. Debit Amount
5. Debit Value Date
6. Credit Account Number
7. Credit Currency
Slide 136
Input Routine - Solution
 Step 1
 Create a version for the FT application with the necessary fields
 Step 2
 Write a subroutine that will
Check if the record is not put on hold and only then proceed
Extract the debit and credit account currencies
Compare the values
Throw an error message if the values are unequal
Slide 137
Input Routine – Points To Remember
 When the Input Routine is invoked, COMI will not be available

 Extract necessary information from R.NEW
 Use ETEXT and STORE.END.ERROR to display error messages
 STORE.END.ERROR
This is a T24 subroutine that is capable of displaying an error message
stored in a common variable ETEXT.
 ETEXT
• The variable ETEXT always needs to be populated with the error
message before STORE.END.ERROR is invoked
• Defined in I_COMMON
ETEXT = “Error Message”

Slide 138
Input Routine – Points To Remember
 By default, STORE.END.ERROR will display the error message in the left

top corner of the screen.
 Use the following variables to display the error message next to a field
 AF - Holds the field position
 AV - Holds the multi vale position
 AS - Holds the sub value position
AF = 1
AV = 1
AS = 1
ETEXT = “Error”
 The above will cause the error message to be displayed adjacent to the field
‘1.1.1’.
Slide 139
*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
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
AF = FT.DEBIT.CURRENCY ; * Use field name instead of field number
ETEXT = “Credit Acct Ccy Not Equal To Debit Acc Ccy”
END
END
RETURN
END
Slide 140
 Step 3
 Compile and catalog the routine
 Create EB.API record for the routine
 Attach the routine to the field ‘Input Routine’ in the Version application
Slide 141
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 before a write is made to the buffer meaning that
changes made to R.NEW will reflect in the record even without a WRITE
being made explicitly.
In this case, even a call to JOURNAL.UPDATE is not required as this is taken care of by
T24 core when the authorised record is written to the database
Slide 142
Authorization Routine - Task
 Once a record in a version of the FUNDS.TRANSFER application is

authorised, the following details from the transaction need to be extracted
and written on to a flat file named TEMENOS.TRG.FT.INTERFACE for
interface purposes.
 ID of the record in the flat file needs to be the FT id

 Following field’s values need to be stored in the flat file all delimited with a single
space
• Debit Account Number
• Credit Account Number
• Value Date
• Debit Amount
• Debit Currency
Slide 143
Authorization Routine - Solution
 Step 1
 Create a version for the FUNDS.TRANSFER application with all
the following fields
Transaction Type
Debit Account Number
Debit Currency
Debit Amount
Debit Value Date
Credit Account Number
Credit Currency
Slide 144
 Step 2
 Create the flat file under the HOME directory if it does not exist
CREATE.FILE TEMENOS.TRG.FT.INTERFACE TYPE=UD
Slide 145
 Step 3
 Write a routine that will extract the following values from the FT record and
write to the flat file
FT Id
Debit Account Number
Credit Account Number
Value Date
Debit Amount
Debit Currency
Slide 146
SUBROUTINE V.TRG.AUTH.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
Y.FILE.NAME = "TEMENOS.TRG.FT.INTERFACE"
Y.FILE.ID = ID.NEW
OPENSEQ Y.FILE.NAME,Y.FILE.ID TO Y.FILE.PTR ELSE
CREATE Y.FILE.PTR ELSE
CRT "Unable to create record in file"
END
END
Y.STRING.TO.BE.WRITTEN = R.NEW(FT.DEBIT.ACCT.NO):" ":R.NEW(FT.DEBIT.CURRENCY)
Y.STRING.TO.BE.WRITTEN := " ": R.NEW(FT.CREDIT.ACCT.NO):"
":R.NEW(FT.DEBIT.VALUE.DATE)
Y.STRING.TO.BE.WRITTEN := " ":R.NEW(FT.DEBIT.AMOUNT):" ":R.NEW(FT.DEBIT.CURRENCY)
WRITESEQ Y.STRING.TO.BE.WRITTEN TO Y.FILE.PTR ELSE
CRT "Unable to write to the file"
END
RETURN
END
Slide 147
 Step 4
 Compile and catalog the routine
 Create EB.API record for the routine
 Attach the routine to the field ‘Auth Routine’ in the version
 Input a record and authorize a record using the FT version
 Check the flat file once the record is authorised
Slide 148
ID Routines
 Attached to ID.RTN field in VERSION
 Used for special processing or validation of ID entered
 Called by RECORDID.INPUT (THE.TEMPLATE)
 Invoked before ID.NEW gets initalised
 Uses COMI
 Requires EB.API Entry
Slide 149
ID Routines
Example:
 Write a routine that will prefix any enquiry ID with the string ‘TEM.TRG’
when the record is created / opened to denote that it was created /
amended as a part of the Temenos Training program. This should not
happen for ids of enquiries that begin with a ‘%’ or a Enquiry-LIST.
Slide 150
ID Routines
Solution
SUBROUTINE V.TRG.CHECK.ID.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.ENQUIRY
IF APPLICATION NE 'ENQUIRY' THEN RETURN
IF COMI THEN ;* ID.NEW would not have been set now
IF COMI[1,1] NE '%' AND FIELD(COMI,'-',2)[1,4] NE 'LIST' THEN
COMI = 'TEM.TRG.':COMI
END
END
RETURN
END
Slide 151
CHECK.RECORD Routine
 Called from RECORD.READ (THE.TEMPLATE)
 Similar to the .RECORD method
 R.NEW, R.NEW.LAST and R.OLD available for manipulation
 Requires EB.API entry
Slide 152
Example
 Write a subroutine that will restrict any user trying to open a Live
Customer Record which was not input and authorized by him and will
display an error message “Access Restricted”.
Slide 153
Solution
SUBROUTINE V.TRG.CHECK.REC.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
IF NOT(R.NEW(EB.CUS.INPUTTER)) THEN RETURN ;* Could be a new record
IF R.NEW(EB.CUS.RECORD.STATUS) THEN RETURN ;* Could be an unauth record
THIS.OPERATOR.OK = 0
INPUTTERS = R.NEW(EB.CUS.INPUTTER)
NO.OF.INPUTTERS = DCOUNT(INPUTTERS,@VM)
IF NO.OF.INPUTTERS = 1 THEN
IF FIELD(INPUTTERS,'_',2) = OPERATOR THEN THIS.OPERATOR.OK = 1
END ELSE
LOOP
REMOVE INPUTTER FROM INPUTTERS SETTING MORE.INPUTTERS
WHILE INPUTTER : MORE.INPUTTERS
INPUT.OPERATOR = FIELD(INPUTTER,'_',2)
IF INPUT.OPERATOR EQ OPERATOR THEN
THIS.OPERATOR.OK = 1
INPUTTERS = '‘
END
Slide 154
Solution
REPEAT
END
* He wasn’t one of the Inputters
IF NOT(THIS.OPERATOR.OK) THEN
AUTHORISER = R.NEW(EB.CUS.AUTHORISER)
* He was’nt the authoriser
IF FIELD(AUTHORISER,'_',2) NE OPERATOR THEN
E = 'Access Restricted'
CALL ERR
V$ERROR = 1
END
 Note: The INPUTTER audit field( though a Multivalue field) only holds the last
INPUTTER(if multiple inputters have edited the record). To hold the id's of all the
INPUTTERS in multi valued positions, set the field, DATE.TIME.MV in SPF
application to YES.
 V$ERROR is used to set the error variable.
Slide 155
AFTER UNAU Routine
 Called from UNAUTH.RECORD.WRITE
 Called after R.NEW is flushed to disk
 Changes to R.NEW not encouraged
Slide 156
BEFORE AUTH Routine
 Called by AUTH.RECORD.WRITE
 Changes to R.NEW not encouraged, since data is already validated
 Executed before R.NEW is flushed to disk
 Updating R.NEW at user’s risk
Slide 157
BEFORE AUTH Routine
Example
 There is a requirement where in, there is a local reference field that is

attached to the version and this field has to be populated with the total
number of accounts for a particular customer, whenever the user
authorizes a customer record for that particular customer
Slide 158
BEFORE AUTH Routine
Solution
SUBROUTINE BEFORE.AUTH.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.ACCOUNT

F.CUS.ACC = ''
FN.CUS.ACC = 'F.CUSTOMER.ACCOUNT'
CALL OPF(FN.CUS.ACC,F.CUS.ACC)

Y.CUSTOMER.ID = ''
R.CUS.ACC = ''
Y.ERR = ''
*Check the version that is being opened
IF APPLICATION = 'ACCOUNT' AND PGM.VERSION = ',OPEN' AND V$FUNCTION =
'A' THEN

*Retrieve the customer id
Y.CUSTOMER.ID = R.NEW(AC.CUSTOMER)

*Read the FBNK.CUSTOMER.ACCOUNT file to retrieve the account records
CALL F.READ(FN.CUS.ACC,Y.CUSTOMER.ID,R.CUS.ACC,F.CUS.ACC,Y.ERR)
IF Y.ERR = '' THEN
NO.OF.ACC = DCOUNT(R.CUS.ACC,@FM)
END
CRT "No.of.Accounts for " :Y.CUSTOMER.ID : "is" : NO.OF.ACC
END
RETURN
END
Slide 159
Workshop
 Put a DEBUG statement in all the routines and methods and test which
routine is called before or after which TEMPLATE method to
understand the flow of THE.TEMPLATE
 NOTE: Use the EB.DEBIT.CARD application and test using the version
of EB.DEBIT.CARD used earlier. Make sure there is an EB.API entry
for all the version routines.
Slide 160
Workshop – Validation routines
1. Write a validation routine for a version of EB.DEBIT.CARD, the

CUSTOMER.NO should get populated when we tab out of the
ACCOUNT NO field.
(Hint: Make ACCOUNT.NO a ‘HOT.FIELD’, and attach the validation
routine to this field)
2. Write an Input Routine for a version of EB.DEBIT.CARD to check if the

END.DATE is a working day, If not raise an error.
Slide 161
Workshop – Validation routines
3. When an USER authorizes a record using the version for

EB.DEBIT.CARD, a “debitcard.csv” file should be created in your local
BP directory (for e.g. DEBIT.CARD.BP) with the following details.
 CARD.NO
 CUSTOMER NAME
 CUSTOMER ID
 START DATE
 END DATE
 ACCOUNT NO
 CARD TYPE
 CARD DESCRIPTION
Every time a new card is created, the details in this .CSV file should be
appended and NOT overwritten.
Slide 162
Day 8
 Overrides
 Workshop
Slide 163
Overrides
Overrides
Slide 164
Overrides Messages
 Generating overrides or errors at appropriate places increases the user

friendliness of an application
 .OVERRIDES method available to raise override messages. It is

executed after the data is validated but before it is return to the $NAU file
 OVERRIDE Application used to define override messages
 TEXT - common variable to store the ID of the OVERRIDE record or the

actual text to be displayed
 STORE.OVERRIDE is the core subroutine called to raise the override
 Overrides, if accepted are stored in the no input OVERRIDES field in an

application
Slide 165
Overrides And Error Messages
 Overrides can be static in nature or dynamic (containing values from

the transaction)
 Values if any, must be passed in the TEXT variable itself before the call
to STORE.OVERRIDE
 TEXT = ‘OVERRIDE.ID’:FM:VALUE1:VM:VALUE2 etc…
Slide 166
.OVERRIDES Method – Debit Card Example – EB.DEBIT.CARD
OVERRIDES:
* TODO Add your override here
* Set TEXT to be the key to the override you want to use form the OVERRIDE
table
* Set AF/AV/AS to be the field that is relevant to the override.
*
IF R.NEW(DBC.CARD.TYPE) NE Y.CARD.TYPE THEN

AF = DBC.CARD.TYPE
TEXT = "CARD.ELIGIBLE"
GOSUB DO.OVERRIDE
END
DO.OVERRIDE:
CALL STORE.OVERRIDE(CURR.NO)
IF TEXT = 'NO' THEN
GOTO EXIT.SUB
END
RETURN
Note: CARD.ELIGIBLE is a record in OVERRIDE application. Before calling the core

subroutine STORE.OVERRIDE for the first time, this code must be executed. These
statements initialise the override field in the application and clear existing overrides if
present. CURR.NO is then incremented by 1 in the STORE.OVERRIDE subroutine so that
subsequent overrides are stored in the field and it is multi valued as required to store as
many overrides as required.
Slide 167
.OVERRIDES Method – Debit Card Example – EB.DEBIT.CARD
 When the Card Type is changed for an existing record…
Slide 168
Day 9 & 10
 Accounting
 XX.ACCOUNTING
 Workshop
Slide 169
Accounting
Accounting
Slide 170
Accounting files in T24
 STMT.ENTRY
 CATEG.ENTRY
 RE.CONSOL.SPEC.ENTRY
Slide 171
STMT.ENTRY
 Account related entries are raised ONLINE and OFFLINE for all
movements in the customer and internal accounts.
 All entries in the CATEGORY range 1-19999 are held in this file.
Slide 172
STMT.ENTRY
 In addition to STMT.ENTRY record, an entry is also generated in the

ACCOUNT.ENT.TODAY file
 ACCT.ENT.TODAY holds reference to transactions carried out since the

last COB and is cleared in the Start Of day processing. Similarly
ACCT.ENT.FWD holds reference to the forwarded dates transactions
 When the file is cleared during COB the contents is copied to a file by
name ACCT.ENT.LWORK.DAY file
 In the file ACCT.ACTIVITY, the actual account balance and other

related information for accounts are build using the ACCT.ENT.TODAY
file
Slide 173
CATEG.ENTRY
 Profit and Loss entries are raised ON-LINE and OFF-LINE and are kept
in the CATEG.ENTRY file.
 All entries hitting the Category codes over 50000 are held in this file.
Slide 174
CATEG.ENTRY
 In addition to CATEG.ENTRY record, an entry is also generated in the

CATEG.ENT.TODAY file.
 CATEG.ENT.TODAY holds reference to transactions carried out since the

last COB and is cleared in the Start Of day processing. Similarly
CATEG.ENT.FWD holds reference to the forwarded dates transactions
 When the file is cleared during COB the contents is copied to a file by name
CATEG.ENT.LWORK.DAY file
Slide 175
RE.CONSOL.SPEC.ENTRY
 The RE.CONSOL.SPEC.ENTRY file is updated only during COB.

Online spec entries are not raised
 Input of a fresh contract gives raise to a CONSOL.ENT.TODAY record,

which is converted to spec Entry during Close of Business
 The CONSOL.ENT.TODAY records are converted to SPEC entries in

EOD.CONSOL.UPDATE in SYSTEM.END.OF.DAY5 and are cleared in
FILE.TIDY.UP during Start Of day processing. Similarly
CONSOL.ENT.FWD holds reference to the forwarded dates
transactions
 When the file is cleared during COB the contents are copied to a file by
name CONSOL.ENT.LWORK.DAY file
Slide 176
Accounting in T24
 When a record in any application is committed, the accounting entries

are raised and are stored in the ENTRY.HOLD directory.
 Once the record is authorized, the entries are then transferred from
ENTRY.HOLD directory to the appropriate accounting files.
 Any processing that has to happen before a record goes to INAU status
has to be done in the .PROCESS method
 Any processing that has to be done before a record is authorized has to

be done in the .AUTHORISE method
Slide 177
XX.ACCOUNTING Subroutine
INITIALISATION
PRODUCE.ENTRIES
RAISE.AC.ENTRY RAISE.CATEG.ENTRY RAISE.CRF.ENTRY
BUILD.BASE.ENTRY BUILD.BASE.ENTRY BUILD.BASE.ENTRY
APPEND.ENTRIES APPEND.LIVE.ENTRIES APPEND.ENTRIES
APPEND.LIVE.ENTRIES APPEND.LIVE.ENTRIES
APPEND.FORWARD.ENTRIES
APPEND..FORWARD.ENTRIES
MULTI.ENTRIES
Slide 178
Sample Code from XX.ACCOUNTING
 Building Entries
 I_file of STMT.ENTRY or CATEG.ENTRY could be used since name

only represents a position in the array called ENTRY
ENTRY<AC.STE.COMPANY.CODE> = ID.COMPANY
ENTRY<AC.STE.TRANSACTION.CODE> = ''
ENTRY<AC.STE.THEIR.REFERENCE> = ID.NEW
ENTRY<AC.STE.VALUE.DATE> = VALUE.DATE
ENTRY<AC.STE.CURRENCY> = LCCY ;* Set a value here
ENTRY<AC.STE.POSITION.TYPE> = 'TR'
ENTRY<AC.STE.OUR.REFERENCE> = ID.NEW
ENTRY<AC.STE.CURRENCY.MARKET> = '1'
ENTRY<AC.STE.DEPARTMENT.CODE> = R.USER<EB.USE.DEPT.CODE>
ENTRY<AC.STE.SYSTEM.ID> = "AC"
ENTRY<AC.STE.BOOKING.DATE> = TODAY
Slide 179
EB.ACCOUNTING Subroutine
 EB.ACCOUNTING is the core routine that will actually raise the entries
 It is called from within XX.ACCOUNTING available in GLOBUS.BP
 Has 4 parameters
 Application Name
 Type of Accounting
 Entry Details
 Forward Entry Flag
 EB.ACCOUNTING can raise more than one entry at a time with just
one call to it
Slide 180
EB.ACCOUNTING Parameters
 1st parameter – Application name / Product name
 2nd parameter – Type of Accounting

 VAL
 AUT
 CHG
 DEL
 REV
 SAO
 RSAO
 SNP
 3rd parameter – Array containing entries, separated by FM
 4th parameter – Variable that can contain 1 or 0 or “CONSOL” to raise

CRF entries
Slide 181
Important Note
 DO NOT GOSUB PRODUCE.ENTRIES when the function is A, R or D
 When we call EB.ACCOUNTING with AUT, all that we need to do is

select the correct entries from ENTRY.HOLD and move it to
STMT.ENTRY / CATEG.ENTRY
 Since the entries are already available, we do not have to populate the
MULTI.ENTRIES variable again
 This holds good when we use Reverse or Delete functions as well
Slide 182
Take a look at XX.ACCOUNTING
 Understand the different paragraphs and need for checking

V$FUNCTION before proceeding with processing
 Discuss under which circumstances must we pass values in ENTRY

array to EB.ACCOUNTING
Slide 183
Code for Accounting
 Accounting subroutine must be called in the .PROCESS as well

as .AUTHORISE method
 ID of ENTRY.HOLD is ID.NEW and hence when we call

EB.ACCOUNTING in the .AUTHORISE method, we don’t have to
populate ENTRY array again
Slide 184
XX.ACCOUNTING Subroutine
 The core routine that actually raises accounting entries is

EB.ACCOUNTING
 Refer to the EB.DEBIT.CARD.ACCOUNTING subroutine to understand

the entries raised by the Debit Card example we are discussing
 STMT.NOS is the no input field that gets updated with accounting entry
ids
Slide 185
Accounting in the Debit Card Example
 Accounting entries must be raised

 Accounting Entries
 Accounting entries must be raised when
 A customer withdraws from the ATM or swipes his card (POS)
If it is an ATM withdrawal
• STMT Entry – Debit the customer account
• STMT Entry – Credit the ATM account (internal)
If it is a POS swipe
• STMT Entry – Debit the customer account
• STMT Entry – Credit the Vostro account
 Use enquiries NAU.ENTRY and STMT.ENT.TODAY to view entries

raised
Slide 186
EB.CONTRACT.BALANCES
 The reporting ('CRB') consolidation module maintains the 'CENTRAL

REPORTING BASE' from which financial reports (such as General
Ledger, Balance Sheet, Statement of conditions, Foreign Currency
Control Ledger, Central Bank reports etc.) are produced.
 The EB.CONTRACT.BALANCES file provides a single place for CRB

reporting to take its information.
 It is possible to extract the balance at the close of the last working day
as well as the current balance.
 Balances are updated real-time at the authorization stage of a

transaction. For certain balance types unauthorized movements are
held too.
Slide 187
EB.CONTRACT.BALANCES
 The balances are updated from the core accounting processing based on
the Consol entries raised by the underlying application – there is no direct
update from the underlying application.
 The following applications currently update EB.CONTRACT.BALANCES

 ACCOUNT
 ASSET & LIABILITY (AL)
 MM.MONEY.MARKET
 LD.LOANS.AND.DEPOSIT
 PD.PAST.DUE
 SC.TRADING.POSITION
 MG.MORTGAGE
 MD.DEAL
 SL.LOAN
 FOREX
 LIMIT
Slide 188
Workshop
 Raise accounting entries as per the requirement for the DEBIT CARD
example
Slide 189
Day 11 & 12
 DAS
 Multi threading
 Workshop
 Run as COB / Service
Slide 190
DAS
DAS – Data Access Service
Slide 191
DAS
 SELECT statements are a part of almost every subroutine in T24
 SELECT statements not written efficiently is the killer when it comes to

the performance of any system
 If we needed data from the database, we would write an appropriate

SELECT statement and use the core subroutine EB.READLIST to
execute it
 DAS is now the standard that must be followed when writing queries for
an application
Slide 192
DAS
 Data Access Service
 Single frame work for queries
 No requirement to write jQL or any other query language
 The subroutine EB.QUERY.BUILDER which is the heart of DAS

generates the jQL or the SQL query depending on the database we are
using
 May be created by EB.DEV.HELPER if required
Slide 193
Components of DAS
 If the application we are creating uses SELECT(s), we first have to

decide the list of queries that we want to allow
 We obviously can’t think of every possible combination, so it’s best to

build the list as we along
 In DAS each query defined has 2 parts – the user defined name for the
query and its description
 DAS components for each application

 I_DAS.APPLICATION – Names for queries to be used in application
 I_DAS.APPLICATION.NOTES – Description for each query defined above
 DAS.APPLICATION – Routine to describe each query
Slide 194
I_DAS.APPLICATION
 Must list down all possible query option to be allowed for the application
 Each query must be given a meaningful name
 No need for any jQL yet
 Name must be equated to a number
 Naming convention must be DAS.<APPNAME>$<QUERYNAME>
EQU DAS.EB.DEBIT.CARD$CUSTOMER.CARD TO 1
EQU DAS.EB.DEBIT.CARD$CARD.VALIDITY TO 2
Slide 195
I_DAS.APPLICATION.NOTES
 This must contain an explanation for each of the queries used
 Notes must be stored in a variable called DAS$NOTES
 No actual query definition yet
COMMON/DAS.APPLICATION/DAS$CACHE(100),DAS$NOTES(100)
DAS$NOTES(DAS.EB.DEBIT.CARD$CUSTOMER.CARD) = 'List of cards per customer'

DAS$NOTES(DAS.EB.DEBIT.CARD$CARD.VALIDITY) = 'Cards expiring before a date'
Slide 196
DAS.APPLICATION
 Definition of all queries take place here
 Queries are broken up into

 Fields
 Operands
 Sorts
 Joins
 For example, lets assume we need to define the two queries below
SELECT FBNK.EB.DEBIT.CARD WITH CUSTOMER EQ ‘10001
SELECT FBNK.EB.DEBIT.CARD WITH START.DATE EQ TODAY AND END.DATE LT

20200101
Slide 197
Defining the Queries
SUBROUTINE DAS.EB.DEBIT.CARD(THE.LIST,THE.ARGS,TABLE.SUFFIX)
$INSERT I_DAS.EB.DEBIT.CARD
$INSERT I_DAS.EB.DEBIT.CARD.NOTES
$INSERT I_DAS
BUILD.DATA:
MY.TABLE = <EB.DEBIT.CARD>:TABLE.SUFFIX
BEGIN CASE
CASE MY.CMD = DAS.EB.DEBIT.CARD$CUSTOMER.CARD
MY.FIELDS = ‘CUSTOMER’
MY.OPERANDS = ‘EQ’
MY.DATA = THE.ARGS
CASE MY.CMD = DAS.EB.DEBIT.CARD$CARD.VALIDITY
MY.FIELDS = ‘START.DATE’
MY.OPERANDS = ‘EQ’
MY.DATA = THE.ARGS<1> ;* Can use TODAY here too
MY.JOINS = ‘AND’
MY.FIELDS<-1> = ‘END.DATE’
MY.OPERANDS<-1> = ‘LT’
MY.DATA<-1> = THE.ARGS<2>
END CASE
RETURN
Note: MY.TABLE, MY.FIELDS, MY.OPERANDS, MY.DATA, MY.JOINS are variable names that cannot be
changed. The paragraph name has to be BUILD.DATA. The ordering of insert files in the above code is very
important.
Slide 198
DAS
 Core DAS Components

 I_DAS – Insert file with code to execute and cache query results
 I_DAS.COMMON – Insert file with DAS common variables
 DAS – Subroutine that is an equivalent of EB.READLIST. Called when
execute of a query is needed
 Calling DAS is similar to EB.READLIST
CALL DAS(‘ApplicationName’, QUERYNAME, LIST, TABLE.SUFFIX)
 DAS$CACHE – Common variable used to cache query results
 Advantages
 Caching
 Database specific query formation
 Predefined selects for an application
Slide 199
DAS
<ANY ROUTINE WHERE SELECT MUST BE EXECUTED>

$INSERT I_DAS.EB.DEBIT.CARD
THE.LIST = DAS.EB.DEBIT.CARD$CUSTOMER.CARD
THE.ARGS = ‘10001’
TABLE.SUFF = ‘’ ;* Must mention $NAU or $HIS if required
CALL DAS(‘EB.DEBIT.CARD’,THE.LIST,THE.ARGS,TABLE.SUFF)
 DAS is the core subroutine which internally invokes the subroutine of

the form DAS.<APPLICATION>
 This routine would not usually be called by code outside of a CALL DAS
Slide 200
More information
 DAS subroutine also invokes EB.UPDATE.DAS.RESULTS which

updates a live file called DAS.RESULTS with the Table name, No of
records selected, Query name and the LIST returned.
 dasMode is a COMMON variable defined in I_DAS.COMMON
 The results in DAS.RESULTS file will be used if

dasMode = dasReturnResults
 The query string that DAS builds, can be returned by setting

dasMode=dasReturnDescription and the select statement is returned,
along with the description
Slide 201
Workshop
 Write a multi threaded routine to select

 All debit cards from the debit card master application
 All debit cards of a particular card type
 All debit cards that belong to a particular customer
 All debit cards that expire on a particular date
using DAS.
Slide 202
Day 13, 14 & 15
 Extra Information
 Templates in R5
 Workshop
 Comparison between R5, R7 and R9 templates
Slide 203
Important Tidbits
Important Tidbits
Slide 204
HOOK Routines
 In some applications, we require a valid subroutine to be input as data

in certain fields
 Versions
 Enquiries
 How does T24 check is the data entered is in fact a valid routine name?
 T(FieldPosition) = ‘HOOK’
 Calls IN2HOOK to validate subroutine name entered
 Looks for an EB.API record for the data entered hence validating it
 Code to call the routine when required must be added by us at

application level
Slide 205
Transaction Boundaries in T24
 Transaction Boundaries ensure total updates or no updates at all
 Core subroutine EB.TRANS called to start / end / abort the boundary
 Transaction Blocks are handles in 2 ways depending on the requests

 Bulk OFS requests
 Non Bulk OFS requests
 At application level, there are transaction boundaries in

UNAUTH.RECORD.WRITE and in AUTH.RECORD.WRITE
Slide 206
Non Bulk OFS Requests
Slide 207
Bulk OFS Requests
Slide 208
F.READ Vs CACHE.READ
 F.READ
 First checks if requested record is in the cache (FWC, FWT, FWF)
 Else reads from disk and loads into cache
 Subsequent reads within subroutine execution is only from cache
 Cache cleared after process termination
 CACHE.READ
 Checks if record is in cache (STATIC.INDEX, STATIC.DETAILS,
STATIC.DATA)
 Else reads from disk and loads into cache
 This cache is session specific
 Records that rarely change can be accessed using this – SPF, COMPANY
 DON’T use this to read from ACCOUNT, CUSTOMER etc
Slide 209
Backward Compatibility
 Before R9, Older TEMPLATE used C_PROPERTIES array to define

the properties
 C_PROPERTIES is a common variable defined in

 If properties are defined using the old TEMPLATE, THE.TEMPLATE

invokes a subroutine called TableUtil.fromMethods
 This subroutine populates the Table objects from C_PROPERTIES

array
 This is essentially used for backward compatibility
Slide 210
THE.TEMPLATE
Slide 211
Other Subroutines Used in THE.TEMPLATE
 MATRIX.UPDATE
 MATRIX.ALTER
 FIELD.DISPLAY / FIELD.MULTI.DISPLAY
 FIELD.INPUT / FIELD.MULTI.INPUT
Slide 212
Interesting Core Subroutines Used So Far
 CDD
 CDT
 DUP
 EB.CALL.API
Slide 213
Older Templates
Templates in older versions of T24 (R5)
Slide 214
Template Programming in R5 and lower
 No THE.TEMPLATE
 Different TEMPLATE subroutine available depending on the type of

application
 U, H – Copy the TEMPLATE subroutine from GLOBUS.BP
 L – Copy the TEMPLATE.L subroutine from GLOBUS.BP
 T – Copy the TEMPLATE.T subroutine from GLOBUS.BP
 W – Copy the TEMPLATE.W subroutine from GLOBUS.BP
 No properties and methods concept. Only paragraphs or calls to other

routines
 No EB.DEV.HELPER to create other components, all done manually using

 FILE.LAYOUT – To create the I_ file at the jBASE prompt
 PGM.FILE and FILE.CONTROL to create the respective records
 CREATE.FILES at the Awaiting Application prompt
 STANDARD.SELECTION – to rebuild the SS record of an application
Slide 215
The TEMPLATE in R5
 The flow of an application built into the subroutine
 Changes for different types of applications incorporated into different

TEMPLATE subroutines
 Code to be written in corresponding paragraphs or individual

subroutines and called when required
 No naming convention for these subroutines
 Validations executed as and when required, unlike when using the

browser
Slide 216
CHECK.FUNCTION
 This is executed as soon as the function is entered
 Prohibit certain functions for a particular application
 Perform special checks if such functions are attempted.
 This is now the .FUNCTION method
Example :
IF INDEX(‘VH’,V$FUNCTION,1) THEN
E = ‘FUNCTION NOT ALLOWED FOR THIS APPLICATION’
CALL ERR
V$FUNCTION = ''
END
Slide 217
CHECK.ID
 Executed as soon as the ID is entered
 Any special editing of the record id should be coded here.
 The value entered will be in ID.NEW.
 If an error is found requiring the id to be re-input, then ERROR must be set

so that T24 will ask for the record ID input again
 Error messages should be displayed using E and ERR.
 This is now the .ID method

Example :
IF (LEN(ID.NEW) > 12) OR NOT(NUM(ID.NEW[8,5])) THEN
E = "INVALID ID"
CALL ERR
V$ERROR = 1
END
Slide 218
CHECK.RECORD
 This is executed before the requested record is displayed to the user
 To perform additional processing / updating when an unauthorised

record is deleted
 This is now the .RECORD method
Slide 219
Major Difference in Validations
There are various stages where validation of data can be done.
 We could validate data as soon as a user types in data in a field and

presses return (Field Level Validation)
 When a user commits a record.
Validation of Data
Field Level Validation Input Level Validation

CHECK.FIELDS CROSSVAL
Slide 220
CHECK.FIELDS
There are 3 types of validations that can be done in check fields.
CHECK.FIELDS
XX.CHECK.FIELDS XX.DEFAULT.FIELDS
DEFAULT.OTHER.FIELDS
Slide 221
Paragraphs in the XX.CHECK.FIELDS Subroutine
 CHECK.FIELDS - Validate the value entered in a field and display error

messages (if any)
 DEFAULT.FIELDS - When data is not entered in a field, and if T24 must

default a value into it, it is done in this paragraph which is executed
when the Enter key or Tab Key is used
 DEFAULT.OTHER.FIELDS – Based on the value entered in a field

(COMI), if other fields need to be defaulted, that code goes here
Slide 222
CHECK.FIELDS
 The third subfield of the ’N’ array should be set to ’C’. This is to enable the
checkfile property.
N(Z) = ’35..C’
 The value input will be in COMI and AF, AV and AS will be set.
 The value entered will NOT have been assigned to R.NEW at this stage.
 This is now the .VALIDATE method
Slide 223
CHECK.DELETE
 To perform additional processing / updating when a record is deleted

(i.e., V$FUNCTION = ‘D’)
Slide 224
CHECK.REVERSAL
 To perform additional processing / updating when an authorised record

is reversed.
Slide 225
Cross Validation
 XX.CROSSVAL is the subroutine that will contain code to be executed

at cross validation
 This section will be performed only when the record has been
committed and FUNCTION is 'I' or 'C'.
 It should be split into three sections with calls to subroutines to process
Field cross validation

Overrides
Additional processing
Slide 226
Cross Validations
 R.NEW, R.OLD, R.NEW.LAST can be used
 Fields in error can be flagged with a corresponding error message by

calling STORE.END.ERROR with AF, AV and AS set
 Check field validations also called again
 In the new way of coding, the .VALIDATE method is called again in

THE.TEMPLATE when a record is committed
Slide 227
XX.OVERRIDE Subroutine or Paragraph
 Subroutine that will contain code to generate overrides
 R.NEW is used to access values in the fields and decide whether an

override must be generated or not
 XX.OVERRIDE must be a multi value field in the application
 Any override messages should be displayed by calling

STORE.OVERRIDE(CURR.NO) setting TEXT to the OVERRIDE record
ID or the text message to be displayed.
 If TEXT is returned as NO, then exit the subroutine immediately.
 The subroutine should initialise the override fields by calling

STORE.OVERRIDE with CURR.NO set to zero at the start of the
subroutine.
 This is now the .OVERRIDE method

Slide 228
Additional Processing
 Invoked after all cross validation checks and overrides.
 To invoke other sub-systems e.g. EB.ACCOUNTING, Delivery etc
 In the new coding standard, this type of processing can be put in

the .PROCESS method or the .AUTHORISE method
Slide 229
BEFORE.UNAUTH.WRITE
 To perform processing which is to be done before the record is written

to the unauthorised file.
 It will be executed when the FUNCTION used is D, R, C or I.
 After performing CHECK.DELETE, CHECK.REVERSAL and

CROSS.VALIDATION.
 To make related updates to other files.
Slide 230
AFTER.UNAUTH.WRITE
 The purpose of this section is similar to that of BEFORE.UNAU.WRITE

except that it will be performed after the write to the unauthorised file
 Not available in the new template programming
Slide 231
BEFORE.AUTH.WRITE
 To do special processing before the live record is written.
 To invoke accounting in authorisation mode and to handle the

authorisation of a reversal.
 To distinguish between the authorisation of Input and the authorisation

of a reversal, the record status must be checked
Example :
BEGIN CASE
CASE RECORD.STATUS[1,3] = "INA"
CALL XX.AUTHORISATION
CASE RECORD.STATUS[1,3] = "RNA"
CALL XX.REVERSAL
END CASE
Slide 232
AFTER.AUTH.WRITE
 Similar to BEFORE.AUTH.WRITE but performed after the write
 This is not available in the new template programming
Slide 233
What was defined where?
 Initialise method was INITIALISE paragraph in the TEMPLATE subroutine

in R5
 Fields method was the DEFINE.FIELDS paragraph in the TEMPLATE

subroutine in R5
 Function method was the CHECK.FUNCTION paragraph in the

TEMPLATE subroutine in R5
 ID method was the CHECK.ID paragraph in the TEMPLATE subroutine in

R5
 Record method was the CHECK.RECORD paragraph in the TEMPLATE

subroutine in R5
 Default method was part of the CHECK.FIELDS subroutine available in

R5
Slide 234
What was defined where?
 Validate method was CHECK.FIELDS paragraph / subroutine in R5
 Preview method was DO.PREVIEW paragraph in the TEMPLATE

subroutine in R5
 Overrides method was the OVERRIDES paragraph in the TEMPLATE

subroutine in R5
 Process method was the BEFORE.UNAUTH.WRITE paragraph in the

 Authorise method was the BEFORE.AUTH.WRITE paragraph in the

 Run method is the same as the $RUN routine in R5
Slide 235
Workshop
 Create the INSURANCE application according to the given specification

using the R5 template
 Perform the specified validations
Slide 236
Comparison of R5, R7 and R9 Templates
Comparison of R5, R7 and R9 Templates
Slide 237
TEMPLATE Subroutine
 In R5
 Both application flow and business logic built into TEMPLATE
 Different TEMPLATE subroutines for different application types
 No properties and methods
 All business functionality defines in paragraphs or call to routines
 No naming conventions for these routines
In R7
 Application flow in THE.TEMPLATE
 Same TEMPLATE subroutine for all types of application
 Business functionality in individual subroutines called methods
 C_PROPERTIES used to define properties
 C_METHODS flag array determines what methods to invoke
 In R9
 Table objects used to define properties
 Any method that exists will automatically be invoked
Slide 238
THE.TEMPLATE Subroutine
 In R5
 No concept of THE.TEMPLATE
 In R7
 THE.TEMPLATE holds execution flow
 .FIELDS method is made mandatory
 Other methods invoked based on C_METHODS flag array
 In R9
 Subroutine modified to be compatible with using Table definitions
 Any method that exists is automatically invoked
Slide 239
 In R5
 This invokes the <Application> Subroutine
 In R7
 This invokes the <Application> Subroutine
 The <Application> Subroutine (a copy of THE.TEMPLATE) in turn invokes
THE.TEMPLATE
 In R9
 This invokes both the <Application> Subroutine and THE.TEMPLATE
Slide 240
Field Definitions
 In R5
 DEFINE.PARAMETERS paragraph in TEMPLATE contains the field
definitions
 ID.F, ID.N, ID.T, F, N and T arrays are directly used to define the fields.
 In R7
 In the .FIELDS method, ID.F, ID.N, ID.T, F, N and T arrays are directly used
to define the fields
 In R9
 In the .FIELDS method, there are a lot of API’s that can be used to define
fields which in turn populate values in the F, N and T arrays
 There are 2 new insert files
• I_Table to define common variables used in Table object
• I_Datatypes which equates basic data types to standard names
Slide 241
Validations
 In R5
 Validations can be done at 2 levels,
• Field level validations – CHECK.FIELDS paragraph
• Input level validations (when user commits the record) – CROSSVAL
paragraph
 In R7
 Validations are written in the .VALIDATE method
• Executed on clicking validate, commit and authorise buttons
 For field level validations, field must be set as HOT.FIELD and code is
written in .VALIDATE method
• Executed on tab out of the field
 In R9
 Same as in R7
Slide 242
Creation of additional components
 In R5
 All components have to be created manually.
• FILE.LAYOUT at the jBASE prompt – to create the I_ file
• PGM.FILE and FILE.CONTROL - to create the respective records
• CREATE.FILES at the Awaiting Application prompt – To create files at
database level
• STANDARD.SELECTION – to rebuild the SS record of an application
 In R7
 EB.DEV.HELPER is a one stop shop to create all the additional components
 In R9
 EB.DEV.HELPER is a one stop shop to create all the additional components
Slide 243
Summary
 The TEMPLATE subroutine from GLOBUS.BP must be copied for every

application we try to create
 THE.TEMPLATE is a subroutine that contains the application flow in

T24. This is used by all applications
 Depending on the properties and methods defined, each application

behaves differently
 Applications in T24 can

 Generate Advices
 Calculate Charges
 Raise Accounting Entries
 Affect Limits
 Have COB processing
Slide 244
You will now be able to …
 Appreciate the way all applications in T24 work
 Create new applications in T24
 Modify functionality of existing ones (if required, otherwise it’s a bug!!)
 Decide which methods to split up the required functionality into
 Explain to others the TEMPLATE and THE.TEMPLATE subroutine in T24
 Be able to decide what properties to set for an application you are about
to create
 Create applications using the older Template in T24
Slide 245
You will now be able to …
 Decide when to use F.READ / CACHE.READ
 Write validations, for an application as well as for a version
 Decide what type of accounting entries will be raised in a given situation
 Write multi threaded routines for COB / Services
 Create additional components of an application and know their

relationship
 To debug issues arising from incorrect code
 Explain to someone else about transaction management in T24
Slide 246
If Not …
 Read the word document titled T24 Template Programming in R9 as the

slides are just a training aid.
Slide 247
Thank You

At The End of The Session You Will Have Adequate Knowledge To Understand

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

At The End of The Session You Will Have Adequate Knowledge To Understand

Uploaded by

Copyright:

Available Formats

Objectives

At the end of the session you will have

 Adequate knowledge to understand

 Adequate knowledge to create

 There are different kinds of applications in T24

 At database level depending on the kind above, there can be

 Applications can be either

 Naming conventions for database files

 FIN – F<MNE>. <APPLICATION>{$<SUFFIX}

 What is an Application in T24?

 What is a Table in T24

 We must decide a name for our application

 What type of application (H, U, L, T, W)

 What classification (CUS, FIN, INT)

 We must decide what functions are going to be permitted

 We must decide fields

 Other related file updates

 What is the business functionality to be built in

1. Enter Application Name

T24 checks if a VALID Application is entered.

2. Enter Function and ID

When data is entered and we hit enter, T24 validates it as a function.

If record does not exist, open new record for user.

4. Enter Data and Commit

Validates data, raises errors or overrides and saves record in database

If everything is OK, save changes in the database, update other applications if

Send advices to customer (if any)

T24 Application Flow

 If we want to develop an application in T24, do we have to start writing

 There are two core subroutines called TEMPLATE and

 That’s why this course is called TEMPLATE PROGRAMMING 

T24 Application Flow

 Most variables used in TEMPLATE programming can be found in

 Application / Product specific common variables also available

 Must include I_ file in all code

 Following common variables need to be understood before we attempt to

 All the above mentioned variables are common variables defined in

 User creates new CUSTOMER record using CUSTOMER I F3

ID.NEW : 123456 ID.NEW.LAST - NOT USED ID.OLD - NOT USED

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 Contains the ID of the currently opened record in any application

 When the record is closed or committed or authorised the value in this

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currently opened record in any application

Definition as seen in I_COMMON : DIM R.NEW(C$SYSDIM)

 User opens INAU record to authorise it

ID.NEW : 123456 ID.NEW.LAST – 123456 ID.OLD – Not Used

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 If an unauthorized record exists for the currently opened record in any

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currently opened record in any application

 ID.NEW.LAST holds the ID of the currently opened record’s unuathorised

Definition as seen in I_COMMON : DIM R.NEW.LAST(C$SYSDIM)

ID.NEW : 123456 ID.NEW.LAST – NOT USED ID.OLD - 123456

R.NEW R.NEW.LAST R.OLD

 Common variable defined in I_COMMON

 If an authorized record exists for the currently opened record in any

 This variable enables us to check programmatically whether the