T24-CSD Programming Standards

Client Specific Development
PROGRAMMING STANDARDS
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without
the express written permission of TEMENOS HEADQUARTERS SACOPYRIGHT
2007 - 2008 TEMENOS HEADQUARTERS SA. All rights reserved.
DOCUMENT HISTORY
Author Version Date
Ponnarangam Shanmugam V.01 20 Jan 2008
Shameem Ahmed Reviewed V.01
Arun Prakash. R V.02 16 Mar 2010
Shameem Ahmed Reviewed V.02
Arun Prakash. R V.03 28 Apr 2010
Arun Prakash. R V.04 07 May 2010
Arun Prakash. R V.05 14 May 2010
Palanivel Pandiyan.A V.06 05 Aug 2011
Arunachalam. M R Reviewed V.06 16 Aug 2011
Mohanraj. R V.07 05 Jun 2012
Shameem Ahmed Reviewed V.07 15 Jun 2012
Jude / Aysha Version 08 21-Mar-2016
Sathish / Shrinath Version 09 30-Mar-2016
Aswani Kumar J Version 10 04-Oct-2016

Table of Contents
1. INTRODUCTION ............................................................................................................................... 5
2. BASICS OF jBASE PROGRAMMING ............................................................................................ 6
3. PROGRAM QUALITIES ................................................................................................................... 7
4. COMMENTS ...................................................................................................................................... 7
5. NAMING CONVENTION ................................................................................................................ 11
6. USAGE OF VARIABLES ................................................................................................................ 14
7. CODING STANDARDS .................................................................................................................. 16
7.1 GENERAL STANDARDS ................................................................................................................. 17
8. USE OF LOOPS .............................................................................................................................. 30
9. USE OF MULTI.GET.LOC.REF .................................................................................................... 31
10. jBASE STATEMENTS AND COMMANDS .............................................................................. 32
11. PERFORMANCE CONSIDERATIONS ................................................................................... 41
11.1 In BR/FS-You must definitely collect this information ....................................................... 44
11.2 In the technical specifications-the following must be indicated........................................ 44
12. USE OF IN2 ROUTINES ........................................................................................................... 46
13. T24- SECURE CODING STANDARDS ................................................................................... 47
13.1 Basic ......................................................................................................................................... 47
13.2 Information leakage ................................................................................................................ 47
13.2.1 Access control ................................................................................................................ 47
13.2.2 Insecure Storage ............................................................................................................ 47
14. FILE HANDLING ......................................................................................................................... 48
15. EXCEPTION HANDLING ........................................................................................................... 57
16. MULTITHREAD ROUTINES ..................................................................................................... 59
17. CORE ROUTINES ...................................................................................................................... 61
17.1 DATE ROUTINES................................................................................................................... 61
17.2 VALIDATION ROUTINES...................................................................................................... 63
18. EXCHANGE RATE ..................................................................................................................... 64
19. COB ROUTINES ......................................................................................................................... 64
20. CORE REUSABLE ROUTINES ................................................................................................ 65
21. UTILITY ROUTINES ................................................................................................................... 71
22. LOCAL COMMONS in AA ......................................................................................................... 74
23. VERSIONS and APIs in AA ....................................................................................................... 75
24. CORE TABLES IN AA FOR LENDING .................................................................................... 76
25. TRANSACTION BOUNDARY FOR AA ................................................................................... 77
26. SPECIAL ABOUT AA BATCH PROCESSING ....................................................................... 77
27. USEFUL APIs .............................................................................................................................. 79
Programming Standards
1. INTRODUCTION
Programming Standards is a set of rules or guidelines used when coding programs in a particular
language. It is often claimed that following a particular programming style/Standard will help programmers
to read and understand the purpose for which the source code is developed, and help to avoid introducing
errors while developing codes.
A particular Programming Standard which is applicable for one language may not be applicable for another.
Hence, Programming styles are often designed for a specific programming language style which may be
derived from the Coding Standards or Code conventions specific to company or other computing
organization, as well as the preferences of the author of the code. Programming styles are often designed
for a specific programming language style considered good in C source code may not be appropriate for
BASIC source code, and so on. However, some rules are commonly applied to many languages.
This document aims at explaining the Infobasic programming standards to be followed while coding
in jBASE or TAFC and points to be taken regarding the adherence of the local code to T24
development Standards.
2. BASICS OF jBASE PROGRAMMING
This section aims at projecting the basic points that should be adhered while coding programs in jbase.
1. R10 Coding Standards must be followed
2. If the number of lines exceeds 600 lines of code, CALL routines can be used wherever possible
to minimize lines of code.
3. The CALL routines should not have more than 4 arguments. It is advised to use dynamic arrays in
arguments if it exceeds more than 4.
4. The routine must be sectioned into smaller units/ paragraph and can be linked by using GOSUB‟s.
5. The GOSUB Para defined inside the routine must not exceed 75 lines of code.
6. The minimum number of GOSUB‟s that can be used in the routine should not exceed 5.
7. The modern day ANSI C++ compilers are designed to rate the code based on basic pre-defined
criteria‟s. The ratings will be generated during compilation of the codes and the same will be
amended at the top of the routine. The ratings generated must be NEGATIVE which implicitly means
that code Standard is in good quality.
8. It is recommended to use Eclipse as the CODE window since, it projects the view of routine in a
better way and also provide additional features than the other editors.
9. Region to be defined for all GOSUB‟S. This can be achieved by using Eclipse code window.
3. PROGRAM QUALITIES
The quality of a program is not only measured by the rating of the source code given by the compiler but
also on the level “Simplicity of the program “.
If so, what does the term “Simplicity” means?
Simplicity of program can be measured from the level of understanding by another personal on his/her first
look over the routine irrespective to whether the person knows the programming or not.
It is easy to make a programmer understand but how come the other personnel‟s?
This can be achieved by giving proper comments and using meaningful variables in the program.
4. COMMENTS
Comments in programming language is simply the programmer‟s annotation about the flow of the routine as
well as purpose of the usage of variables and GOSUB‟s defined in the routine. Those annotations are
potentially significative to programmers but typically ignorable to compilers and interpreters
Comments are usually added with the purpose of making the source code easier to understand. The syntax
and rules for comments vary and are usually defined in a programming language specification
With respect to jBASE & T24, we have got some standard formats of commenting a program.
We divide the commenting as 2 parts. They are:-
1. Generic Comments
2. Functional Comments
4.1 GENERIC COMMENTS
The generic comments are the comments which will project the outline of the routine.
The description should not describe the implementation details because these often change over time.
The generic comments should consist the details of below specified factors,
i) Company Name
ii) Developer Name
iii) Product/Module Name
iv) Parameter to which the routine is linked with
v) Incoming and Outgoing Argument details
vi) Brief Introduction of the Program
vii) Modification History
NOTE: It is essential that for TAFJ related codes to be written using the standard TAFJ IDE as a
programming environment since it provides a better view of the routine and additional features that the
other editors
The format below will provide you a better understanding about generic comments,
*********************************************************************
SUBROUTINE XXXXXXXX (ENQ.DATA)
*********************************************************************
* Company Name : Bank Name
* Developed By : Client Specific Development
* Product Name : EB
*--------------------------------------------------------------------------------------------
* Subroutine Type :
*<<VERSION/ENQUIRY/MAINLINE/PHANTOM/PROCEDURE/COB>>
* Attached to : <<VERSION Name/ENQUIRY Name/BATCH RecordID>>
* Attached as :
*<<CONVERSION/BUILD.ROUTINE/FIELD.VAL.RTN/INPUT.ROUTINE>>
* Primary Purpose : <<READ Parameter Table/WRITE to a concat
File/VALIDATE
* some logic>>
*--------------------------------------------------------------------------------------------
* Modification Details:
*-------------------------------------------------------------------------------------------
If there is a change in the code then it has to be a CR or defects from client (PACS tickets). Internal defect
is not necessary as we consider it as internal.
If a fix is developed for the routine, then the fix should contain proper “MODIFICATION DETAILS” like
modification date, defect number.
The modification history should be defined in the format as specified below,
* Modification Details:
* -----------------------------
*
* 04/05/15 - 1666397
* Enquiry crashes and times out if date input is other than 8 digits,
* since fatal error is called while call to CDT. Before processing
* validation of dates carried out and proper error message thrown to
* overcome fatal out.
8
4.2 FUNCTIONAL COMMENTS
The functional comments are nothing but the comments that will project the functionality of set of codes or a
line of code where the programmer wish to explain to the program views.
With respect to T24, it is advisable for a programmer to provide a brief introduction about each and every
GOSUB section in the beginning before start coding it.
The below given example will illustrate a sample of Functional Commenting.
E.g:
**Main process start here, Here we open the work file path
*and get all the limit ids. Finally we calculate advised amount
MAX.TOTAL = R.LIMIT<LI.MAXIMUM.TOTAL>
LR.FB.INTLIM = R.LIMIT<LI.LOCAL.REF,LOCREF.POS>
ADVISED.AMOUNT = MAX.TOTAL - LR.FB.INTLIM

5. NAMING CONVENTION
A naming convention is a set of guidelines recommended for choosing the sequence of characters to be
used for identifiers which denote variables, labels and functions etc. in source code.
Appropriate choices for variable names are seen as the keystone for good style. Poorly-named variables
make code harder to read and understand.
Reasons for using a naming convention is
1. To reduce the effort needed to read and understand source code.
2. To find out the value which the variable holds.
3. To understand the purpose for which the variable is defined
Now coming to the point, with respect to T24 programming, how we can actually define the naming
conventions? The answer for the question is sculptured below.
1. Subroutine names should be limited to 35 characters.
2. Subroutine names should not include the “$” or “_” character.
3. Routine name and template name should NOT be prefixed with “TAM” or with the product id‟s since
it would conflict with the core routines. Instead, it should be prefixed based on the type of routine
written (V.INP for version input, E. for enquiry related and B. for Batch / Service routines
E.g: V. INP.ACCOUNT.DETAILS
4. Subroutine names should be named with an extension of ‘.b’ and data records with ‘.d’ as this is
standard internal format to upload the sources/data records into RTC repository.
E.g: V. INP.ACCOUNT.DETAILS.b
F.VERSION!FUNDS.TRANSFER,AC.REFUND.d
5. The Keywords should be written only in capital letters and cannot be used as variable names in the
routine.
6. Meaningful names must be given for each local variable defined. Remove the local variables that
are initialized to NULL or assigned a value, but not used in the routine
7. Standard abbreviations are recommended for file name variables to help keep name length in
Standard form for frequently used long terms.
E.g:
FN.LETTER.OF.CREDIT = „F. LETTER.OF.CREDIT‟
F. LETTER.OF.CREDIT = ''
CALL OPF (FN. LETTER.OF.CREDIT, F. LETTER.OF.CREDIT)
8. During the execution the variables values are bound to change, hence never use different variable
names to hold the same value.
9. It is recommended not to use the same names as Labels, variables and routines.
E.g:
CONV.LBP.CCY:
*******************
* Converting the USD amount to LBP
equivalent Y.CCY.FROM = 'USD'
Y.CCY.TO = 'LBP'
CONV.LBP.CCY = ''
Both GOSUB and variable names are the same.

Instead initialize another variable for CONV.LBP.CCY = ''
CALL EB.CURR.CONV (Y.CCY.FROM, Y.AMT.FROM, Y.CCY.TO, CONV.LBP.CCY)
10. Labels and variable names should be short, simple and meaningful so that the strain on debugging
these variables names will be minimum.
E.g: Do not use variable like "TAMS.BALANCE.UPLOAD.INTO.FILE"

11. Numeric Labels should not be used. Labels must exist on their own line with no other text
appended to it.
E.g: Wrong way of Coding
DEFINE.PARAMETERS: * SEE „I_RULES‟ FOR DESCRIPTIONS *

REM > CALL XX.FIELD.DEFINITIONS
E.g: Proper way of coding
DEFINE.PARAMETERS:
* SEE „I_RULES‟ FOR DESCRIPTIONS *
REM > CALL XX.FIELD.DEFINITIONS
12. File name variables must be referenced by FN.FILENAME and File path variables must be
referenced by F.FILENAME and record variables must be referenced with R.FILENAME. The Error
variables must be referenced by ACCOUNT.ERR.
E.g: FN.ACCOUNT
F.ACCOUNT
R.ACCOUNT
ACCOUNT.ERR
13. Do not use Non-Standard Variables. Kindly Use meaningful Variables names.
Eg: Wrong way of Coding:
XX.CUST, YY.ACT
FOR Y.J = 1 TO NO.DEL - 1
FORM.DIR:= FIELD (CUR.FILE.PATH,"/", Y.J)
FORM.DIR:='/'
NEXT Y.J
Programming Stan
E.g: Proper way of Coding
FOR CUST.INT = 1 TO NO.DEL - 1

FORM.DIR:= FIELD (CUR.FILE.PATH,"/", CUST.INT)
FORM.DIR:='/'
NEXT CUST.INT
14. Do not use Alpha numeric variable names. Kindly use meaningful variable names.
15. Do not use RESERVED word (Key word) as a GOSUB Name. Kindly use meaningful names.
Eg: Wrong way of Coding:
GOSUB OPEN
OPEN:
CALL OPF (FN.CUSTOMER, F.CUSTOMER)
CALL OPF (FN.ETMB.H.DELINQ.CUST, F.ETMB.H.DELINQ.CUST)
RETURN
Note: „OPEN‟ is a RESERVED word
GOSUB OPEN.FILES
OPEN.FILES:
CALL OPF (FN.CUSTOMER, F.CUSTOMER)
CALL OPF (FN.ETMB.H.DELINQ.CUST, F.ETMB.H.DELINQ.CUST)
RETURN
6. USAGE OF VARIABLES
What is a variable?
A variable is a way of referring to a memory location.

The memory location may hold any type of data depending on the data type of the variable.
Depending upon the life of the variable inside the routine they are categorized as follows,
1. Local variable
2. Common variable
3. Array variable
4. Record variable
The points described below this section refer to scope of variables that are defined in the routine.
1. Usage of Local Variables must be reduced and wherever possible local variables can be replaced
with Common Variables.
E.g: Read on records like COMPANY,SPF, USER etc.., can be reduced and the common
variables ID.COMPANY, R.COMPANY, R.SPF.SYSTEM, OPERATOR can be used.
2. The variables which are used throughout the program should only be defined in the initialization
GOSUB. Local variables which are used in GOSUB or FOR loop should be initialized within the
GOSUB or FOR loop so that these variables are accessible only within the range for which it is
initialized and cannot be used outside the range of the variable for better readability.
3. Avoid the common variable names passed on as arguments. Common variables like ETEXT cannot
be defined as error variable in F.READ or EB.READLIST
4. Use local variables as much as minimum and in case if program needs, use array variable by
grouping the variables by its similarity. This helps in reducing the complexity of the program.
5. I_RULES to be referred & COMMON variables have to be checked before programming - the reason
being that some of the value might have be assigned by the CORE program and the local
development can do away with just using the same.
6. Do not assign values to common variables and override the actual functionality of the variable. This
may affect the overall functionality of the common variable used.
E.g: TODAY = “20091110”
7. Do not use a variable as dimensional array before declaring in the routine.

Standards
8. Record variables must not be used for Calculation purpose. Only the final update must be done to the
Record variables.
R.ACCOUNT <AC.WORKING.BALANCE> = R.ACCOUNT <AC.WORKING.BALANCE>

*COM.AMT
WORKING BALANCE = R.ACCOUNT <AC.WORKING.BALANCE>
TOT.AMOUNT = WORKING BALANCE* COM.AMT
R.ACCOUNT <AC.WORKING.BALANCE> = TOT.AMOUNT
9. When declaring variables do not use keywords like OPEN, FOR etc … as variable names in the
routines
10. Avoid using character checks which have combination of upper case and lower which will yield
incorrect results
11. Product and Subroutine level Common variables are retained and possible to be carried out to
subsequent transactions and provide unexpected results. So explicitly clear a common variable if the
usage is not required to be passed on to subsequent transactions or cob processes.
7. CODING STANDARDS
Coding Standards is a set of rules or guidelines used when writing the source code for a
computer program. Coding Standards refers to specifying rules and guidelines for the proper use of an
individual programming language's constructs. Hence, it is essential to define set of criteria so as how the
source code should be and what all could be the necessary contents of a code.
Though at initial stages it seems like a burden to follow standard, its advantages become visible over a
period of time. Some of the advantages are:
1. Programmer feels comfortable with the code written by others, as it is similar to what he
himself would have written.
2. Person joining the group at later stage can pick up the code easily (once he is familiar with
the standards).
Now coming to T24, what is Coding Standards?

Coding Standards defines the way a source code should be, how to proceed
This section projects set of Standards that should be adhered while writing a jBASE code
Programming Standard
7.1 GENERAL STANDARDS
This section explains general standards that must be adhered and also the basic files that should be
included at the start of routine.
1. All routines must have I_COMMON and I_EQUATE inserted at the start of the program.
2. Each routine should have one main controlling section with the detailed code written. Do not write
TOP DOWN code. The main controlling section should contain the insert files, GOSUB statements
along with the proper RETURN statement. Each GOSUB should be defined properly along with the
RETURN statement.
E.g:
GOSUB INITIALIZE
GOSUB OPEN FILES
GOSUB PROCESS
RETURN
INITIALIZE:
/Statements
RETURN
OPEN FILES:
/Statements
RETURN
PROCESS:
/Statements
GOSUB CALCULATE
RETURN
CALCULATE:
/Statements
RETURN
3. Before the commencing the PROCESS gosub, check all the preliminary conditions separately in a
GOSUB.
CHECK.PRELIM.CONDITIONS:
* * * *Check for any Pre requisite conditions - like the existence of a record/parameter etc
* if not, set PROCESS.GOAHEAD to 0
* * * * When adding more CASEs, remember to assign the number of CASE statements
to *MAX.LOOPS
LOOP.CNT = 1 ; MAX.LOOPS =
NN LOOP
WHILE LOOP.CNT LE MAX.LOOPS AND PROCESS.GOAHEAD DO
BEGIN CASE
CASE LOOP.CNT EQ 1
REM > IF APPLICATION NE 'CUSTOMER' THEN PROCESS.GOAHEAD = 0
CASE LOOP.CNT EQ 2
REM >IF NOT (V$FUNCTION MATCHES 'I' :VM: 'C' :VM: 'H')
THEN PROCESS.GOAHEA=0
CASE LOOP.CNT EQ 3
REM > CU.LREF.NAMES = „SIGNATURE.Y.N‟:FM: 'US.TAX.ID' :FM:
'US.TAX.ID.TYP' REM > CU.LREF.POSNS = '' ; CU.LREF.ERR = ''
REM > CALL GET.LOC.REF.CACHE ("CUSTOMER", CU.LREF.NAMES,
CU.LREF.POSNS, CU.LREF.ERR)
REM > IF CU.LREF.ERR THEN
REM > ETEXT = RAISE (CU.LREF.ERR<1>)
REM > PROCESS.GOAHEAD = 0
REM > END ELSE
REM > SIGN.POS = CU.LREF.POSNS<1>; TAX.ID.POS = CU.LREF.POSNS<2>;
TAX.ID.TYP.POS = CU.LREF.POSNS<3>
REM > END
END CASE
LOOP.CNT += 1
REPEAT
4. If number of argument is more than 5, try to use array variables in the subroutines.
CALL INT.RATE (CUSTOMER.ID, CATEGORY, MNEMONIC, CURRENCY, WORKING BALANCE,

ACCT.OFF)
ACCT.ARRAY = CUSTOMER.ID: FM: CATEGORY: FM: MNEMONIC: FM: CURRENCY:

FM: WORKING BALANCE: FM: ACCT.OFF
CALL INT.RATE (ACCT.ARRAY)
5. New template programs should contain lesser lines of code. All lines of code should be called from
the subroutines defined in the template like FIELD.DEFINITIONS, CHECK.FIELDS & CROSSVAL.
6. Do not cut and paste code, use an internal subroutine/paragraph for code that is very similar or used
several times. When maintaining/enhancing older programs with duplicated code like this, in the area
being modified, re-write this section to remove the duplication. This will make future maintenance and
enhancement easier.
7. Programs should be coded as “SUBROUTINE”. In case if its required to call a program from jbase
prompt or call the program using EXECUTE statement, then the program must be executed as
“PROGRAM”.
8. In case, a program is coded as “PROGRAM” then exit statement should be “STOP” and not
“RETURN”.
9. The subroutines as well as internal subroutines should return from a single exit point. There should
not be any abnormal termination in the program using commands like ABORT or EXIT. The routine
should terminate safely using return statement.
10. Commented code of lines should not be present during the delivery for testing. This may improve
readability effort in the routine.
E.g
*IF Y.RTN.NAME EQ 'F.READ' THEN
* TABLE.LIST<-1> = @ (FIELD (FIELD (Y.LINE.OUTPUT,'(', 2),',', 2))
*END
*ELSE
11. Commented lines of code in most preferred for better understanding of the statement purpose.
E.g:
* Conversion of foreign currency to local
currency OUTSTAND.AMT = O.DATA
LENGTH.VAL=LEN (OUTSTAND.AMT); *Calculating the length of
OUTSTAND.AMT YCCY.FROM = OUTSTAND.AMT [1, 3];*Currency
YCCY.TO = ‘USD’;*USD
YAMT.FROM = OUTSTAND.AMT [4,LENGTH.VAL] ;*Amount part
12. Fields must never be referenced with the field number except in conversion routines. Use the field
names supplied in Standard inserts. This is because in future, when template level changes are done
it affects the programs and the program needs to be coded again.
13. There is no need to include @symbol before VM, SM and FM. Once the I_EQUATE file is inserted,
the VM, SM and FM will be internally converted to @VM, @SM and @FM respectively.
MSG.COUNT = DCOUNT (MSG.SWEEP, @VM)

MSG.COUNT = DCOUNT (MSG.SWEEP, VM)
14. OPEN statement on any T24 file should to be replaced by OPF. This is because, when the path is
changed and OPEN command is used, then the changes have to be performed at program level.
Whereas, if OPF is used it’s enough to perform changes at VOC level
15. Do not use the command TXT in T24 browser. This is because; TXT translates only dynamic
messages and hence cannot be used in browser.
16. Do not hard code the override messages; define the override messages in the OVERRIDE table. The
TEXT that needs to be displayed must be defined in the F.OVERRIDE table. Since, the override
messages should not be overridden the value of CURR.NO should be incremented (CURR.NO+1), so
that CURR.NO may store number of override messages.
IF ACC.BRANCH NE FT.BRANCH THEN

TEXT = “Non-Contingent PL items are being excluded from
PL.CLOSE.OUT" CURR.NO = 1
CALL STORE.OVERRIDE (CURR.NO)
END
Eg: Proper way of Coding
IF ACC.BRANCH NE FT.BRANCH THEN

TEXT = "RE-EXCLUDING.PL.TYPES"
CURR.NO = 1 //* Any numerical value
CALL STORE.OVERRIDE (CURR.NO)
END
17. Do not hard code the ETEXT Value. Kindly Create EB.ERROR Record.
Eg: Wrong way of coding
IF CHQ.BANK AND LEN (CHQ.BANK) NE 9 THEN

ETEXT = 'INCORRECT BANK CODE'
CALL STORE.END.ERROR
END
Eg: Proper way of Coding
IF CHQ.BANK AND LEN (CHQ.BANK) NE 9 THEN
ETEXT = 'EB-INC.BANK'
CALL STORE.END.ERROR
END
18. Do not hard code the AF Value
Eg: Wrong way of coding
AF=”FT.CREDIT.AMOUNT”
Eg: Proper way of coding
AF= FT.CREDIT.AMOUNT
19. Avoid the inline function as it reduces the complexity of the function and improves the readability. Also,
formatting of the routine can be improved by using Ctrl^V formatting method
E.g.: Wrong way of Coding
IF PASS.VALUE AND PASS.VALUE EQ 'NO' THEN PASS.VALUE = 'Partial Shipment not

allowed'
IF PASS.VALUE AND PASS.VALUE EQ 'NO' THEN

PASS.VALUE = 'Partial Shipment not allowed'
20. Do not use „BREAK‟ Statement. Kindly use FLAG LOGIC or put RETURN instead of BREAK.
Some cases we have to use as per Scenario I.

Scenario I:
PROCESS:
LOOP
WHILE J LE PRE.CNT
IF OUT.ARR.MG.DESC<J> EQ "DIS" THEN
Y.PRE.VAL.DATE = OUT.ARR.VAL.DATE<J>
BREAK
END
J+=1
REPEAT
RETURN
PROCESS:
LOOP
WHILE J LE PRE.CN
IF OUT.ARR.MG.DESC<J> EQ "DIS" THEN
Y.PRE.VAL.DATE = OUT.ARR.VAL.DATE<J>
RETURN
END
J+=1
REPEAT
RETURN
Some cases we have to use as per Scenario II.
Scenario II: FLAG LOGIC:
PROCESS:
FLAG = 0
LOOP
UNTIL SEQ.DATE.AMEND<Y.K> GE Y.FMD AND FLAG EQ '0'
IF Y.ANN.CAL.FLAG NE '1' THEN

GOSUB AMEND.SEQ.DATE.2
END ELSE
GOSUB
AMN.ANNUITY.CALENDAR END
IF ETEXT THEN
RETURN
END
IF Y.J NE '2' AND Y.SCHED.TYPE EQ 'ANNUITY.CALENDAR'
THEN FLAG = 1
END
Y.K = Y.K + 1
REPEAT
21. Do not use „ABORT‟ Statement. Instead of ABORT, Kindly use „RETURN‟.
E.g: Wrong way of Coding:
PROCESS:
PB.XML.FILE.NAME = ''
FV.OUT.PATH = ''
OPEN OUT.DIR.PATH TO FV.OUT.PATH ELSE
ABORT 201, OUT.DIR.PATH
END
PB.XML.FILE.NAME = SEQ.NO: '.xml'

WRITE OFSML.RECORD TO FV.OUT.PATH, PB.XML.FILE.NAME ON
ERROR ABORT 201, FV.OUT.PATH, PB.XML.FILE.NAME
END
RETURN
PROCESS:
PB.XML.FILE.NAME = ''
FV.OUT.PATH = ''
OPEN OUT.DIR.PATH TO FV.OUT.PATH ELSE
RETURN
END
PB.XML.FILE.NAME = SEQ.NO: '.xml'

WRITE OFSML.RECORD TO FV.OUT.PATH, PB.XML.FILE.NAME ON ERROR
RETURN
END
RETURN
22. Do not use CONTINUE. Kindly Put RETURN or FLAG LOGIC.
IF PL.VAL THEN
IF R.ARRANGEMENT<AA.ARR.PRODUCT.LINE> NE PL.VAL THEN

CONTINUE
END
END
PL.FLAG = 'EXECUTE'
IF PL.VAL THEN
PL.FLAG = ''
IF R.ARRANGEMENT<AA.ARR.PRODUCT.LINE> EQ PL.VAL THEN

PL.FLAG = 'EXECUTE'
END
END
23. Never use “STOP” to terminate a batch process. Always use “FATAL.ERROR” to terminate a batch
job when error condition occurs.
IF Y.DELINQ.ERROR NE '' THEN

Y.CSV.RES.FILE.ID = TODAY:"-Error-":Y.CSV.FILE.ID
OPENSEQ F.PATH.DIR, Y.CSV.RES.FILE.ID TO DELINQ.RESPONSE.PTR ELSE
CREATE DELINQ.RESPONSE.PTR ELSE
END
END
LOOP
READSEQ RES.ID FROM DELINQ.RESPONSE.PTR ELSE FILE.EOF =
1 WHILE NOT (FILE.EOF)
Y.RES.DELIN.CUST = RES.ID
CHANGE CR TO "" IN Y.CUR.DELIN.CUST.DET
Y.DELINQ.ERROR1<-1> = Y.RES.DELIN.CUST
REPEAT
WRITESEQ Y.DELINQ.ERROR TO DELINQ.RESPONSE.PTR ELSE
STOP
END
END
RETURN
Programming
IF Y.DELINQ.ERROR NE '' THEN
Y.CSV.RES.FILE.ID = TODAY:"-Error-":Y.CSV.FILE.ID
OPENSEQ F.PATH.DIR,Y.CSV.RES.FILE.ID TO DELINQ.RESPONSE.PTR ELSE
CREATE DELINQ.RESPONSE.PTR ELSE
END
END
LOOP
READSEQ RES.ID FROM DELINQ.RESPONSE.PTR ELSE FILE.EOF =
1 WHILE NOT(FILE.EOF)
Y.RES.DELIN.CUST = RES.ID
CHANGE CR TO "" IN Y.CUR.DELIN.CUST.DET
Y.DELINQ.ERROR1<-1> = Y.RES.DELIN.CUST
REPEAT
WRITESEQ Y.DELINQ.ERROR TO DELINQ.RESPONSE.PTR ELSE
CALL FATAL.ERROR (Y.CSV.RES.FILE.ID)
END
END
RETURN
24. Kindly use $INSERT instead of using $INCLUDE.
$INSERT I_COMMON
$INSERT I_EQUATE
25. Do not use JOURNAL.UPDATE in the Routine.
26. Kindly avoid the usage of CHECK.RECORD.ROUTINE wherever possible. The usage of
CHECK.REC.RTN should be limited to scenarios, where there is an absolute necessity to modify the
field properties alone
27. Do not use more than ten local fields.

28. Use CALLJEE instead of CALLJ from R10 release onwards.
7.1.1 CODING CONSIDERATIONS
 Any code to be developed should always be named generic. Client names/acronyms

should not be used. 

 Use E.STMT.ENQ.BY.CONCAT (or TAM.GET.ACCT.TRANSACTIONS – locally modified
to be used as an API/call routine) to fetch the entries for a given period. Rather than
selecting STMT.ENTRY file. 

 Use bulking wherever possible 

 No hard coding of data while coding. 

 A generic parameter table should be built. This can have some 100 local ref fields that
can be named as required in each of the project. Eventually, this parameter file will
become the base PARAM file 

7.1.2 STANDARD CORE API
 There are Standard CORE API‟s available, which should be used to retrieve information,
instead of incorporating new logic / code for any given problem. We will have to ensure
that we use already available API‟s to achieve our solution. 
Sample of CORE API‟s with details on what they do is made available in below link:
http://uni-t.temenos.com/dms/QMS/L2L3/Documentation/CSD_Governance_API_Details.xls?Web=1
7.1.3 LOCAL REFERENCE FIELDS AND LOCAL VARIABLES
 Local reference – on core templates should be below 10. If there are more fields to be
added proper explanation has to be provided as to why additional fields have to be
included. 

 Local variables should be under check and usage of Array has to be promoted. 
8. USE OF LOOPS
Loops are used for iterative purposes to execute same set of instructions specified number of times or until
a specific condition or result is obtained.
There are various types of loops in jbase namely,
1) FOR...NEXT
2) LOOP... REMOVE
3) CASE STATEMENTS
Though these loops make the execution of instructions faster and easier, there are certain specific
constraints that should be considered while coding these loops in the routine. The criteria to be considered
before using these loops are as follows,
1. Instead of FOR and NEXT loops prefer using LOOP and REMOVE syntax since it is more efficient
than FOR loop.
2. In GOSUB avoid deeply nested IFs and large CASE constructs. This will help in reducing the
complexity of the GOSUB as well as reduce the overall rating of the routine.
3. The construction of IF....ELSE statements can be very complicated but it‟s a good practice to make
it both readable and non-ambiguous. Consider the following example,
E.g : Wrong way of Coding
IF CONDITION THEN READ RECORD FROM F.FILE , ID THEN ID.OK = 1

END ELSE
(Statements)
END
This is poor coding technique since, it is difficult to analyze whether the ELSE statements should be
executed for IF or READ condition. Hence the following code should be re-written as,
IF CONDITION THEN
READ RECORD FROM F.FILE , ID THEN
ID.OK = 1
END
END ELSE
// (Statements)
END
9. USE OF MULTI.GET.LOC.REF
Each application has large number of fields to store for a bank. But it is not possible for a bank to store all
possible fields that a bank may require.
To overcome this, T24 provides us the functionality of „Local Reference‟ fields. These fields can be added for a
particular application depending upon the bank„s requirement. They are totally „CUSTOMISABLE‟.
To get this local reference field position, call made to GET.LOC.REF which will return the position of the
local reference field from the Standard Selection table.
This section explains how to use GET.LOC.REF and to retrieve the local field position,
1. Do not use OPF for the files in which only local reference field values are updated using
GET.LOC.REF.
2. Hard coding of LOCAL.REF fields of any applications to be replaced by the position returned by
GET.LOC.REF. Do not use the variable POS inside the routine for calculation purposes. Instead
assign the value of POS to a variable and use that variable inside the routine.
E.g:
APPL = "CUSTOMER"
FLD = "OPEN.DATE"
POS = ''
CALL GET.LOC.REF (APPL, FLD, POS)
OPEN.DATE.POS = POS<1,1>
3. Use MULTI.GET.LOC.REF instead of GET.LOC.REF to get local reference field position. When
GET.LOC.REF is used the same file needs to be reopened multiple times to get the local field
position. Whereas, if MULTI.GET.LOC.REF is used, the file is opened once and multiple field
positions can be retrieved.
E.g: Wrong Way of Coding:
CALL GET.LOC.REF("CUSTOMER", "CUST.ID", LR.CUST.ID)

CALL GET.LOC.REF ("CUSTOMER", "MFO.CODE", LR.MFO.CODE)
CALL GET.LOC.REF ("CUSTOMER", "NBU.B010", LR.NBU.B010)
CALL GET.LOC.REF ("CUSTOMER", "USB.OBLAST", LR.USB.OBLAST)
APPL = "CUSTOMER"
FLD = " CUST.ID”:VM: "MFO.CODE":VM:” NBU.B010"

POS = ''
CALL MULTI.GET.LOC.REF (APPL, FLD,POS)
CUST.ID.POS = POS<1,1>
NBU.B010.POS= POS<1,3>
MFO.CODE.POS= POS<1,2>
10. jBASE STATEMENTS AND COMMANDS
The commands are used to perform a specific task in the program, which may be print or open file or
delete and so on.
Hence in jbase, the programmer can make use of available commands and statements to make the code
simpler and manageable.
This section explains the few jbase commands that can/cannot be used and if usable, the way how to use
it,
1. Do not use PRINT and CRT in GUI since it will display nothing. PRINT and CRT will work only in CUI
mode.
2. The CHAIN statement exits the current program and transfers process control to the program defined
by the expression. Process control will never return to the originating program.
E.g
CHAIN "OFF" ;* exit via the OFF command
! Prog1
COMMON A,B
A = 50; B = 100
CHAIN "NEWPROG I"
! NEWPROG
COMMON I,J
! I and J inherited
3. When specified elements need to be removed from a dynamic array DEL command can be
used. This command will delete/remove only the particular element specified.
E.g:
FOR I = 1 TO 10
NUMBERS<I> = I
NEXT I
FOR I = 9 TO 1 STEP -2
DEL MUMBERS<I>
NEXT I
4. Do not use INPUT statement since it may lead to severe implications and may cause the session to
hang/ or terminate abnormally.
Programming
5. Do not use EQU command when array variables which do not have an underlying table / file are
EQUATED with numbers rather than names.
E.g:
EQU LO24.CR.SCORING TO 1 ;
R.LO24<LO24.CR.SCORING>
6. The ASCII function can be used when all the characters in the expression from EBCDIC character
set are to be converted to ASCII character set.
E.g:
AsciiBlock = ASCII(EbcdicBlock)
7. The DEFFUN statement can be used to declare an external jBC function to a jBC compiler and
define its arguments. If the RETURN statement specifies no value, then an empty string is returned
by the function.
E.g:
DEFFUN Add()
A = 10
B = 20
sum = Add(A,
B) X = RND(42)
Y = RND(24)
Add(X, Y)
FUNCTION Add(operand1,
operand2) result = operand1 +
operand2 RETURN(result)
8. The command ABSS returns absolute value of all the elements in dynamic array. Hence ABSS can
be used to return absolute value of an array. If the element in the dynamic array is null, then null is
returned for that element.
E.g:
Y = REUSE(300)
Z = 500:@VM:400:@VM:300:@SM:200:@SM:100
A = SUBS(Z,Y)
The output of this program will be
200]100]0\-100\-200
200]100]0\100\200
9. Remove DEBUG after testing the program. DEBUG should not be present during the delivery of the
program
10. The use of statement TRIM command allows characters to be removed from the string in number of
ways. Hence depending upon the character that needs to be removed, proper choice of trim options
can be used.
E.g:
* Remove spaces and tabs (second parameter
ignored) Answer = TRIM(Answer, ", "D")
* Remove all dots
Thief = TRIM(Joker, ".", "A")
11. The MAT command can be used to either assign every element in a specified array to a single value
or to assign entire contents of one array to another.
Programming
E.g:
DIM A(45), G(50)

MAT A = “Array Value”
MAT G = MAT A
12. The INDEX function will return the position of a character or characters within another string.
E.g:
AB = “Temenos”
IND.POS = INDEX( AB , “e” , 1 )
The result of above program is 2.
13. The function ICONV can be used to convert the data in external form such as dates to their
internal form.
E.g:
INTDATE = ICONV(“27 May 2009”, “D”)
Output of the command is May 27, 2009.
14. The function OCONV can be used to convert the data in internal form to their external form.
E.g:
GET.DATE = OCONV(DATE(),"D4-")
GET.TIME = OCONV(TIME(),"MTS")
15. The execution of the program can be halted by using EXIT command which exits returning a
numeric code to the parent process. If the exit expression doesn‟t evaluate to a numeric value then
the program will enter the debugger with suitable error message.
Programming St
16. The ALPHA function will check whether the expression consists of entirely alphabetical characters.
It will return value 1 if the expression is purely alphabetic else return 0.
E.g:
Abc = “ABC”
IF ALPHA(Abc) THEN
//Statements
END ELSE
//Statements
END
17. CLEARFILE can be used to clear data of a previously opened file only if the file is opened using
OPEN statement.
18. When FIND statement is used, it will either omit IF clause or ELSE clause but will never omit both.
E.g:
VAR= “ABC”:VM:”JAC”:VM:”CDE”:”WHO”
FIND “JAC” IN VAR SETTING Ap, Vp THEN
TEXT “JAC IS IN FIELD “ :Ap: “, VALUE ”: Vp
ELSE
TEXT “JAC IS NOT IN FIELD”
END
The output of the above routine will be,
JAC IS IN FIELD 1, VALUE 2.
19. Do not use HUSH statement to suppress the output display unless the display is unnecessary.
When HUSH ON is used all output is suppressed including the error messages and request for
information. HUSH statement will suppress all output normally sent to a terminal during processing.
HUSH also suppress output to COMO file.
20. Do not use CALLC function to transfer arguments which are arrays since CALLC function is used to
transfer the program control to an external function and CALLC arguments can be simple or
complex expressions.
E.g:
A = 10; B = 1000
MyFunction = "MYC1"
CALLC @MyFunction
Result = CALLC MYC2(A, B)
TEXT "Result is ":Result
21. Use COUNTS function to count the number of times a substring is repeated in each element of
dynamic array. The result is a new dynamic array whose elements are the counts corresponding to
the elements in the dynamic array.
E.g:
ARRAY1 = “A”:@VM:”AA”:@VM:”AAAA”
COUNTVALUE= COUNTS(ARRAY, “A”)
22. For any T24 Release in R09, do not use OFS.GLOBUS.MANAGER from version routines.
OFS.GLOBUS.MANAGER can be used only for validation purposes. To avoid transaction boundary
issues, OFS.POST.MESSAGE should be preferred over the use of OGM.
23. The usage of OFS.POST.MESSAGE is restricted to delaying the processing of the transactions (by
writing the message to queue and then being later processed by OFS.MESSAGE.SERVICE). Also
suggest that the parallel and synchronous run of OFS.REPONSE.QUEUE should be encouraged to
avoid the growth of the OFS.MESSAGE.QUEUE. This is preferred way of doing it rather than
clearing the file manually
24. Where ever the ID of a TXN is required for updation, do a validate using OGM and get the ID,
then use the OFS.POST.MESSAGE with the ID and write to queue
25. Passing the company ID always with the OFS messages, since this has been seen to have a little
faster response time when compared to messages without company ID‟s.
26. Use the OFS.BUILD.RECORD, instead of forming the OFS message by hard coding the field
values.
27. When forming OFS messages please included the below syntax which will insert the last multivalue
and subvalue set with values rather that doing DCOUNT and adding the values to the array.
For example:- To add a value to the last multivalue set / subvalue set for a field say
POSTING.RESTRICT, the message can contain the syntax like
POSTING.RESTRICT:-1:-1=3
This syntax can be used to add field multi values via OFS irrespective of available VM or SM rather than
reading the record to calculate next multi value position
28. Do not use INPUT.BUFFER (used as keyboard type ahead) variable for defaulting data or
navigation commands e.g. moving to a new field or expanding a multi-valued field etc since
INPUT.BUFFER cannot be recognised by GUI.
29. Use REFRESH.FIELD and REFRESH.SCREEN to refresh the screen although use the later
sparingly since all the field definitions and all the data are resent to GUI again.
30. All SELECT statements with multiple conditions separated by SPACE should be replaced by AND
condition.
E.g.: Wrong way of Coding
SEL.CMD="SSELECT ":FN.IS.H.CONTRACTS: “WITH FWL.FLAG EQ 'YES' " : “ WITH
FWL.LD.ID NE "
E.g.: Proper way of Coding
SEL.CMD="SSELECT ":FN.IS.H.CONTRACTS
SEL.CMD:=" WITH FWL.FLAG EQ 'YES'"
SEL.CMD:=" AND WITH FWL.LD.ID NE ''"
30. Never to use STOP or ABORT. In case of error, the errors should be properly logged and the
control should return safely from the routine.
31. Do not use GOTO even if it is to exit a unit or used to retry the record that is locked. The use of the
GOTO command is not recommended as it obscures the readability of code and therefore is a
hindrance to maintainability. All Programs written using the GOTO construct can be written using
structured statements such as LOOP and FOR. Opinions on this are divided but the consensus is
that GOTO should be avoided.
11. PERFORMANCE CONSIDERATIONS
Performance issues that may arise in T24 may be as a result of parameters that are shipped with the
application in T24. These offer most detailed functionality but at a cost. At the time of writing T24 actively
modified to default parameter settings to be performance oriented.
This section details certain performance issues that can be overcome by possible usage of another
parameter with the same functionality.
1. Use the faster operators “:=“ “+=“ etc.
E.g.
TOTAL.VAL += SUB.TOTAL
Instead of poor coding technique as below,
TOTAL.VAL = TOTAL.VAL + SUB.TOTAL.
2. Avoid large dynamic arrays (greater than 1000 bytes).
3. Always use “:=“instead of <-1> when building a large dynamic array. There is little difference when
performed at FIELD level, but this is expensive on multi and sub values.
4. Construct case statements so that the most often used condition is at the top.
5. Do not perform counts in the controlling section of a loop:
E.g.
FOR CNT = 1 to DCOUNT(array, FM)
It should be written as two separate statements:
E.g:
NO.ITEMS = DCOUNT(array,FM)
FOR CNT = 1 to NO.ITEMS
6. The system will evaluate the DCOUNT for every pass of the FOR.. NEXT loop, which can be very
expensive with large arrays, where it only needs to be evaluated once.
7. Do NOT use DBR to read single fields from a record as this reads the whole record, it is better to
read the entire record once and extract the values required. A typical subroutine will access more
than value from a record, and even if it does not do, then further enhancement will be easier if the
entire record is available.
8. Ensure that new files created have a sensible modulo. Do NOT release new file control records with
a modulo of 3 or 9731, try to work out a projected record size and base the size on a database with
a reasonable volume.
9. Make sure that operations are not needlessly repeated within a loop, for example avoid re-reading
the same parameter record every time a loop is executed.
10. Do NOT select files that are known to be likely to grow large in installations, use concat files or
other alternative methods of finding the records required. When developing new applications /
processes. If a process will be dependent upon selection of a file that will grow large, build an
alternative access method, e.g. a concatfile.
Example files include:
STMT.ENTRY
CATEG.ENTRY
RE.CONSOL.SPEC.ENTRY
LIMIT.TXNS
SC.POS.ASSET
For extracting data from STMT.ENTRY , CATEG.ENTRY AND RE.CONSOL.SPEC.ENTRY please

use the below core contact tables to get data as per the business logic
RE.CONSOL.SPEC.ENT.KEY
RE.CONSOL.STMT.ENT.KEY
11. Be very careful in the use of concatfiles. A poorly designed concatfile can result in a performance
overhead when updated due to the large record size created and system locks if the key is a poor
choice. E.g. the concatfile LMM.CURRENCY is a poor file since the key is likely to be common with
the majority of contracts, this has the effect of allowing only a single contract to be entered at any
one time for a given currency, and is likely to contain massive records (e.g. for local currency). If a
concatfile is likely to contain more than 1000 ids in it a different structure / process should be used.
12. Use standard system routines and functions wherever available. This will optimise the performance.
13. Avoid unnecessary select statements; if a record key can be obtained using direct access, a select
is an unnecessary overhead. Do not select a file with a specific key, put into a select list, and then
read the record.
14. Use SUM etc to add all multi-values in a field together. Do not use a loop to process each multi-
value separately.
15. When dynamic arrays are used they become more and more in efficient to store data when the
number of values and multi-values become large. Even at around 100 the processing will noticeably
degrade
16. The cache must ONLY be used when the result of the query is static at run time, e.g. CATEGORY
or COMPANY. Caching must NOT be used where variable data is used in the selection. Once the
query results have been returned, they are added to the cache mechanism and further invocation of
the named select will always use the cached results
17. Do not use condition selection in query file like CUSTOMER, ACCOUNT, STMT.ENTRY, etc…
chiefly in oracle database. This is because the condition query on huge files may take up more time
to extract values from the files. Instead use SELECT condition and validate the condition criteria
using LOOPS.
18. Select which has a possibility of multiple record selections should consider using the EQ clause
instead of LIKE in it. Eg. To select accounts with category = 1001,6001 & 5001 consider using it as
SELECT FBNK.ACCOUNT WITH CATEGORY EQ 1001 6001 5001. This works faster with
traditional databases which make use of drivers to communicate.
19. Using convert is a performance issue since it is more time consuming and hence use CHANGE
instead of CONVERT. The benchmark result shows that CONVERT on large arrays is 20 times
slower than using CHANGE under similar circumstances.
The first program that uses CONVERT completed in 40-50 minutes and the second program using
CHANGE completed in less than 2 seconds.
The TEST.REC has 20000 lines of code written.
CONVERT FM TO '' IN R.REC
E.g: Proper Way of Coding
R.REC = CHANGE (R.REC,FM,"")

20. We should not use ACCOUNT.PARAMETER hook routine at ACCOUNTING.SUBRTN field
unnecessarily. We need to check for the feasibility to achieve the required functionality using
Version/Version.Control.
ACCOUNT.PARAMETER hook routine to be used only if there is no other option is available to us.
21. Do not use EB.INTEREST.CALC routine in local routines.
11.1 In BR/FS-You must definitely collect this information
Volume of transactions to be processed in a day. 


Is the volume consistent through the day or there are peaks and troughs. E.g. peak
transactions during the morning or during the month end etc. If that is the case volumes
during peak period and volumes during normal period. 

If the volumes are from multiple channels then volume per channel must be provided. Also,
an indicator to indicate whether it is a client facing channel (e.g. – ATM, Internet Banking) or
internal user must be clearly indicated 

11.2 In the technical specifications-the following must be indicated
If the transaction is posted Online or a Service
Online
 Each online transaction we must provide consideration to the following. 


 Number of fields on screen including number of multi values on screen. There must be a
restriction on the number of fields input/displayed as loading data in the screen on browser
will be slow 

 When COS is displayed care must be taken that the landing screen is never the COS and
even in a COS scenario very minimal applications are shown together. If too many enquiries
are placed in COS then all the requests will clog the agents in parallel. This being the case
the number of enquiries and applications must be limited in a COS. 

 Have the following consideration on I/O.
Activity Numbers Guidelines
No of All files must be opened using OPF.

Files Repeatedly opened files must be put in a common variable rather than being
Opened X repeatedly OPF‟ed
1. If Locked and read - ensure that there are no locking contentions.

Accounts must be sub accounted if there is a possibility of sub accounting
No of and IDS must be always set to Unique.
Files 2. Size of the record read should always be small < 4096 bytes.
Read X 3. All parameter files must be always CACHE.READ
No of 1. No Locking contentions
Files 2. Size of record written should always be small.
Written X 3. Never have redundant writes
No of 1. Restrict Selects - must always be reads unless the selected file is a non-
Selects X growing file and small in size
 Enquiries must never be on Entry files including STMT.ENTRY,CATEG.ENTRY or

RE.CONSOL.SPEC.ENTRY 

 On large files there must definitely an indexed field which must be part of the mandatory
selection criteria. 

 Never use any I-Descriptor for selection criteria. 

 Large enquiry output must be converted to a report executed via an online service. 

 Logging must be enabled only on request and must have brief and full options. Logging must
be switched off by default 
COB/ Service
 Must always be multi-threaded and multi-server compatible 


 It must always be re-runnable from a crashed point 

 Have the following consideration for I/O
Activity Numbers Guidelines
No of All files must be opened using OPF.

Files All OPFs must happen in the LOAD section of the multi-threaded process -
Opened X unless required to be in the record routine
1. If Locked and read - ensure that there are no locking contentions.

Accounts must be sub accounted if there is a possibility of sub accounting
No of 2. Size of the record read should always be small < 4096 bytes.
Files 3. All parameter files must be always CACHE.READ and must be read in the
Read X load routine
No of 1. No Locking contentions
Files 2. Size of record written should always be small.
Written X 3. Never have redundant writes
No of There must be only one select from the .SELECT routine. Any other selects
Selects X is not permitted
The largest transaction in a record routine must be less than the review seconds, i.e. 60
seconds 

Any auto service must not run with a review time of less than 60 seconds. There will be
requirements for <5 second review time but this should not be permitted 

Logging must be enabled only on request and must have brief and full options. Logging must
be switched off by default 

If the process is a COB process then all consideration must be given to check if this can be
placed outside the COB process and in the online stage. 



12. USE OF IN2 ROUTINES
IN2 routines are generally used for the field definitions of the applications. IN2 routines can also be used
elsewhere if it is called correctly.
1. The T array setting for IN2 routines can be initialized depending on type of field F(Z) for which the IN2
routine is invoked. IN2 routines can validate upon fields like alphanumeric text, Amounts, Dates,
Account Numbers, Category, Currency, Charges, Commissions and tax, Customer. Refer IN2 subroutin
guide for further clarifications
13. T24- SECURE CODING STANDARDS
13.1Basic
1. Avoid using common variables to pass as parameters in subroutines
2. Avoid using transaction, boundary related core common variables – except in core programs where it
is specifically required. Any update to core COB files – eg JOB.LIST, its related locking updates etc
should be avoided.
3. Ensure that code does not alter global common variables like TODAY, ID.COMPANY, R.COMPANY,
R.DATES etc within application code. Only the components/subroutines that own these common
variables could change them. For example ID.COMPANY could be changed by LOAD.COMPANY.
4. Ensure that named common variables are only assigned in the appropriate routines. For example
named commons used in batch – should only be assigned in the load routine. The record /Select
routine should only use them not alter values in them unless functionality demands it
5. When common variables need to be used in programs ensure that they are reset after they are
expected to be out of scope.
13.2Information leakage
1. Ensure not to log highly sensitive information where possible. Logging should only use T24 logger
framework
2. System memory variables should not be used to log any sensitive information as it can be
misused /monitored by others
13.2.1 Access control
1. Ensure not to log highly sensitive information where possible. Logging should only use T24 logger
framework EB.CALL.API should be used where an API request to be done. This will ensure that
core common variables are preserved so that it cannot be tampered by API‟s
2. DAS should be used for selecting records from applications. No Direct SELECT should be used.
This will have a control on SELECT‟s performed on applications are permitted by application owner.
13.2.2 Insecure Storage

1. Data should be in database files and not directly directory structure of T24 – E.g. writing directly
to run directory should be avoided.
Navigation for KB Secure coding standard‟s page link

http://uni-t.temenos.com/teams/DA/Product Standards/Product - Secure Coding standards - T24.pdf
14. FILE HANDLING
File handling defines the way how to handle files and make call to files using F.READ , F.WRITE and other
available commands which are basically defined in the core API. These files simply replace the use certain
base commands or statements and also increase the performance of the routine.
1. When F.READ is used to read a file, all the arguments in the F.READ should be initialized. No
empty braces should be used instead of arguments.
CALL F.READ (FN.ACCOUNT, ACCOUNT.ID, R.ACCOUNT, F.ACCOUNT, ” “)
CALL F.READ (FN.ACCOUNT, ACCOUNT.ID, R.ACCOUNT, F.ACCOUNT, ACCOUNT.ERR)
2. While updating CORE files and other files like ACCOUNT, CUSTOMER use F.READU instead
of F.READ, if you wish to read and lock the record.
E.g;
CALL F.READU (FN.ACCOUNT, ACCOUNT.ID, R.ACCOUNT, F.ACCOUNT, ACCOUNT.ERR,““)
3. F.READ or READ on PARAMETER FILES to be replaced by CACHE.READ. This is because,

F.READ reads from the database whereas CACHE.READ reads from the cache memory. Parameter
files by nature are static records in the database and hence accessing these files is quick when
CACHE.READ is used.
E.g:
CALL CACHE.READ ( FN.IS.H.PARAMETER, Y.PROD, R.IS.H.PARAMETER, IS.ERR )

4. READ or F.READ or CACHE.READ on SPF file to be removed. Instead use the common
variable R.SPF.SYSTEM
5. Use F.DELETE to delete a single record form a file. Do not use multiple F.DELETE to delete
records from the file.
E.g:
CALL F.WRITE(FN.ACCOUNT.PATH,ACCOUNT.FILE.PATH.ID,R.ACCOUNT.FILE.ERR)
CALL F.DELETE(FN.ACCOUNT.FILE.PATH,R.ACCOUNTL.FILE)
6. Use EB.CLEAR.FILE when you want to clear a file or delete selected records from a file.
7. In case there is a need to bypass T24 subroutines to perform delete (F.DELETE) and write
(F.WRITE), the syntax in these statements must avoid ELSE and THEN statements.
8. Use F.MATREAD instead of F.READ to read a dimensional array from a file.
E.g:
CALL OPF(FN.ENQUIRY.REPORT,F.ENQUIRY.REPORT)
CALL F.MATREAD (FN.ENQUIRY.REPORT, Y.ENQ.ID, MAT R.NEW, 100,
F.ENQUIRY.REPORT, ENQ.REP.ERR)
9. Use F.WRITE command instead of WRITE to write a file. When WRITE is used each record will be
individually updated in database. Whereas when F.WRITE is used, it will update records in cache
memory initially and then update the entire records in database once the cache size exceeds the
maximum capacity
10. When audit fields needs to be updated on LIVE record and HISTORY needs to be updated on $HIS
record file use F.LIVE.WRITE. Since this is wrapped around a CALL to external subroutine
AUTH.AND.HIST.WRITE, updates are processed automatically.
11. When using audit field checks, care should be table to include multi-value checks based on the setup
in SPF record for DATE.TIME field. In general, care should be taken in the code to consider if the
field is multi-value or sub value and then should be used appropriately
12. Use F.MATWRITE instead of F.WRITE when you actually write a dimensional array (records) into a
file.
13. Avoid using F.LOAD & F.MATLOAD to refresh the Read and Write Cache without doing a Write
14. Release of Lock on Data file should be done using F.RELEASE and avoid using RELEASE directly.
15. When audit fields needs to be updated on LIVE file record and HISTORY file needs to be updated on
$HIS file record file use F.LIVE.MATWRITE. Since this is wrapped around a CALL to external
subroutine AUTH.AND.HIST.WRITE, updates are processed automatically.
16. When current transaction needs to be cancelled use TRANSACTION.ABORT .It also clears deferred
writes and releases locks.
17. Use the routine EB.NO.OF.MONTHS to arrive the number of months between two specified date
records. Syntax :- SUBROUTINE EB.NO.OF.MONTHS(START.DATE, END.DATE,
NO.OF.MONTHS)
18. To read Parameter files use EB.READ.PARAMETER as it has the intelligence of returning correct
parameter setup in a Multi Company installation.
19. Avoid using EB.READLIST routine for selecting data files
20. To get calendar days for days displacement use the core routine CALENDAR.DAY
21. To cycle dates always use the core routine CFQ
22. Use the routine WORKING.DAY for any calculation with respect to working day for a business day
definition
23. Use the core routine AWD to check if a given date is a holiday or working day
24. Use the core routine DIETER.DATE to convert dates from the format used throughout T24
(YYYMMDD) to the standard jBASE format (either internal or external. External dates formatted as
per jBASE CONVERSIONs)
25. Use GET.CURRENCY.RECORD for getting the Currency record and Do not get the details by directly
accessing the file. To read a history CURRENCY record please use the core API
GET.CCY.HISTORY. To get a specific static values from of currency table use the UPD.CCY
26. To get Currency Market details for Particular product and specific movement, FIND.CCY.MKT should
be used.
27. To format a currency amount to the respective decimal places use the routine
SC.FORMAT.CCY.AMT.
28. Enquiry Subroutine E.GET.LOCAL.AMOUNT can be used to calculate the local currency equivalent
using MIDDLE.RATE.CONV.CHECK.
29. For getting interest rate of Periodic interest setup TERMRATE routine need to be called.
30. For getting interest rate for BASIC.INTEREST rate setup, EB.GET.INTEREST.RATE need to be used
31. To get the Number of days for Interest processing for a Interest basis, routine BD.CALC.DAYS should
be used.
32. No direct read is allowed on the file ACCT.ACTIVITY table always use the routine
EB.GET.ACCT.ACTIVITY to read the values
33. Any read or write to EB.CONTRACT.BALANCES should use EB.READ.CONTRACT.BALANCES and

EB.WRITE.CONTRACT.BALANCES.
34. Use the routine INT.ACC to check if a given account number is an internal account number
35. To validate the category of an account with ACCOUNT.CLASS use the routine
CHECK.ACCOUNT.CLASS
36. Any read or write to EB.CONTRACT.BALANCES should use EB.READ.CONTRACT.BALANCES and

EB.WRITE.CONTRACT.BALANCES.
37. For getting the external Account details for the respective Nostro account from AGENCY file, the
routine GET.EXT.ACC.NO should be used.
38. EB.ROUND.AMOUNT routine to be used for all rounding off variables
39. Getting the details on whether the Particular application is in Trade dated or Value dated, use the
routine AC.VALUE.DATED.ACCTNG.
40. Use E.GET.STMT.NARRATIVE to return a calculated statement entry narrative for enquiry purposes.
The narrative is calculated according the definitions in TRANSACTION, STMT.NARR.FORMAT and
STMT.NARR.PARAM.
41. Use GET.NARRATIVE to return calculated statement narrative using TRANSACTION,

STMT.NARR.PARAM and STMT.NARR.FORMAT applications.
42. To get the Accounting entries for a Contract for a particular date range, use the routine
EB.GET.CONTRACT.ENTRIES.
43. Use the routine EB.GET.ENTRY.DETAILS for the reconciliation entries for a Consolidated entry.
44. Conversion of Amount with respect to Limit currency should use the routine LIMIT.CURR.CONV.
45. To get Account balance for checking Overdraft purpose use the routine GET.WORKING.AVAIL.BAL.
46. Use LIMIT.CHECK from applications both online and end of day to verify and update the limits
system. The application is required to supply the correct values from the transaction in order to give
the correct update to the system.
47. Use LIMIT.GET.PRODUCT from applications to validate and default the Limit Reference used in a
given transaction.
48. T24 Interest Accrual processing should use EB.PERFORM.ACCRUAL for calculating the Interest.
49. Charge Accrual process should use the routine EB.ACCRUAL.UPDATE to update Accrual
information in Entry array to initiate e Core Charge Accrual process.
50. Any read to Account related Files which has High Volume should use EB.READ.HVT routine instead
of reading the file directly. This routine will do a notional merge and will give consolidated details.
Below files need to be categorised as High Volume files. Example of some files are STMT.PRINTED,
ACCT.STMT.PRINT, EB.CONTRACT.BALANCES, STMT.VAL.ENTRY
51. Getting details on GL asset types should use the routine RE.TYPES.
52. GL setup details from CONSOLIDATE.COND should use the routine

RE.READ.CONSOLIDATE.COND.
53. Any GL related setup file for an Application need to use the routine RE.APPLICATIONS to get the
details for CRF key formation.
54. Asset type Validation should use the routine AC.CHECK.ASSET.TYPE.
55. To check an Account for Contingent use the routine AC.CONTINGENT.
56. Any cash flow update from contract should use the routine EB.CASHFLOW.HANDOFF to update the
contract cash flow in relevant file.
57. To get Credit check setup of the system for Account Cashflow use the routine GET.CREDIT.CHECK.
58. For getting Group from the group setup for XX.GEN.CONDITION setup , use the routine EB.GROUP.
59. The routine CALCULATE.CHARGE need to be used for any Charge , commission and Tax
calculation in T24.
60. Routine APPL.GRP.CONDITION need to be called when we need the details of Contract group for
an application based on XX.GEN.CONDITION setup.
61. Where there is a processing of data that belong to other company in a Multi company environment,
use LOAD.COMPANY to load and Company basic Data like ID.COMPANY, R.COMPANY, DATES
etc. They variables should not be set directly without calling LOAD.COMPANY.
62. Use GET.ACCOUNT.COMPANY to get the Company of an Account.
63. Get the Branch details of an Account using GET.ACCT.BRANCH.
64. Use FIND.CHARGE.REC to get CUSTOMER.CHARGE details for customer.
65. Any routine called from T24 hooks should be called after checking whether the routines exists using
CHECK.ROUTINE.EXISTS.
66. System Cache uses inbuilt FUNCTIONS and provide better performance.
•Use System.fetchFromCache to retrieve value for a table provided key to table is known.
•Use System.putCache to load the record in specified cache bucket
•Use System.getCache to retrieve value from a bucket
•Use System.deleteCache to delete an item from bucket .
Care to be taken when deleting cache only if functionality is not required
67. Use FIELD.NAMES.TO.NUMBERS for converting the Standard selection field names to numbers.
For doing vice versa use the routine FIELD.NUMBERS.TO.NAMES
68. To check whether an application is NS enabled, use the routine NS.CONTRACT.CHECK.
69. Any Manipulation of common Variables should call COMMON.SAVE before processing and use
COMMON.RESTORE after processing.
70. Avoid using OFS.GLOBUS.MANAGER. Instead use OFS.POST.MESSAGE to posts a message to

an OFS queue which will be processed by the OFS message service.
71. Use EB.CLEAR.FILE to either clear file or selected data in a file.

72. Use EB.FORMAT.RATE to format rate values depending upon the system settings. If extended
precision is on, the maximum no. of decimals allowed is 9 else it is 6. Total no of digits allowed for a
rate value is 11.
73. Use EB.LOCREF.SETUP to get data based on local reference setup in an application.
74. Use GET.SETTLEMENT.DEFAULTS to get the default account and settlement details for a
particular customer and application. Defaults may be obtained from Portfolio SEC.ACC.MASTER,
AGENCY, CUSTOMER.CCY.ACCT or NOSTRO.ACCOUNT files.
75. Use EB.GETFIELD to retrieve a field or a set of fields from the current application record, another
record within the same file or from another file using literal field names.
76. Use EB.OBJECT application for fields like ACCOUNT, DEPT.ACCT.OFFICER etc where length of
field can be changed at EB.OBJECT definition across applications
77. Avoid using direct input commands through TXTINP, REM as User intervention is needed which is
against T24 browser principles
78. Avoid using PRINT and CRT statements as it will simply display nothing in the user interface
79. Avoid using INPUT statement as the user cannot feed any data for the command and hence will
lead the session to hang and/or terminate abnormally
80. Use UPDATE.HEADER to set enrichment against ID / Header details which is compatible with
Desktop and browser interfaces
81. Please use EB.OVERRIDE.TOOL if any specific browser tool to be overwritten due to business
functionalities
82. It is recommended to use the variable SESSSION.NO to fine tune any record ids
83. No SELECTS to be found within any looking structure or iterative processing.
84. There shall never be more than two levels of iterative processing. This is not from a performance
perspective but from a code readability . However, if the level is more than two levels required, then
branch out for better readability. Earliest opportunity to break out of a loop shall be considered and
not a ceremonial completion of the iteraction
85. Key to a table where a lock is being acquired should never be a constant
86. The argument to F.READU for retry shall be passed as null unless the calling program has logic to
handle the locking failure
87. Locking should not be applied for keys that gurantee uniqueness example SESSION.NO
88. User F.READU to lock a record which is already being read.
89. Do not write batch routines to be run the ONLINE stage of the COB rather do the same as service
running during the intra day.
90. Do not alter core variables such as CACHE.OFF/WRITE.CACHE/ RUNNING.UNDER.BATCH shall

never be tampered in application programs
91. Bulking shall be enabled in jobs only when the underlying transaction does not do heavy
processing. (no rule here but good example would be accounting jobs are never put under bulk
processing in COB ) or for jobs that do not do contentious locks
92. No log file is written by applications without a provision of parameter to turn on/off the log
93. Do no use a direct call to the System.getCache routine in the local routines.
94. Do not set HOT.FIELDS in field definitions. Always use them at version level validations.
95. Multiple calls to EB.ACCOUNTING from a single transaction/message has to be avoided.
96. LOCATE causes performance issues as it needs to scan through entire value and hence use it only
if it cannot be avoided
97. Before reading a record, check for availability in common variables – eg

Global/Product/Application/Batch commons etc and use it.
98. Concat files are not good but if it is on a static table and it helps selection it is fine to use. It has to
be on case to case as the introduction of concat should not end up in locking contentions.
99. Avoid using VERSION AND VERSION.CONTROL routines for local template. All validations should
be done in .VALIDATE or .AUTHORISE routines
100. Following below needs to be avoided / considered when building a SELECTS
 No SELECTS should be written when you activation list concept

 Do not hardcode the select for bulking. Specify them in the PGM.FILE
 Avoid selection on huge files like STMT.ENTRY, CATEG.ENTRY
 Do not do a READ operation inside a .FILTER routine
 Use I_BATCH.FILES if you are using common variables for BATCH variables
 Do not modify the incoming argument in a record routine unless you want to add a new
ID to the job list
 Avoid using SELECTS or any selection on field names if this is really not necessary.
Selection on @id is much faster than selection done on fields
101. For TAFJ related calls being done always assign the routine name to a variable and then
use the @ symbol to make calls to the routine. This is to avoid TAFJ compilation error
102. In TAFJ, Do not specify the length of a record ID more than 200 characters. Failing to
adhere to this standard will cause the driver to throw ID constraints error at runtime
103. In TAFJ, Always execute online or batch related service using the standard TAFJEE servlet
which will increase the performance of the jobs running rather than in a classic session for a TAFJ
environment.
104. In TAFJ, usage or variable increment like i++ should be avoided. Explicit imcrementing of
variables like i = i + 1 should be used in the codes
105. In TAFJ, The use of CALLJ is obsolete, hence please do not use CALLJ instead CALLJEE
is enabled for any messages to be posted to queues. Below is the syntax for CALLJEE
CALLJEE(ACTIVATION, INFO)
ACTIVATION Specifies the activation string
INFO  Contains the message string to be posted
106. In TAFJ, there are only certain ITYPES supported. Hence

 Any Itype that begins or contains SUBR
 Any IF Itype that contains ENQ.TRANS OR SUBR
 Any IF Itype that doesn’t start with IF
All the above should be avoided in TAFJ coding
107. In TAFJ, Avoid hardcoding any characters like ‘{‘ and comparing the same using
MATCHES function
For Example IF X MATCHES ‘{‘ will fail to produce the result when internalisation is turned on as
UNICODE representation of ‘{‘ defers based on the where UTF8 is turned on or off. For TAFJ there
is no specific handling as by default TAFJ is UTF-8
15. EXCEPTION HANDLING
Exception handling is a programming language construct or computer hardware mechanism designed

to handle the occurrence of exceptions, special conditions that change the normal flow of program or
subroutine execution.
R.REDO.CCRG.RL.BAL.MAIN = ''
CALL F.READ (FN.REDO.CCRG.RL.BAL.MAIN,Y.CUSTOMER.ID,R.REDO.CCRG.RL.BAL.MAIN,
F.REDO.CCRG.RL.BAL.MAIN,Y.ERR)
END
R.REDO.CCRG.RL.BAL.MAIN =
'' CALL F.READ
(FN.REDO.CCRG.RL.BAL.MAIN,Y.CUSTOMER.ID,R.REDO.CCRG.RL.BAL.MAIN,F.REDO.CCRG.
RL.BAL.MAIN,Y.ERR)
IF NOT(R.REDO.CCRG.RL.BAL.MAIN) THEN
Y.TEXT = "ST-REDO.CCRG.BAL.NO.EXIST.BY.CUSTOMER"
CALL TXT(Y.TEXT)
ENQ.ERROR<-1> = Y.TEXT
PROCESS.GOAHEAD = 0
END
FATAL ERROR HANDLING
R.INTERFACE.PARAM = ''
INTERFACE.PARAM.ERR = ''
CALL CACHE.READ
(FN.INTERFACE.PARAM,'STAMP.DUTY.IND',R.INTERFACE.PARAM,INTERFACE.PARA
M.ERR)
OUTPUT.DIR = R.INTERFACE.PARAM<INTF.OUTBOUND.PATH>
IF INTERFACE.PARAM.ERR NE '' THEN

MESSAGE.INFO<3>='IDA.STAMP.RPT.GEN'
MESSAGE.INFO<4>="Cannot find the record STAMP.DUTY.IND in
INTERFACE.PARAM table"
TEXT = "Please create the record STAMP.DUTY.IND in INTERFACE.PARAM
table" MESSAGE.INFO<1>='IDA.STAMP.RPT.GEN'
MESSAGE.INFO<2>=''
MESSAGE.INFO<5>='YES'
CALL FATAL.ERROR
(MESSAGE.INFO) END
16. MULTITHREAD ROUTINES
Multithreading in T24 is all about sharing the load or in other words task to be executed. One process at
system operating level processing at list of id‟s will be slower than multiple copies of same process
processing on the list of id‟s.
This section explains the do‟s and dont‟s that needs to kept in mind before adopting multithreading concept
in the routine,
1. In a multithread routine, there should be a call to BATCH.BUILD.LIST in the SELECT routine

which contains the selection list as its arguments.
E.g:
SEL.CMD = "SELECT ":FN.ACCOUNT:" WITH CATEGORY EQ 1001"
CALL EB.READLIST(SEL.CMD,SEL.LIST,'',NO.OF.REC,RET.CODE)
CALL BATCH.BUILD.LIST(„ „,SEL.LIST)
2. When requirement of the job is to perform different operations in sequence with the ability of the job
to run parallel, CONTROL.LIST common variable can be used. CONTROL.LIST is initialized in the
SELECT routine, which invokes the select routine for n number of times thus sequencing the different
jobs within which every job can have parallel processing..
3. The SELECT routine should contain only the CONTROL.LIST common variable and the SELECT
statement to be executed. Do not define the process of the routine in SELECT statement. This is
because, the select routine is executed only with one agent and hence defining the entire process of
the routine in SELECT routine may cause serious performance issue. Define the process of the
routine in the RECORD (PROCESS) routine.
4. For multithread routines, do not use OPF in the PROCESS routine. This is because PROCESS
routine is executed by number of agents, and hence the performance of the routine may go slower.
So all OPF calls should be made in the LOAD routine since LOAD routine is executed only once and
all the agents running the PROCESS routine will pick up the files from the LOAD routine.
5. For multithread routines, variables must not be initialized in POST routine. This is because, if the
POST routine is executed with any other agent other than the one which executed the load routine,
then the variable holds only NULL value.
6. For Multithread Routines, Do not use MULTI.GET.LOC.REF in the RECORD Routine. Kindly use
CALL MULTI.GET.LOC.REF in the .LOAD Routine.
7. For Multithread Routines, Do not use CACHE.READ in the RECORD Routine. Kindly use
CACHE.READ in the .LOAD Routine
17. CORE ROUTINES
Core routines are the routines that are developed inside T24 which cannot be modified but can be used in
the in the program by calling the routine.
Core routine reduces redundant set of statements that are called repeatedly and also reduces the
complexity of the routine. Hence there is no need to code the statements instead simply make a call to the
routine and pass the arguments For example, core routine CDD can be used to calculate the difference
between two dates which not only reduces the complexity of routine but also reduces the time required to
code these routines.
17.1DATE ROUTINES
This section defines the set of core routines that can be used to calculate either forward or backward dates.
1. When date routine CDD is used, it calculates the difference in dates when two dates are supplied.
The return argument is the number of day‟s difference.
E.g:
IF LAST.INT.SCHED LE VAL.DATE THEN
PERIOD = 0
NO.OF.DAYS = 'C'
CALL CDD("",VAL.DATE,TODAY,NO.OF.DAYS)
CD.PROCESS = '1'
END
2. Call to routine CDT, calculates the forward or previous date from the
start Date and number of day
E.g:
IF DATE EQ TODAY THEN
NO.OF.DAYS = '+3C'
CALL CDT(" ",TODAY,NO.OF.DAYS)
CD.PROCESS = '1'
END
3. Call to routine JULDATE will convert Julian date to Gregorian date or vice versa depending on which
date is passed as argument in the routine. The other date must be NULL.
E.g
GREG.DATE = ''
TEMP.DATE = TODAY
CALL JULDATE(GREG.DATE,TEMP.DATE.VAR)
17.2VALIDATION ROUTINES
This section defines validation routines that can be used for validating particular field,
1. For checking the duplicate occurrences of values in multi and sub valued fields at cross validation,
call to DUP routine can be enabled.
2. For validating a particular field whether, the field is multi-valued or sub-valued or null valued, call to
FT.NULLS.CHK routine can be enabled.
18. EXCHANGE RATE
This section explains the available core routines that can be used for calculating the exchange rates
1. To calculate the exchange rate between foreign and local currency, call to the routine CALC.ERATE.
foreign currency and foreign currency amounts are passed as the incoming arguments.
2. Call to the routine CUSTRATE performs all tasks involved in foreign exchange on two currencies on buy/s
3. Call to the routine EXCHRATE performs all tasks related to foreign exchange of two currencies
4. Call to the routine FCY.CONVERT.CHECK performs the following functions like,
1) Converts the local currency to foreign currency or vice versa when either of the currency amounts
2) Calculates exchange rates when both local and foreign currency amounts are passed,
3) Recalculates local and foreign amount and returns the difference,
4) Calculates percentage exchange rate difference, when a rate is passed.
19. COB ROUTINES
This section explains the criteria that should be considered while writing COB routines,
1. All new batch records must have an equivalent record in BATCH.NEW.COMPANY application.
2. All new batch process should be written to use multithreading.
3. Do not test the SPF status of the routine during the COB procedure because this will be set as soon
as the COB is initiated. So the routine doesn’t know if it has been invoked from „action line‟ or run as
a part of the routine.
4. Do not call template programs from batch. Isolate the program you require into subroutine and then
call the subroutine and the template program
5. Never prompt during Close of Business. Use “OCOMO” instead of CRT to record the progress of the
job
6. Do not use HUSH or! HUSHIT since the output from the commands are very useful in analyzing
the COB execution.
7. Never use “STOP” to terminate a batch process. Always use “FATAL.ERROR” to terminate a
batch job when error condition occurs.
8. The FATAL.ERROR should be used with proper text only if you don‟t want the COB process to
proceed. This will log the errors in EB.EOD.ERROR. For low level errors, EXCEPTION.LOG can
be used to flush the errors.
20. CORE REUSABLE ROUTINES
The other available core routines in T24 which can be used in the routine are as follows,
1. The available core routine EB.ACCT.ENTRY.LIST can be called to get the list of statement entry
details provided the account number, start date and end date is provided as incoming arguments to
the routine.
CALL EB.ACCT.ENTRY.LIST (ACCOUNT.NUMBER, FROM.DATE, END.DATE, YID.LIST,

OPENING.BAL,ER)
2. The Core routine EB.READ.WRITE.TABLE can perform Read, Write and Deleting of a Table
Records with large elements. Let‟s say for example more than 1000 data‟s in a Record, Pass the
Application
Id, Application Name, Option for Read, Write, Delete Single, or Delete , and Data for which the
action to be performed. 1000 data‟s will be broken in 5 records of 200 each, whereas the Ids of
previous and next related records are stored in 201 and 202 field of the current record.
CALL EB.READ.WRITE.TABLE (APPS.ID, APPS.NAME, RD.WRITE.DEL, IN.DATA, OUT.MSG

3. Before running COB, if user want to verify the unresolved Errors of the last COB, then routine
EB.EOD.UNRESOLVED.ERR can be used which gives the list of errors for the date inputted,
EB.EOD.ERROR Record id must be passed as an Input, where as the EB.EOD.ERROR id, is the
combination of Company Id and Date
CALL EB.EOD.UNRESOLVED.ERR (UNRESOLVED.FLAG, RECORD.ID)
4. The core routine EB.VALIDATE.FREQUENCY will validate a frequency supplied in short frequency
format (M0101/D/W). It will validate the values entered and return the corresponding entry.
CALL EB.VALIDATE.FREQUENCY (IN.FQU, OUT FQU, ERR.MSG)
5. The routine EB.HIST.REC.WRITE helps to write a new record to a live file while moving the
existing record to history file.
CALL EB.HIST.REC.WRITE (FILE.NAME, RECORD.ID, MAT RECORD, RECORD.LENGTH)
6. The subroutine EB.GET.ACCT.BALANCE is used to return the balance of an account on a requested

date. We can also get the CREDIT and DEBIT movement on this date.
CALL EB.GET.ACCT.BALANCE (ACCT.ID, ACCT.REC, BALANCE.TYPE, BALANCE.DATE,

SYSTEM.DATE, BALANCE, CREDIT.MVMT, DEBIT.MVMT, ERR.MSG)
7. The routine EB.DATE.FORMAT.DISPLAY displays date in alphanumeric format. If a value of

„20080102‟ is supplied, it will return as „02 JAN 2008‟.
CALL EB.DATE.FORMAT.DISPLAY (DATE.VALUE, DATE.DISPLAY

Standards
8. The subroutine EB.FORMAT.RATE simply formats the rate supplied. It extends the decimal places to
9 digits (following by 0‟s) else truncate and round off decimal places, if it‟s more than 9 digits, then
leading 0‟s are replaced.
CALL EB.FORMAT.RATE (RATE)
9. The routine EB.COPY.LOCAL.FIELDS is used to copy data of local reference fields to another
application. Input arguments would be the ID and application of source and destination. Output would
be record with local reference fields from source record.
CALL EB.COPY.LOCAL.FIELDS (APPS.ID.FROM, APPS.FROM, APPS.ID.TO, APPS.TO,TO.REC)
10. The routine EB.INTEREST.BASIS can be called in any process when we need the description or
interest basis text for corresponding interest basis. Input argument would be the interest basis ID and
output would be the interest basis text.
CALL EB.INTEREST.BASIS (INT.BASIS, INT.BASIS.TEXT)
11. The subroutine GET.NOSTRO.CUST can be invoked to get the customer ID of a given
NOSTRO.ACCOUNT. It checks LIMIT.REF field is NOSTRO in the account application and will give
customer id as output.
CALL GET.NOSTRO.CUST (NOS.ACC, NOS.CUST.ID)
12. The subroutine EB.CALL.JAVA.API is used to call java API from EB.API. Suppose if the EB.API file
is having an entry and source type as java then this is the routine used to call Java API.
EB.CALL.JAVA.API routine has the following function

1) It will check the EB.API having the value in JAVA.PACKAGE, JAVA.CLASS,
JAVA.METHOD
2) If the above fields are having value and source type is equal to JAVA then this
routine will trigger the CALLJ engine through EB.CALLJ routine
CALL EB.CALL.JAVA.API(EB.API.ID,CALLJ.ARGUMENTS,CALLJ.RESPONSE, CALLJ.ERROR)
13. The subroutine EB.CALC.REPAYMENT is used to calculate the repayment amount for a particular
contract by providing the appropriate data like principle amount, currency, annual rate of interest and
interest basis etc.
CALL EB.CALC.REPAYMENT (PRIN, CCY, RATE, LIFE, FREQ, TYPE, INTEREST,

RESIDUAL.AMOUNT, START.OR.END, DAY.BASIS, ROUNDING, REPAY.AMOUNT)
14. EB.LEAP.YEAR is a subroutine to find out whether the year is a Leap year or not. If year and T24
Internal date is passed to check for leap year, It will send the Leap year YES/NO flag through the
output parameter.
CALL EB.LEAP.YEAR (I.YEAR, I.DATE, LEAP.YEAR, NO.DAYS.IN.YEAR, CONTROL.VAR,

RES1, RES2)
15. The routine EB.MSK.FIELDS is used to mask the field values, from its original value based on the
application and record id supplied. It is used for scrambling the area. For E.g., If the banks want to
mask the data‟s with a mask characters in a report for particular record, it is possible using this API,
by passing the Application name, Record Id, Fields to be masked, which will return the record data
with the masked characters.
CALL EB.MSK.FIELDS (APP.NAME, RECORD.ID, R.RECORD, MASK.FLD.LIST,

APPL.MSK.CHARS)
16. The routine GET.CCY.HISTORY is used to find the values of the CURRENCY record or
FORWARD.RATES record in a historic date supplied. If the date passed does not match, it will return
the earliest or nearest match, where as it will tell using RETURN.CODE
CALL GET.CCY.HISTORY (HIS.DATE, YCCY, CCY.DATE.REC, RETURN.CODE)
17. The routine EB.IN2.CALL is used to validate any value against T24 IN2 Routines. The value to be
validated is passed from COMI and incase of any Error, ETEXT will hole the error message, it
performs two types of validation, ID and Field level validation, which is mandate to be mentioned.
CALL EB.IN2.CALL (INPUT.TYPE, N1, T1)
18. The routine EB.GET.OVE.ERR.ID generates a unique error/override number code to be attached in
the error/override record. Simply increment the counter value in F.LOCKING file.
CALL EB.GET.OVE.ERR.ID (ACTION, THE.ID)
19. The routine EBS.CREATE.FILE is used to create DATA and DICT files. We can specify the path
where the DATA file to be created. We can also specify the type and modulo. It is mainly used to
create files for archiving.
CALL EBS.CREATE.FILE (FILE.TO.CREATE, DATA.OR.DICT, ERROR.MSG)
20. The routine EB.RECORD.MOVE is used to delete a record from a LIVE file based on the values in
the incoming arguments and write the record back to the history.
CALL EB.RECORD.REMOVE (FILE.ACTION, REC.ID, RET.CODE)
21. The Core routine EB.CALC.TERM is called to return the number of due payments provided principal
amount, currency, rate of interest, repayment amount are passed as incoming arguments in the
routine.
CALL EB.CALC.TERM(PRIN, CCY, RATE, LIFE, FREQ, TYPE, INTEREST,

RESIDUAL.AMOUNT, START.OR.END, DAY.BASIS, ROUNDING, REPAY.AMOUNT)
22. The Core routine EB.GET.APPL.FIELD can be called to return either the field number or field name
from the Standard Selection table if either of these fields is provided as argument for the called
routine.
CALL EB.GET.APPL.FIELD (APPL.NAME, FLD, R.SS, ERR.MSG)
23. EB.READ.HISTORY.REC is used to READ the HISTORY FILES.
CALL EB.READ.HISTORY.REC
(F.FUNDS.TRANSFER.HIS,TEMP.FT.REF,R.FUNDS.TRANSFER.HIS,FUNDS.TRANSFER.HIS.ER R)
24. Do not use CALL OPF for STANDARD.SELECTION. Kindly Use Core API.
CALL GET.STANDARD.SELECTION.DETS (X.APPLICATION, R.STANDARD.SELECTION)
25. Kindly use OFS.CALL.BULK.MANAGER () instead of using OFS.BULK.MANAGER ().
26. Use Public API ofs.addLocalRequest (...) for BULK OFS Transaction
21. UTILITY ROUTINES
Utility routines are developed as part a local development. These routines can be called from any
program by passing proper arguments. For further clarifications, refer the RAD Utility Document.
1. COMP.ACCT.BALANCE :
The routine COMP.ACCT.BALANCE is used to compare the online cleared balance and working
balance of the account. If the online cleared balance is not equal to working balance and working
balance is greater than online cleared balance, the results are taken out.
2. CHECK.ADI.FOR.AC:
The routine CHECK.ADI.FOR.AC is used to check the debit interest for the account. This subroutine
can be used to get ACCOUNT.DEBIT.INT records which are used to calculate interest amount for the
group of customers
3. GET.T24.FILE.LIST:
The utility program GET.T24.FILE.LIST is used to list down all the files present in VOC. This can be
used when there is a need of all the files in T24, their size, product code, size, record count, and file
type. The output of the program is stored in the &SAVEDLISTS& file..
4. GET.CUST.ACCT.DETS:
The routine GET.CUST.ACCT.DETS , is a called subroutine, with one I/O Argument. If the Customer
number is passed as input, it will return the list of accounts for that customer. If customer is not
available it will return the error.
5. S.MONITOR.COB.TSA:
The program S.MONITOR.COB.TSA is used to monitor the agents during close of business. It
accepts agent number and display the details of COMO. It will also accept the time delay which we
should refresh every time. The system will check for each selected record whether the agent is in the
monitored list.
6. LOC.DEV.LISTING :
The utility routine LOC.DEV.LISTING will provide list of details about the given BP can be fetched
through the routine. The details are Routine Name, Code lines of the Routine, Command lines of the
routine, total number of lines and code efficiency of the routine. At last .CSV file will be created with
the routine details in &COMO&
7. GET.CATEG.LIST :
The GET.CATEG.LIST is used to get the list of Category Entry for the supplied Category within the
range of given Booking date, consolidate the category for a date and sum up the Amount Lcy and
Fcy, along with STMT.ENTRY Id‟s.
8. GET.LOCKED.EVENTS :
The mainline routine GET.LOCKED.EVENTS, is used to display the unlocked amounts for the given
date and descriptions. Data is retrieved from the application, AC.LOCKED.EVENTS..
9. VIEW.JOB.LIST :
The utility routine VIEW.JOB.LIST is used to get and display the job lists count and Ids; Job List start
and end number is inputted by the user. This is very useful while running COB, and multi threaded
Services.
10. PROCESS.ACTIVITY.MONITOR :
The info basic program PROCESS.ACTIVITY.MONITOR is used to monitor the process, commands
or background activities. E.g., SELECT, COUNT. Output will be updated in the log file
PROCESS.ACTIVITY.MONITOR.LOG.
11. PROCESS.MONITOR:
The info basic program PROCESS.MONITOR is executed from jbase prompt to monitor the process
and update the log file in the given frequency.
12. ADD.FUNC.TO.SMS:
The routine ADD.FUNC.TO.SMS is used to add a function to a record in USER.SMS.GROUP. The

routine must be called from T24, along with the USER.SMS.GROUP id and the function (A B 2 C D E
H I L P Q R S V) to be included in that record.
13. GET.ROUTINE.DETAILS
The routine GET.ROUTINE.DETAILS is used to get the list of all files and find out the location of the
actual code; it takes the full path of a „lib‟ as argument. It opens the respective „objdir‟ under that „lib‟
to process all „obj‟ files to find the actual location of each file.
14. VERSION.RTN.DETAILS :
The routine VERSION.RTN.DETAILS is used to get the various routines attached to a specified
version. It takes an array with list of version to be processed. The result will be stored in .csv file
under a specified directory.
15. SYSTEM.APPL.SEARCH:
The routine SYSTEM.APPL.SEARCH is used to find the occurrence of local routines in various
applications. It also searches various BP‟s to return the list of routines calling this routine. It takes the
list of routines and BP to process and return with the .CSV file that contains occurrence of routine in
various applications and list of routines which call this.
16. GET.PROGRAM.DETAILS.JBASE :
The routine GET.PROGRAM.DETAILS.JBASE is used to get the details of routines using „jshow -
c‟ command. It checks for
I. Whether the routine compiled or not
II. Have VOC entry or not
III. Is the local or core program
IV. Compiled BP and Source BP details
V. Core duplicate or not
17. GET.VERSION.DETAILS :
The routine GET.VERSION.DETAILS is used to get the details of all versions. It process each routine
attach to the various field of version (INPUT, AUTH, ID, VALIDATION, etc.). For each routine it gets
the following details,
Whether the routine compiled or not
Have VOC entry or not
Is it a local or core program
Compiled BP and Source BP
details Core duplicate or not
All details are written to a file named „VERSION.LIST‟ under a directory

AA – THINGS TO REMEMBER
22. LOCAL COMMONS in AA
AA has a defined set of variables which are exposed as commons to be used in Local APIs. These
are available in I_AA.LOCAL.COMMON. The following are the details of these variables:
c_aalocArrId, ;* Arrangement id
c_aalocArrangementRec, ;*Main arrangement record
c_aalocArrProductId, ;* Stores the product used by the arrangement
c_aalocArrCurrency, ;* Store the currency used by the arrangement
c_aalocActivityId, ;* Activity id loaded in the property
c_aalocTxnReference, ;* Arrangement activity transaction reference
c_aalocCurrAction, ;* Current action being processed by action manager
c_aalocArrActivityRec, ;* Current arrangement activity record
c_aalocLocalRefList, ;* List of local ref fields
c_aalocCurrActivity, ;* User/System generated activities
c_aalocLinkedAccount, ;* Linked Account id
c_aalocProductRecord, ;* Stores the published product record for the arrangement
c_aalocPropClassId, ;* Property class ID of current property
c_aalocPropertyId, ;* Current property
c_aalocProdPropRec, ;* Stores the published product property for the arrangement
c_aalocActivityStatus, ;* Stores the status of current activity like . UNAUTH, DEL, REV-DEL
c_aalocArrActivityId, ;* Store the arrangement activity id
c_aalocActivityEffDate, ;* Effective date
c_aalocAccountDetails, ;* Account Details

23. VERSIONS and APIs in AA
1) No routines should be defined in the versions defined in ACTIVITY.PRESENTATION. The

versions should only define screen layout.
2) Pre and Post routines (if any) are called during all stages of template – like Input, Delete,
Authorization, Reversal etc. Hence the developer should branch the control to specific codes
in the local routine.
3) Avoid using AA commons in the local routines. Equivalent local common variables have been
released use these common variables (Refer the insert file I_AA.LOCAL.COMMON)
4) AA Commons if used should never be modified by local routines.
5) Both the Pre and Post routines currently do not have any arguments.
6) Never read the files on Catalog/Arrangement directly using F.READs. Use the API(discussed
later) for the purpose.
7) All arrangement records are dated, For example if a record already exists for 01-Jan and a
new record is currently being updated for 01-Mar, the ID.OLD/R.OLD of the property would
NOT be NULL. They would refer to 01-Jan date and record respectively.
8) AA would not allow modification on an authorised record. When a similar activity is

attempted, system creates a new SEQ number for the date and ID.OLD/R.OLD would refer to
the previous sequence record.
9) When a Change-on-change is performed on a property, system would first delete the record
and then commit the new record. So, do not be surprised if the local code for Delete gets
executed during Input.
10) Usage of R.NEW.LAST should be avoided in Local routines for the reason stated above.
Since delete clears the previous input, the actual Input record would not load R.NEW.LAST
11) Local developers should not assume all requests would hold
OFS$SOURCE.REC<OFS.SRC.SOURCE.TYPE> would hold SESSION even if it is a
browser request. AA mixes SESSION and T24 requests frequently.
12) Even if the user Authorises the request through Browser front-end, the requests are all
processed as Vanilla requests.
13) There would be no local provision to do ID checks or defaulting through .RECORD routine.
All defaults should be driven by product condition.
14) If there is a need to generate secondary or child activity for the given arrangement in the local
routine use the core APIs – AA.GEN.ARRANGEMENT.ACTIVITY.FIELDS and
AA.GEN.NEW.ARRANGEMENT.ACTIVITY (Explained in detail under the section Useful
APIS)
15) A new function – called M- has been introduced. The feature of this function is that it still
flows through the template, but does not leave any trace of its execution. There would not be
any new ids created after a M function has run on the template. M function does execute the
Pre and Post APIs that have been written for the activity. M function does not commit the
property record,
16) Classic and Desktop are not supported - no support for online prompts or displays.
24. CORE TABLES IN AA FOR LENDING
The AA product line which offers retail and lending functionality is LENDING. Temenos has
released the LENDING product line with its required property classes, activities and action routines.
The client can design lending products using the product builders. The activity to create new
arrangements for lending product is LENDING-NEW-ARRANGEMENT. When this activity is triggered
using AA.ARRANGEMENT.ACTIVITY, new arrangement is created with a unique number. New
record is created in the live application AA.ARRANGEMENT.
For lending product lines, the related core application that is affected is ACCOUNT.
Every new arrangement creates a new account record. Account record is the actual contract for the
product (equivalent to LD contract). The arrangement id is stored in the account record. This account
will be accessible only thru AA activities.
AA.ARRANGEMENT
The AA.ARRANGEMENT record stores the static information of the arrangement like
customer, currency, the related application id, the start date of the arrangement, its product and the
product properties. The current status of the arrangement can also be known from this record.
AA.ACCOUNT.DETAILS
AA.ACCOUNT.DETAILS is another live file which holds account and bill information for a given
arrangement. This file holds value date of the arrangement, its drawdown date, maturity date,
payment start date. The bills generated for the arrangement, the bill statuses, payment information,
bills repaid and whether the arrangement is suspend or not – all the above information is stored in
this file
25. TRANSACTION BOUNDARY FOR AA
1. System issues a TRANS.START even before the processing of application starts.
2. Processing issues F.WRITEs, F.DELETEs. These do not go to the disk directly. They are
updated in the T24 IO cache(FWT, FWC, FWF variables)
3. Direct WRITEs and DELETEs DO NOT hit the database directly. Since the transaction is
already in a boundary, system only updates the jBase cache. Local code developers should
keep this in mind.
4. JOURNAL.UPDATE (for templates, these are called in UNAUTH.RECORD.WRITE, and

AUTH.RECORD.WRITE) would flush the T24 cache to jBase cache.
5. System processes multiple transactions(this currently applies only for AA)
6. All updates are held now in jBase cache.
7. If all transactions get processed successfully, system issues a TRANS.END to update the
jBase cache to disk.
8. If any of the transaction fails, system issues a TRANS.ABORT to clear the jBase cache.
9. Please refer to the Core Transaction management document for further details on this.
NOTE: TRANSABORT, TRANSTART, TRANSEND are not to be used anywhere in the local
development code
26. SPECIAL ABOUT AA BATCH PROCESSING
1. There is a single major difference between AA batch execution and other T24 batch
processing. Even whilst executing the scheduled activity, system would always pass through
normal Template route i.e. process activities via AA.ARRANGEMENT.ACTIVITY. All activities
performed either - online or COB - share the same code since they are all executed through
templates. So the way a scheduled Rate change is executed in COB would be no different
from a rate change triggered by the user online. In COB, the AA.ARRANGEMENT.ACTIVITY
would be triggered through an OFS message (since that is the standard T24 methodology by
which a template is accessed if it is not user initiated).
2. Please be noted that currently ALL AA COB jobs are .NTX which means they do not use the
Transaction management initiated by BATCH.JOB.CONTROL. Since AA uses the new
Transaction boundary and there is no difference between Online and COB transactions, it
deviates from the BJC‟s transaction management.
3. Users performing local development should keep this in mind. So, if there is a local API which
gets triggered during –say rate change- the same would be triggered during COB process as
well. If an update is not supposed to happen during COB process, then it is the developer‟s
responsibility to add RUNNING.UNDER.BATCH condition and stop the execution
27. USEFUL APIs
There are lots of core API‟s which are never being used in local codes, which may save time as well
as performance. So try to check the availability in core routine, before coding it locally. Most of the
API‟s are like AC.GET …, FT.GET…, LD.GET… etc.
(e.g.) AC.GET.ACCT.ENT.TODAY.LWORKDAY, can be used to fetch the Entry id‟s from

ACCT.ENT.TODAY,ACCT.ENT.LWORK.DAY.
Find below few AA API‟s which may help in your Developments

The following APIs may be utilised when certain information are required in a local routine:
AA.GET.ARRANGEMENT.CONDITION
This routine can be used by any application to retrieve the property conditions that apply to an
arrangement for a particular effective date (default value is TODAY).
The specific property or property class required must be supplied
The records and ids for the property conditions that apply are returned
Number of Parameters 7
Parameter Type Name Description
IN(Mandatory) idArrangementComp The Id of the arrangement for which

property condition is requested. Company
code may also be passed as the second
element in this id. Separation by „/‟
IN(Optional) idPropertyClass Property class for which property details are

sought. If the class contains multiple
properties in this arrangement, system
returns the records for all properties
IN(Optional) IdProperty Specific property for which details are

sought. If class is not supplied, property
must be stated.
IN(Optional) effectiveDate The date for which property details are

sought. If the property record does not have
a record on that date, the past record
nearest to that date is returned. If a date is
not supplied, TODAY would be assumed.
OUT returnIds List of property Ids for this class separated

by FMs
OUT returnConditions List of property records – lowered to be in

sync with Ids
OUT returnError Errors if any during the processing

AA.GET.PUBLISHED.RECORD
This routine will resolve the published property / product structure and return the published
record. This routine is intended to be used only from Arrangement level
The parameter STAGE is optional now - the stage would be assumed as AA$PUBLISH if nothing
is stated.
IN(Mandatory) Product.or.property Is the designer or property records that is

requested. Valid options are „PRODUCT‟
and „PROPERTY‟
IN Stage Stage of the product from which details are

sought like Designer, Proof, Publish.
Would be assumed as Publish if nothing is

passed
Set the parameter to AA$DESIGNER,

AA$PROOF, AA$PUBLISH and pass it in.
These areequated commonsin
I_AA.APP.COMMON
IN(Mandatory) Product.property.Id The Id of the product or the property name

for which details are sought.
IN(Mandatory) effectiveDate The date for which property/product details

are sought. If the property record does not
have a record on that date, the past record
nearest to that date is returned.
OUT Published record The record of product/property returned

from the stage requested
OUT returnError Errors if any during the processing

AA.GET.PROPERTY.CLASS
This simple routine returns the

class to which the property
belongs.
IN(Mandatory) Activity id The name of the activity
OUT Activity class The Activity class id to which the activity

belongs
OUT Activity class record The activity class record
AA.GET.ACTIVITY.CLASS
This simple routine returns the

activity class to which the activity
belongs.
IN(Mandatory) Property The name of the property
OUT Property class The class to which the property belongs to
AA.GET.ARRANGEMENT.PROD
UCT
This method returns the product

that the arrangement is running
on and the properties linked to it.
IN(Mandatory) Arrangement Id The arrangement id reference

IN(Mandatory) Effective date The effective date on which product needs
to be identified.
IN/OUT Arrangement record The AA.ARRANGEMENT record for this

arrangement Id. If this is passed, system
uses it. Otherwise loads this as well
OUT Product Id The arrangement product that is effective

on the date passed for this arrangement
OUT Property List The list of properties that are eligible for this
product(separated by VMs)
AA.GEN.ARRANGEMENT.ACTIV
ITY.FIELDS
This method maps the

arrangement properties, its field
name and its value to new
arrangement activity record.
Values can be supplied to
arrangement property conditions
from
AA.ARRANGEMENT.ACTIVITY
record while triggering an activity
IN(Mandatory) Property list List of property names of the arrangement

whose values are supplied. Properties are
separated by value markers
IN(Mandatory) Field name list List of field names for each of the properties
whose values are supplied. For a property
the field names are separated by sub value
markers
IN(Mandatory) Field value list Actual values for the list of fields for each of
the arrangement properties. For a property
the field values are separated by sub value
markers
OUT ARR ACT Fields The formatted arrangement activity record

record
AA.GEN.NEW.ARRANGEMENT.
ACTIVITY
This method appends the new

arrangement activity as the
secondary activity to the parent
activity
IN(Mandatory) Arrangement Id The arrangement id reference
IN(Mandatory) Secondary activity New secondary activity name to be

triggered.
IN(Mandatory) Effective date Effective date of the activity
IN(Mandatory) Txn Details The arrangement product that is effective

on the date passed for this arrangement
IN(Mandatory) Parent activity id The list of properties that are eligible for this
product(separated by VMs)
IN(Mandatory) Arrangement activity New arrangement activity record

rec
OUT Return error Error message if any
AA.GET.ECB.BALANCE.AMOUNT
This method returns the total balance amount for a given balance type on a given date for an
account arrangement.
IN(Mandatory) Account Id The account number of the arrangement
IN(Mandatory) Balance type The balance type for which the balance is
sought.
IN(Mandatory) Request date Date for which balance is sought
OUT Balance amount The balance amount as in

EB.CONTRACT.BALANCES as on the
requested date. If the balance type is virtual
then sum of all the virtual balance is
returned
OUT Return error Error if any
VERSION
VERSION is a standard T24 application which allows users to create customised screens for input,
authorisation, display etc. It may also be used to automate the replacement of data on records. In fact T24
comes with many useful VERSION records for the majority of T24 applications. It is also possible to add
local sub-routines which can be used for field, input and authorisation validation. These small programs will
allow even greater customisation of T24 by the user.
The following points must be adhered while creating versions in T24,
1. Number of Versions used must be limited.
2. Redundant codes used in Version can be defined in VERSION.CONTROL
DOCUMENT DETAILS
1. Document approach should be from Test Cases.
2. Use “Snag it” tool for Screenshots.
3. Document should contain the detailed functionality of the module along with Workflow diagram.
4. Document should contain all the Parameter setup required for the respective module.
REDESIGNING A DEVELOPMENT
1. If reusable components are identified while redesigning the code, it must be informed to TL or PL,
so that the same can be packed and can be used later by all.
E:g: Requirement for NBF : Utility routine done for NBF
In Reuters Dealing TOF, if the deal has incorrect information, the deal will be put in IHLD
status and the OFS RESPONSE will be sent with the error status “-1”. If the OFS RESPONSE is received
with the “-1(Failure)” status, table OF.REUTERS.SEQN will not get updated. Because the deal was
picked up again and again; this caused more no of deals in IHLD.
To avoid this utility routine was written to amend the Status in the OFS RESPONSE. Since
the deals are available in IHLD or INAU status, in all the cases, OFS.RESPONSE was sent with the
Success status “1”.
This utility routine was handover to RLM team and it is now reused by many clients.
Similarly reusable codes or utility routines done for a particular bank should be identified
and informed to RLM team for reusability.

T24-CSD Programming Standards

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

T24-CSD Programming Standards

Загружено:

Авторское право:

Доступные форматы

Client Specific Development

Information in this document is subject to change without notice.

Author Version Date

Ponnarangam Shanmugam V.01 20 Jan 2008

Shameem Ahmed Reviewed V.01

Arun Prakash. R V.02 16 Mar 2010

Shameem Ahmed Reviewed V.02

Arun Prakash. R V.03 28 Apr 2010

Arun Prakash. R V.04 07 May 2010

Arun Prakash. R V.05 14 May 2010

Palanivel Pandiyan.A V.06 05 Aug 2011

Arunachalam. M R Reviewed V.06 16 Aug 2011

Mohanraj. R V.07 05 Jun 2012

Shameem Ahmed Reviewed V.07 15 Jun 2012

Jude / Aysha Version 08 21-Mar-2016

Sathish / Shrinath Version 09 30-Mar-2016

Aswani Kumar J Version 10 04-Oct-2016

2. BASICS OF jBASE PROGRAMMING

1. R10 Coding Standards must be followed

If so, what does the term “Simplicity” means?

We divide the commenting as 2 parts. They are:-

4.1 GENERIC COMMENTS

The modification history should be defined in the format as specified below,

4.2 FUNCTIONAL COMMENTS

The below given example will illustrate a sample of Functional Commenting.

ADVISED.AMOUNT = MAX.TOTAL - LR.FB.INTLIM

Reasons for using a naming convention is

1. To reduce the effort needed to read and understand source code.

2. To find out the value which the variable holds.

3. To understand the purpose for which the variable is defined

1. Subroutine names should be limited to 35 characters.

2. Subroutine names should not include the “$” or “_” character.

FN.LETTER.OF.CREDIT = „F. LETTER.OF.CREDIT‟

CALL OPF (FN. LETTER.OF.CREDIT, F. LETTER.OF.CREDIT)

Both GOSUB and variable names are the same.

CALL EB.CURR.CONV (Y.CCY.FROM, Y.AMT.FROM, Y.CCY.TO, CONV.LBP.CCY)

E.g: Do not use variable like "TAMS.BALANCE.UPLOAD.INTO.FILE"

E.g: Wrong way of Coding

DEFINE.PARAMETERS: * SEE „I_RULES‟ FOR DESCRIPTIONS *

E.g: Proper way of coding

Eg: Wrong way of Coding:

E.g: Proper way of Coding

FOR CUST.INT = 1 TO NO.DEL - 1

Eg: Wrong way of Coding:

Note: „OPEN‟ is a RESERVED word

E.g: Proper way of Coding

A variable is a way of referring to a memory location.

E.g: TODAY = “20091110”

7. Do not use a variable as dimensional array before declaring in the routine.

E.g: Wrong way of Coding

R.ACCOUNT <AC.WORKING.BALANCE> = R.ACCOUNT <AC.WORKING.BALANCE>

E.g: Proper way of Coding

WORKING BALANCE = R.ACCOUNT <AC.WORKING.BALANCE>

TOT.AMOUNT = WORKING BALANCE* COM.AMT

R.ACCOUNT <AC.WORKING.BALANCE> = TOT.AMOUNT

Now coming to T24, what is Coding Standards?

7.1 GENERAL STANDARDS

E.g: Wrong way of Coding

CALL INT.RATE (CUSTOMER.ID, CATEGORY, MNEMONIC, CURRENCY, WORKING BALANCE,

E.g: Proper way of Coding

ACCT.ARRAY = CUSTOMER.ID: FM: CATEGORY: FM: MNEMONIC: FM: CURRENCY:

CALL INT.RATE (ACCT.ARRAY)

* Conversion of foreign currency to local

currency OUTSTAND.AMT = O.DATA