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 1
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 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
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 14
R.NEW

 Common variable defined in I_COMMON

 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 15
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

R.NEW R.NEW.LAST R.OLD

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 16
ID.NEW.LAST

 Common variable defined in I_COMMON

 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 17
R.NEW.LAST

 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

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)

Where C$SYSDIM = 500

Slide 18
What Happens When An Authorized Record Is Amended?

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

R.NEW R.NEW.LAST R.OLD

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 19
ID.OLD

 Common variable defined in I_COMMON

 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 20
R.OLD

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 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)

Where C$SYSDIM = 500

Slide 21
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

R.NEW R.NEW.LAST R.OLD

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 22
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 23
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 24
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 25
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 26
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 27
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 28
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 29
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 30
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 31
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 32
EB.EXECUTE.APPLICATION

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 33
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 34
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 35
Methods

 Where are method names defined?

 Are they hard coded?

Slide 36
I_METHODS.AND.PROPERTIES

 Common variable to define method names

 Methods with different names ignored

Slide 37
I_METHODS.AND.PROPERTIES

 T24’s convention is to represent each position C_ROUTINES array by

a name not a number

Slide 38
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 39
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 40
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 41
Behind the Scenes – THE.TEMPLATE

 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 42
Behind the Scenes – THE.TEMPLATE

 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 43
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 44
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 45
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 46
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 47
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 48
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 49
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 50
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 51
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 52
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 53
Field Definitions

Field Definitions

Slide 54
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 55
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 56
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 57
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 58
Table.addFieldDefinition

 Adds a field using the F, N and T definitions

 Table.addFieldDefinition(fieldName, fieldLength, fieldType, neighbour)

 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• 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 59
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)

 It takes 3 parameters, where,

• args – the list of arguments passed to Table.addField.
• nArrayItem - The N array item to process
• tArrayItem - The T array item to process

Slide 60
Field.setAttributes

 Sets the N and T array

 Field.setAttributes(fieldLength, fieldType, neighbour)

 It takes 3 parameters, where,

• 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 61
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)

 It takes 3 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• tableName – The virtual table name used to access values in EB.LOOKUP
Application.
• neighbour - Reserved for future use

Slide 62
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)

 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• tableName – The virtual table name used to access values in EB.LOOKUP
Application.
• args - (optional) Any additional arguments (mandatory, no input, etc.)
• neighbour - Reserved for future use

Slide 63
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 64
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 65
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 66
Table.addAmountField

 Adds amount field to the application

 Table.addAmountField(fieldName, currencyFieldName,args, neighbour)

 It takes 4 parameters, where,

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 67
Table.addOptionsField

 Adds a field with pre-defined set of options

 Table.addOptionsField(fieldName, options, args, neighbour)

 It takes 4 parameters, where,

fieldName - The name of the field to add. The "F" array item
options – The list of options separated by an ‘_’. The T(fieldposition)<2> item.
args – Any additional arguments (mandatory, no input, etc.)
neighbour – Reserved for future use.

CALL Table.addOptionsField("WITHDRAW.SWIPE","S_W",'','')

Slide 68
Table.addYesNoField

 Adds a simple field that holds the value YES or blank

 Table.addYesNoField(fieldName, args, neighbour)

 It takes 3 parameters, where,

fieldName - The name of the field to add. The "F" array item
args – Any additional arguments (mandatory, no input, etc.)
neighbour – reserved for future use

Slide 69
Table.setAttributeOnFields

 API to set a number of fields to be NOINPUT, NOCHANGE or

inputtable

 Table.setAttributeOnFields(attribute, fieldList)

 It takes 2 parameters, where,

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 70
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 71
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 72
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 73
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 74
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 75
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 76
How to create additional components?

 No, EB.DEV.HELPER will do it for us…..

Slide 77
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 78
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 79
Workshop

 Run EB.DEV.HELPER and create additional components for all the

applications created relating to DEBIT CARD

Slide 80