Sie sind auf Seite 1von 74

Temenos Application Management

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 SA.

COPYRIGHT 2007 - 2008 TEMENOS HEADQUARTERS SA. All rights reserved.


Programming Standards

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

2
Programming Standards

Table of Contents
DOCUMENT HISTORY 2
INTRODUCTION 4
BASICS OF jBASE PROGRAMMING 5
PROGRAM QUALITIES 6
1.1 COMMENTS 6
1.1.1 GENERIC COMMENTS 7
1.1.2 FUNCTIONAL COMMENTS 9
1.2 NAMING CONVENTION 10
1.3 USAGE OF VARIABLES 13
CODING STANDARDS 15
1.4 GENERAL STANDARDS 16
1.5 USE OF LOOPS 28
1.6 USE OF MULTI.GET.LOC.REF 29
1.7 jBASE STATEMENTS AND COMMANDS 30
1.8 PERFORMANCE CONSIDERATIONS 38
1.9 USE OF IN2 ROUTINES 43
1.10 T24- SECURE CODING STANDARDS 44
FILE HANDLING: 45
FATAL ERROR HANDLING 48
MULTITHREAD ROUTINES 49
1.11 CORE ROUTINES 50
DATE ROUTINES 50
1.12 VALIDATION ROUTINES 51
1.13 EXCHANGE RATE 52
1.14 COB ROUTINES 52
1.15 CORE REUSABLE ROUTINES 53
UTILITY ROUTINES 59
AA – THINGS TO REMEMBER 62
1.16 LOCAL COMMONS in AA 62
1.17 VERSIONS and APIs in AA 63
1.18 CORE TABLES IN AA FOR LENDING 64
1.19 TRANSACTION BOUNDARY FOR AA 65
1.20 SPECIAL ABOUT AA BATCH PROCESSING 65
1.21 USEFUL APIs 66
VERSION 73
DOCUMENT DETAILS 74
REDESIGNING A DEVELOPMENT 74

3
Programming Standards

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.

4
Programming Standards

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.

5
Programming Standards

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.

1.1 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

6
Programming Standards

1.1.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) ODR Number
iv) Parameter to which the routine is linked with
v) Incoming and Outgoing Argument details
vi) Brief Introduction of the Program
vii) Modification History

The format below will provide you a better understanding about generic comments,

*********************************************************************
SUBROUTINE XXXXXXXX (ENQ.DATA)
*********************************************************************
* Company Name : Bank Name
* Developed By : Temenos Application Management
*--------------------------------------------------------------------------------------------
* 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:
*--------------------------------------------------------------------------------------------
* 23/07/2009 - ODR-2009- XX-XXXX
* Development for fetching the T24 account number for the IBAN.

7
Programming Standards

If there is a change in the code then it has to be a ODR, CR OR CSS modification. TUNIT is not necessary
as we consider it as internal.

If a fix is developed for the routine, then the fix should contain proper “MODIFICATION HISTORY” details
like modification date, fix number and also the start and end of fix changes inside the routine.

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

* Modification History

* Company Name:

* Developed By: Temenos Application Management

* Program Name:

****************************************************************************

HD0942615 - 20091112 – S Modification done by

****************************************************************************

* HD0942615 - 20091112 - S - Commented – XXXXXXXXXX

FN.LOCKING = 'F.LOCKING'

F.LOCKING = ''

CALL OPF(FN.LOCKING, F.LOCKING)

* HD0942615 - 20091112 - E

8
Programming Standards

1.1.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

9
Programming Standards

1.2 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 cannot be named with an extension of B (i.e. SC.CALC.YIELD.B).The extension


b is a reserved extension for c code and case insensitive systems such as Windows and iSeries
machines treat B the same as b. To ensure that no problems are encountered, it is best to avoid
using program names that end with „extensions‟ that may be interpreted by the underlying system,
i.e. Windows extensions .doc, .xls, .txt, Language extensions .c, .C, .cpp, .jar, .java, .class.

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

10
Programming Standards

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
Programming Standards

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

12
Programming Standards

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

E.g: Proper way of Coding

GOSUB OPEN.FILES
OPEN.FILES:
CALL OPF (FN.CUSTOMER, F.CUSTOMER)
CALL OPF (FN.ETMB.H.DELINQ.CUST, F.ETMB.H.DELINQ.CUST)
RETURN

1.3 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

13
Programming Standards

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.

14
Programming Standards

8. Record variables must not be used for Calculation purpose. Only the final update must be done to the
Record variables.

E.g: Wrong way of Coding

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


*COM.AMT

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

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.

15
Programming Standards

1.4 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

16
Programming Standards

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

17
Programming Standards

4. If number of argument is more than 5, try to use array variables in the subroutines.

E.g: Wrong way of Coding

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


ACCT.OFF)

E.g: Proper way of Coding

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.

18
Programming Standards

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.

E.g: Wrong way of Coding

MSG.COUNT = DCOUNT(MSG.SWEEP,@VM)

19
Programming Standards

E.g: Proper way of Coding

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.

E.g: Wrong way of Coding

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

20
Programming Standards

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'

E.g: Proper way of Coding

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


PASS.VALUE = 'Partial Shipment not allowed'

21
Programming Standards

20. Do not use „BREAK‟ Statement. Kindly use FLAG LOGIC or put RETURN instead of BREAK.

E.g: Wrong way of Coding

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

E.g: Proper way of Coding

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

22
Programming Standards

Some cases we have to use as per Scenario II.

Scenario II: FLAG LOGIC:

E.g: Proper way of Coding

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

23
Programming Standards

E.g: Proper way of Coding

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.

E.g: Wrong way of Coding:

IF PL.VAL THEN
IF R.ARRANGEMENT<AA.ARR.PRODUCT.LINE> NE PL.VAL THEN
CONTINUE
END
END

E.g: Proper way of Coding

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

24
Programming Standards

23. Never use “STOP” to terminate a batch process. Always use “FATAL.ERROR” to terminate a batch
job when error condition occurs.

E.g: Wrong way of Coding:

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

25
Programming Standards

E.g: Proper way of Coding

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 T24.BP I_COMMON


$INSERT T24.BP 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.

26
Programming Standards

1.4.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

1.4.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 are attached here with details on what they do.

T24 Standard Core


API's.xlsx

1.4.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.

27
Programming Standards

1.5 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,

28
Programming Standards

E.g: Proper way of Coding

IF CONDITION THEN
READ RECORD FROM F.FILE , ID THEN
ID.OK = 1
END
END ELSE
// (Statements)
END

1.6 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>

29
Programming Standards

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)

E.g: Proper way of Coding

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>

1.7 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,

30
Programming Standards

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.

31
Programming Standards

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)

32
Programming Standards

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.

33
Programming Standards

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.

34
Programming Standards

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.

35
Programming Standards

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.

36
Programming Standards

26. Use the OFS.BUILD.RECORD, instead of forming the OFS message by hard coding the field
values.

27. 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.

28. 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.

29. 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.

37
Programming Standards

1.8 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

38
Programming Standards

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

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.

39
Programming Standards

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.

E.g: Wrong way of Coding

CONVERT FM TO '' IN R.REC

E.g: Proper Way of Coding

R.REC = CHANGE (R.REC,FM,"")

40
Programming Standards

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.

1.8.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

1.8.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.

41
Programming Standards

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

42
Programming Standards

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.

1.9 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
subroutine guide for further clarifications

43
Programming Standards

1.10 T24- SECURE CODING STANDARDS

1.10.1 Basic
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.

1.10.2 Information 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

1.10.3 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.

1.10.4 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://knowledgebase.temenosgroup.com/t24/Pages/Development%20Process.aspx

44
Programming Standards

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.

E.g: Wrong way of Coding

CALL F.READ (FN.ACCOUNT, ACCOUNT.ID, R.ACCOUNT, F.ACCOUNT, ” “)

E.g: Proper way of Coding

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 )

45
Programming Standards

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. Use F.MATWRITE instead of F.WRITE when you actually write a dimensional array (records) into a
file.

46
Programming Standards

12. 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.

13. When current transaction needs to be cancelled use TRANSACTION.ABORT .It also clears deferred
writes and releases locks.

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.

E.g: Wrong way of Coding

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

E.g: Proper way of Coding

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

47
Programming Standards

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

48
Programming Standards

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.

49
Programming Standards

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

1.11 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.

DATE 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 days.

50
Programming Standards

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)

1.12 VALIDATION 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.

51
Programming Standards

1.13 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.LOCAL can be done, provided local currency amount, 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/sell basis

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 is given as incoming argument,
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.

1.14 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.

52
Programming Standards

6. Do not use HUSH or! HUSHIT since the output from the commands are very useful in analysing
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.

1.15 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, where as 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

53
Programming Standards

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)

54
Programming 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

55
Programming Standards

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)

56
Programming Standards

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)

57
Programming Standards

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 Transactions

58
Programming Standards

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&.

59
Programming Standards

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.

60
Programming Standards

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

61
Programming Standards

AA – THINGS TO REMEMBER

1.16 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

62
Programming Standards

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

63
Programming Standards

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.

1.18 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.

64
Programming Standards

1.19 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.

1.20 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.

65
Programming Standards

1.21 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.

66
Programming Standards

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

67
Programming Standards

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.

Number of Parameters 6

Parameter Type Name Description

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 are equated commons in
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

68
Programming Standards

AA.GET.PROPERTY.CLASS

This simple routine returns the class to which the property belongs.

Number of Parameters 3

Parameter Type Name Description

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.

Number of Parameters 2

Parameter Type Name Description

IN(Mandatory) Property The name of the property

OUT Property class The class to which the property belongs to

69
Programming Standards

AA.GET.ARRANGEMENT.PRODUCT

This method returns the product that the arrangement is running on and the properties linked to
it.

Number of Parameters 5

Parameter Type Name Description

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)

70
Programming Standards

AA.GEN.ARRANGEMENT.ACTIVITY.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

Number of Parameters 4

Parameter Type Name Description

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

Number of Parameters 7

Parameter Type Name Description

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

71
Programming Standards

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.

Number of Parameters 5

Parameter Type Name Description

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

72
Programming Standards

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

73
Programming Standards

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.

74