T24-csd Programming Standards

Client Specific Development PROGRAMMING STANDARDS

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without the express written permission of TEMENOS HEADQUARTERS SACOPYRIGHT 2007 - 2008 TEMENOS HEADQUARTERS SA. All rights reserved.

DOCUMENT HISTORY

Author

Ponnarangam Shanmugam Shameem Ahmed Arun Prakash. R Shameem Ahmed

Version

V.01

Date

20 Jan 2008

Reviewed V.01 V.02

16 Mar 2010

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 Mohanraj. R

Reviewed V.06 V.07

16 Aug 2011 05 Jun 2012

Shameem Ahmed

Reviewed V.07

15 Jun 2012

Jude / Aysha

Version 08

21-Mar-2016

Sathish / Shrinath

Version 09

30-Mar-2016

Aswani Kumar J

Version 10

04-Oct-2016

Table of Contents 1.

INTRODUCTION ............................................................................................................................... 5

2.

BASICS OF jBASE PROGRAMMING ............................................................................................ 6

3.

PROGRAM QUALITIES ................................................................................................................... 7

4.

COMMENTS ...................................................................................................................................... 7

5.

NAMING CONVENTION ................................................................................................................ 11

6.

USAGE OF VARIABLES ................................................................................................................ 14

7.

CODING STANDARDS .................................................................................................................. 16

7.1 GENERAL STANDARDS ................................................................................................................. 17 8.

USE OF LOOPS .............................................................................................................................. 30

9.

USE OF MULTI.GET.LOC.REF .................................................................................................... 31

10.

jBASE STATEMENTS AND COMMANDS .............................................................................. 32

11.

PERFORMANCE CONSIDERATIONS ................................................................................... 41

11.1

In BR/FS-You must definitely collect this information ....................................................... 44

11.2

In the technical specifications-the following must be indicated........................................ 44

12.

USE OF IN2 ROUTINES ........................................................................................................... 46

13.

T24- SECURE CODING STANDARDS ................................................................................... 47

13.1

Basic ......................................................................................................................................... 47

13.2

Information leakage ................................................................................................................ 47

13.2.1

Access control ................................................................................................................ 47

13.2.2

Insecure Storage ............................................................................................................ 47

14.

FILE HANDLING ......................................................................................................................... 48

15.

EXCEPTION HANDLING ........................................................................................................... 57

16.

MULTITHREAD ROUTINES ..................................................................................................... 59

17.

CORE ROUTINES ...................................................................................................................... 61

17.1

DATE ROUTINES................................................................................................................... 61

17.2

VALIDATION ROUTINES...................................................................................................... 63

18.

EXCHANGE RATE ..................................................................................................................... 64

19.

COB ROUTINES ......................................................................................................................... 64

20.

CORE REUSABLE ROUTINES ................................................................................................ 65

21.

UTILITY ROUTINES ................................................................................................................... 71

22.

LOCAL COMMONS in AA ......................................................................................................... 74

23.

VERSIONS and APIs in AA ....................................................................................................... 75

24.

CORE TABLES IN AA FOR LENDING .................................................................................... 76

25.

TRANSACTION BOUNDARY FOR AA ................................................................................... 77

26.

SPECIAL ABOUT AA BATCH PROCESSING ....................................................................... 77

27.

USEFUL APIs .............................................................................................................................. 79

Programming Standards

1. INTRODUCTION Programming Standards is a set of rules or guidelines used when coding programs in a particular language. It is often claimed that following a particular programming style/Standard will help programmers to read and understand the purpose for which the source code is developed, and help to avoid introducing errors while developing codes.

A particular Programming Standard which is applicable for one language may not be applicable for another. Hence, Programming styles are often designed for a specific programming language style which may be derived from the Coding Standards or Code conventions specific to company or other computing organization, as well as the preferences of the author of the code. Programming styles are often designed for a specific programming language style considered good in C source code may not be appropriate for BASIC source code, and so on. However, some rules are commonly applied to many languages.

This document aims at explaining the Infobasic programming standards to be followed while coding in jBASE or TAFC and points to be taken regarding the adherence of the local code to T24 development Standards.

Programming Standards

2. BASICS OF jBASE PROGRAMMING This section aims at projecting the basic points that should be adhered while coding programs in jbase.

1.

R10 Coding Standards must be followed

2.

If the number of lines exceeds 600 lines of code, CALL routines can be used wherever possible to minimize lines of code.

3.

The CALL routines should not have more than 4 arguments. It is advised to use dynamic arrays in arguments if it exceeds more than 4.

4.

The routine must be sectioned into smaller units/ paragraph and can be linked by using GOSUB‟s.

5.

The GOSUB Para defined inside the routine must not exceed 75 lines of code.

6.

The minimum number of GOSUB‟s that can be used in the routine should not exceed 5.

7.

The modern day ANSI C++ compilers are designed to rate the code based on basic pre-defined criteria‟s. The ratings will be generated during compilation of the codes and the same will be amended at the top of the routine. The ratings generated must be NEGATIVE which implicitly means that code Standard is in good quality.

8.

It is recommended to use Eclipse as the CODE window since, it projects the view of routine in a better way and also provide additional features than the other editors.

9.

Region to be defined for all GOSUB‟S. This can be achieved by using Eclipse code window.

Programming Standards

3. PROGRAM QUALITIES The quality of a program is not only measured by the rating of the source code given by the compiler but also on the level “Simplicity of the program “. If so, what does the term “Simplicity” means? Simplicity of program can be measured from the level of understanding by another personal on his/her first look over the routine irrespective to whether the person knows the programming or not. It is easy to make a programmer understand but how come the other personnel‟s? This can be achieved by giving proper comments and using meaningful variables in the program.

4. COMMENTS Comments in programming language is simply the programmer‟s annotation about the flow of the routine as well as purpose of the usage of variables and GOSUB‟s defined in the routine. Those annotations are potentially significative to programmers but typically ignorable to compilers and interpreters Comments are usually added with the purpose of making the source code easier to understand. The syntax and rules for comments vary and are usually defined in a programming language specification With respect to jBASE & T24, we have got some standard formats of commenting a program. We divide the commenting as 2 parts. They are:1.

Generic Comments

2.

Functional Comments

4.1 GENERIC COMMENTS

The generic comments are the comments which will project the outline of the routine. The description should not describe the implementation details because these often change over time. The generic comments should consist the details of below specified factors, i)

Company Name

ii)

Developer Name

iii)

Product/Module Name

iv)

Parameter to which the routine is linked with

v)

Incoming and Outgoing Argument details

vi)

Brief Introduction of the Program

vii)

Modification History

NOTE: It is essential that for TAFJ related codes to be written using the standard TAFJ IDE as a programming environment since it provides a better view of the routine and additional features that the other editors The format below will provide you a better understanding about generic comments,

********************************************************************* SUBROUTINE XXXXXXXX (ENQ.DATA) ********************************************************************* * Company Name : Bank Name * Developed By

: Client Specific Development

* Product Name

: EB

*-------------------------------------------------------------------------------------------* Subroutine Type : *<> * Attached to : <> * Attached as : *<> * Primary Purpose : <> *-------------------------------------------------------------------------------------------* Modification Details: *-------------------------------------------------------------------------------------------

Programming Standards

If there is a change in the code then it has to be a CR or defects from client (PACS tickets). Internal defect is not necessary as we consider it as internal. If a fix is developed for the routine, then the fix should contain proper “MODIFICATION DETAILS” like modification date, defect number.

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

* Modification Details: * ----------------------------* * 04/05/15 - 1666397 * Enquiry crashes and times out if date input is other than 8 digits, * since fatal error is called while call to CDT. Before processing * validation of dates carried out and proper error message thrown to * overcome fatal out.

8

Programming Standards

4.2 FUNCTIONAL COMMENTS

The functional comments are nothing but the comments that will project the functionality of set of codes or a line of code where the programmer wish to explain to the program views. With respect to T24, it is advisable for a programmer to provide a brief introduction about each and every GOSUB section in the beginning before start coding it. The below given example will illustrate a sample of Functional Commenting.

E.g: **Main process start here, Here we open the work file path *and get all the limit ids. Finally we calculate advised amount

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

Programming Standards 5. NAMING CONVENTION

A naming convention is a set of guidelines recommended for choosing the sequence of characters to be used for identifiers which denote variables, labels and functions etc. in source code. Appropriate choices for variable names are seen as the keystone for good style. Poorly-named variables make code harder to read and understand. Reasons for using a naming convention is 1. To reduce the effort needed to read and understand source code. 2. To find out the value which the variable holds. 3. To understand the purpose for which the variable is defined Now coming to the point, with respect to T24 programming, how we can actually define the naming conventions? The answer for the question is sculptured below.

1.

Subroutine names should be limited to 35 characters.

2.

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

3.

Routine name and template name should NOT be prefixed with “TAM” or with the product id‟s since it would conflict with the core routines. Instead, it should be prefixed based on the type of routine written (V.INP for version input, E. for enquiry related and B. for Batch / Service routines E.g:

4.

V. INP.ACCOUNT.DETAILS

Subroutine names should be named with an extension of ‘.b’ and data records with ‘.d’ as this is standard internal format to upload the sources/data records into RTC repository. E.g:

5.

V. INP.ACCOUNT.DETAILS.b F.VERSION!FUNDS.TRANSFER,AC.REFUND.d

The Keywords should be written only in capital letters and cannot be used as variable names in the routine.

6.

Meaningful names must be given for each local variable defined. Remove the local variables that are initialized to NULL or assigned a value, but not used in the routine

7.

Standard abbreviations are recommended for file name variables to help keep name length in Standard form for frequently used long terms.

E.g: FN.LETTER.OF.CREDIT = „F. LETTER.OF.CREDIT‟ F. LETTER.OF.CREDIT = '' CALL OPF (FN. LETTER.OF.CREDIT, F. LETTER.OF.CREDIT)

8.

During the execution the variables values are bound to change, hence never use different variable names to hold the same value.

9.

It is recommended not to use the same names as Labels, variables and routines.

E.g: CONV.LBP.CCY: ******************* * Converting the USD amount to LBP equivalent Y.CCY.FROM = 'USD' Y.CCY.TO = 'LBP' CONV.LBP.CCY = ''

Both GOSUB and variable names are the same. Instead initialize another variable for CONV.LBP.CCY = ''

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

10. Labels and variable names should be short, simple and meaningful so that the strain on debugging these variables names will be minimum.

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

11.

Numeric Labels should not be used. Labels must exist on their own line with no other text appended to it.

E.g:

Wrong way of Coding

DEFINE.PARAMETERS: * SEE „I_RULES‟ FOR DESCRIPTIONS * REM > CALL XX.FIELD.DEFINITIONS

E.g:

Proper way of coding

DEFINE.PARAMETERS: * SEE „I_RULES‟ FOR DESCRIPTIONS * REM > CALL XX.FIELD.DEFINITIONS

12.

File name variables must be referenced by FN.FILENAME and File path variables must be referenced by F.FILENAME and record variables must be referenced with R.FILENAME. The Error variables must be referenced by ACCOUNT.ERR.

E.g:

FN.ACCOUNT F.ACCOUNT R.ACCOUNT ACCOUNT.ERR

13.

Do not use Non-Standard Variables. Kindly Use meaningful Variables names.

Eg: Wrong way of Coding:

XX.CUST, YY.ACT FOR Y.J = 1 TO NO.DEL - 1 FORM.DIR:= FIELD (CUR.FILE.PATH,"/", Y.J) FORM.DIR:='/' NEXT Y.J

Programming Stan E.g:

Proper way of Coding

FOR CUST.INT = 1 TO NO.DEL - 1 FORM.DIR:= FIELD (CUR.FILE.PATH,"/", CUST.INT) FORM.DIR:='/' NEXT CUST.INT

14.

Do not use Alpha numeric variable names. Kindly use meaningful variable names.

15.

Do not use RESERVED word (Key word) as a GOSUB Name. Kindly use meaningful names.

Eg: Wrong way of Coding: GOSUB OPEN OPEN: CALL OPF (FN.CUSTOMER, F.CUSTOMER) CALL OPF (FN.ETMB.H.DELINQ.CUST, F.ETMB.H.DELINQ.CUST) RETURN Note: „OPEN‟ is a RESERVED word 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

6. USAGE OF VARIABLES What is a variable? A variable is a way of referring to a memory location. The memory location may hold any type of data depending on the data type of the variable. Depending upon the life of the variable inside the routine they are categorized as follows,

1. Local variable 2. Common variable

3. Array variable 4. Record variable

The points described below this section refer to scope of variables that are defined in the routine. 1.

Usage of Local Variables must be reduced and wherever possible local variables can be replaced with Common Variables.

E.g: Read on records like COMPANY,SPF, USER etc.., can be reduced and the common variables ID.COMPANY, R.COMPANY, R.SPF.SYSTEM, OPERATOR can be used.

2.

The variables which are used throughout the program should only be defined in the initialization GOSUB. Local variables which are used in GOSUB or FOR loop should be initialized within the GOSUB or FOR loop so that these variables are accessible only within the range for which it is initialized and cannot be used outside the range of the variable for better readability.

3.

Avoid the common variable names passed on as arguments. Common variables like ETEXT cannot be defined as error variable in F.READ or EB.READLIST

4.

Use local variables as much as minimum and in case if program needs, use array variable by grouping the variables by its similarity. This helps in reducing the complexity of the program.

5.

I_RULES to be referred & COMMON variables have to be checked before programming - the reason being that some of the value might have be assigned by the CORE program and the local development can do away with just using the same.

6.

Do not assign values to common variables and override the actual functionality of the variable. This may affect the overall functionality of the common variable used.

E.g:

7.

TODAY = “20091110”

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

Standards 8.

Record variables must not be used for Calculation purpose. Only the final update must be done to the Record variables. E.g: Wrong way of Coding R.ACCOUNT = R.ACCOUNT *COM.AMT

E.g:

Proper way of Coding

WORKING BALANCE = R.ACCOUNT TOT.AMOUNT = WORKING BALANCE* COM.AMT

R.ACCOUNT = TOT.AMOUNT 9.

When declaring variables do not use keywords like OPEN, FOR etc … as variable names in the routines

10.

Avoid using character checks which have combination of upper case and lower which will yield incorrect results

11.

Product and Subroutine level Common variables are retained and possible to be carried out to subsequent transactions and provide unexpected results. So explicitly clear a common variable if the usage is not required to be passed on to subsequent transactions or cob processes.

7. CODING STANDARDS Coding Standards is a set of rules or guidelines used when writing the source code for a computer program. Coding Standards refers to specifying rules and guidelines for the proper use of an individual programming language's constructs. Hence, it is essential to define set of criteria so as how the source code should be and what all could be the necessary contents of a code. Though at initial stages it seems like a burden to follow standard, its advantages become visible over a period of time. Some of the advantages are: 1.

Programmer feels comfortable with the code written by others, as it is similar to what he himself would have written.

2.

Person joining the group at later stage can pick up the code easily (once he is familiar with the standards).

Now coming to T24, what is Coding Standards?

Coding Standards defines the way a source code should be, how to proceed This section projects set of Standards that should be adhered while writing a jBASE code

Programming Standard

7.1 GENERAL STANDARDS

This section explains general standards that must be adhered and also the basic files that should be included at the start of routine.

1.

All routines must have I_COMMON and I_EQUATE inserted at the start of the program.

2.

Each routine should have one main controlling section with the detailed code written. Do not write TOP DOWN code. The main controlling section should contain the insert files, GOSUB statements along with the proper RETURN statement. Each GOSUB should be defined properly along with the RETURN statement.

E.g: GOSUB INITIALIZE GOSUB OPEN FILES GOSUB PROCESS RETURN INITIALIZE: /Statements RETURN

OPEN FILES: /Statements RETURN

PROCESS: /Statements GOSUB CALCULATE RETURN

CALCULATE: /Statements RETURN

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

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.

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)

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

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'

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

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

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 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 EQ PL.VAL THEN PL.FLAG = 'EXECUTE' END END

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

Programming

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 I_COMMON $INSERT I_EQUATE

25.

Do not use JOURNAL.UPDATE in the Routine.

26.

Kindly avoid the usage of CHECK.RECORD.ROUTINE wherever possible. The usage of CHECK.REC.RTN should be limited to scenarios, where there is an absolute necessity to modify the field properties alone

27.

Do not use more than ten local fields.

28.

Use CALLJEE instead of CALLJ from R10 release onwards.

7.1.1 CODING CONSIDERATIONS 

Any code to be developed should always be named generic. Client names/acronyms should not be used. 



Use E.STMT.ENQ.BY.CONCAT (or TAM.GET.ACCT.TRANSACTIONS – locally modified

 to be used as an API/call routine) to fetch the entries for a given period. Rather than selecting STMT.ENTRY file.   



Use bulking wherever possible 



No hard coding of data while coding. 



A generic parameter table should be built. This can have some 100 local ref fields that

 can be named as required in each of the project. Eventually, this parameter file will become the base PARAM file  

7.1.2 STANDARD CORE API



There are Standard CORE API‟s available, which should be used to retrieve information, instead of incorporating new logic / code for any given problem. We will have to ensure that we use already available API‟s to achieve our solution. 

Sample of CORE API‟s with details on what they do is made available in below link: http://uni-t.temenos.com/dms/QMS/L2L3/Documentation/CSD_Governance_API_Details.xls?Web=1

7.1.3 LOCAL REFERENCE FIELDS AND LOCAL VARIABLES



Local reference – on core templates should be below 10. If there are more fields to be added proper explanation has to be provided as to why additional fields have to be included. 





Local variables should be under check and usage of Array has to be promoted. 

8. USE OF LOOPS

Loops are used for iterative purposes to execute same set of instructions specified number of times or until a specific condition or result is obtained. There are various types of loops in jbase namely, 1) FOR...NEXT 2) LOOP... REMOVE 3) CASE STATEMENTS Though these loops make the execution of instructions faster and easier, there are certain specific constraints that should be considered while coding these loops in the routine. The criteria to be considered before using these loops are as follows,

1.

Instead of FOR and NEXT loops prefer using LOOP and REMOVE syntax since it is more efficient than FOR loop.

2.

In GOSUB avoid deeply nested IFs and large CASE constructs. This will help in reducing the complexity of the GOSUB as well as reduce the overall rating of the routine.

3.

The construction of IF....ELSE statements can be very complicated but it‟s a good practice to make it both readable and non-ambiguous. Consider the following example,

E.g : Wrong way of Coding

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

This is poor coding technique since, it is difficult to analyze whether the ELSE statements should be executed for IF or READ condition. Hence the following code should be re-written as,

E.g: Proper way of Coding

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

9. USE OF MULTI.GET.LOC.REF Each application has large number of fields to store for a bank. But it is not possible for a bank to store all possible fields that a bank may require. To overcome this, T24 provides us the functionality of „Local Reference‟ fields. These fields can be added for a particular application depending upon the bank„s requirement. They are totally „CUSTOMISABLE‟.

To get this local reference field position, call made to GET.LOC.REF which will return the position of the local reference field from the Standard Selection table. This section explains how to use GET.LOC.REF and to retrieve the local field position,

1.

Do not use OPF for the files in which only local reference field values are updated using GET.LOC.REF.

2.

Hard coding of LOCAL.REF fields of any applications to be replaced by the position returned by GET.LOC.REF. Do not use the variable POS inside the routine for calculation purposes. Instead assign the value of POS to a variable and use that variable inside the routine.

E.g: APPL = "CUSTOMER" FLD = "OPEN.DATE" POS = '' CALL GET.LOC.REF (APPL, FLD, POS) OPEN.DATE.POS = POS<1,1>

3.

Use MULTI.GET.LOC.REF instead of GET.LOC.REF to get local reference field position. When

GET.LOC.REF is used the same file needs to be reopened multiple times to get the local field position. Whereas, if MULTI.GET.LOC.REF is used, the file is opened once and multiple field positions can be retrieved.

E.g:

Wrong Way of Coding:

CALL GET.LOC.REF("CUSTOMER", "CUST.ID", LR.CUST.ID) CALL GET.LOC.REF ("CUSTOMER", "MFO.CODE", LR.MFO.CODE) CALL GET.LOC.REF ("CUSTOMER", "NBU.B010", LR.NBU.B010) CALL GET.LOC.REF ("CUSTOMER", "USB.OBLAST", LR.USB.OBLAST)

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>

10. jBASE STATEMENTS AND COMMANDS The commands are used to perform a specific task in the program, which may be print or open file or delete and so on. Hence in jbase, the programmer can make use of available commands and statements to make the code simpler and manageable. This section explains the few jbase commands that can/cannot be used and if usable, the way how to use it,

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 NEXT I FOR I = 9 TO 1 STEP -2 DEL MUMBERS NEXT I

4. Do not use INPUT statement since it may lead to severe implications and may cause the session to hang/ or terminate abnormally.

Programming 5.

Do not use EQU command when array variables which do not have an underlying table / file are EQUATED with numbers rather than names. E.g: EQU LO24.CR.SCORING TO 1 ; R.LO24

6.

The ASCII function can be used when all the characters in the expression from EBCDIC character set are to be converted to ASCII character set.

E.g: AsciiBlock = ASCII(EbcdicBlock)

7.

The DEFFUN statement can be used to declare an external jBC function to a jBC compiler and define its arguments. If the RETURN statement specifies no value, then an empty string is returned by the function.

E.g: DEFFUN Add() A = 10 B = 20 sum = Add(A, B) X = RND(42) Y = RND(24) Add(X, Y)

FUNCTION Add(operand1, operand2) result = operand1 + operand2 RETURN(result)

8.

The command ABSS returns absolute value of all the elements in dynamic array. Hence ABSS can be used to return absolute value of an array. If the element in the dynamic array is null, then null is returned for that element.

E.g: Y = REUSE(300) Z = 500:@VM:400:@VM:300:@SM:200:@SM:100 A = SUBS(Z,Y)

The output of this program will be 200]100]0\-100\-200 200]100]0\100\200 9.

Remove DEBUG after testing the program. DEBUG should not be present during the delivery of the program

10.

The use of statement TRIM command allows characters to be removed from the string in number of ways. Hence depending upon the character that needs to be removed, proper choice of trim options can be used.

E.g: * Remove

spaces

and

tabs

(second

parameter

ignored) Answer = TRIM(Answer, ", "D") * Remove all dots Thief = TRIM(Joker, ".", "A")

11.

The MAT command can be used to either assign every element in a specified array to a single value or to assign entire contents of one array to another.

Programming

E.g:

DIM A(45), G(50) MAT A = “Array Value” MAT G = MAT A

12.

The INDEX function will return the position of a character or characters within another string.

E.g: AB = “Temenos” IND.POS = INDEX( AB , “e” , 1 )

The result of above program is 2.

13.

The function ICONV can be used to convert the data in external form such as dates to their internal form.

E.g: INTDATE = ICONV(“27 May 2009”, “D”)

Output of the command is May 27, 2009.

14.

The function OCONV can be used to convert the data in internal form to their external form.

E.g: GET.DATE = OCONV(DATE(),"D4-") GET.TIME = OCONV(TIME(),"MTS")

15.

The execution of the program can be halted by using EXIT command which exits returning a numeric code to the parent process. If the exit expression doesn‟t evaluate to a numeric value then the program will enter the debugger with suitable error message.

Programming St 16.

The ALPHA function will check whether the expression consists of entirely alphabetical characters. It will return value 1 if the expression is purely alphabetic else return 0.

E.g: Abc = “ABC” IF ALPHA(Abc) THEN //Statements

END ELSE //Statements END

17.

CLEARFILE can be used to clear data of a previously opened file only if the file is opened using OPEN statement.

18.

When FIND statement is used, it will either omit IF clause or ELSE clause but will never omit both.

E.g: VAR= “ABC”:VM:”JAC”:VM:”CDE”:”WHO” FIND “JAC” IN VAR SETTING Ap, Vp THEN TEXT “JAC IS IN FIELD “ :Ap: “, VALUE ”: Vp ELSE TEXT “JAC IS NOT IN FIELD” END

The output of the above routine will be, JAC IS IN FIELD 1, VALUE 2. 19.

Do not use HUSH statement to suppress the output display unless the display is unnecessary. When HUSH ON is used all output is suppressed including the error messages and request for information. HUSH statement will suppress all output normally sent to a terminal during processing. HUSH also suppress output to COMO file.

20.

Do not use CALLC function to transfer arguments which are arrays since CALLC function is used to transfer the program control to an external function and CALLC arguments can be simple or complex expressions.

E.g: A = 10; B = 1000 MyFunction = "MYC1" CALLC @MyFunction Result = CALLC MYC2(A, B) TEXT "Result is ":Result

21.

Use COUNTS function to count the number of times a substring is repeated in each element of dynamic array. The result is a new dynamic array whose elements are the counts corresponding to the elements in the dynamic array.

E.g: ARRAY1 = “A”:@VM:”AA”:@VM:”AAAA” COUNTVALUE= COUNTS(ARRAY, “A”)

22.

For any T24 Release in R09, do not use OFS.GLOBUS.MANAGER from version routines. OFS.GLOBUS.MANAGER can be used only for validation purposes. To avoid transaction boundary issues, OFS.POST.MESSAGE should be preferred over the use of OGM.

23.

The usage of OFS.POST.MESSAGE is restricted to delaying the processing of the transactions (by writing the message to queue and then being later processed by OFS.MESSAGE.SERVICE). Also suggest that the parallel and synchronous run of OFS.REPONSE.QUEUE should be encouraged to avoid the growth of the OFS.MESSAGE.QUEUE. This is preferred way of doing it rather than clearing the file manually

24.

Where ever the ID of a TXN is required for updation, do a validate using OGM and get the ID, then use the OFS.POST.MESSAGE with the ID and write to queue

25.

Passing the company ID always with the OFS messages, since this has been seen to have a little faster response time when compared to messages without company ID‟s.

26.

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

27.

When forming OFS messages please included the below syntax which will insert the last multivalue and subvalue set with values rather that doing DCOUNT and adding the values to the array. For example:- To add a value to the last multivalue set / subvalue set for a field say POSTING.RESTRICT, the message can contain the syntax like POSTING.RESTRICT:-1:-1=3 This syntax can be used to add field multi values via OFS irrespective of available VM or SM rather than reading the record to calculate next multi value position

28.

Do not use INPUT.BUFFER (used as keyboard type ahead) variable for defaulting data or navigation commands e.g. moving to a new field or expanding a multi-valued field etc since INPUT.BUFFER cannot be recognised by GUI.

29.

Use REFRESH.FIELD and REFRESH.SCREEN to refresh the screen although use the later sparingly since all the field definitions and all the data are resent to GUI again.

30.

All SELECT statements with multiple conditions separated by SPACE should be replaced by AND condition.

E.g.:

Wrong way of Coding

SEL.CMD="SSELECT ":FN.IS.H.CONTRACTS: “WITH FWL.FLAG EQ 'YES' " : “ WITH FWL.LD.ID NE "

E.g.:

Proper way of Coding

SEL.CMD="SSELECT ":FN.IS.H.CONTRACTS SEL.CMD:=" WITH FWL.FLAG EQ 'YES'" SEL.CMD:=" AND WITH FWL.LD.ID NE ''"

30.

Never to use STOP or ABORT. In case of error, the errors should be properly logged and the control should return safely from the routine.

31.

Do not use GOTO even if it is to exit a unit or used to retry the record that is locked. The use of the

GOTO command is not recommended as it obscures the readability of code and therefore is a hindrance to maintainability. All Programs written using the GOTO construct can be written using structured statements such as LOOP and FOR. Opinions on this are divided but the consensus is that GOTO should be avoided.

Programming Standards

11. PERFORMANCE CONSIDERATIONS Performance issues that may arise in T24 may be as a result of parameters that are shipped with the application in T24. These offer most detailed functionality but at a cost. At the time of writing T24 actively modified to default parameter settings to be performance oriented. This section details certain performance issues that can be overcome by possible usage of another parameter with the same functionality.

1.

Use the faster operators “:=“ “+=“ etc. E.g. TOTAL.VAL += SUB.TOTAL

Instead of poor coding technique as below,

TOTAL.VAL = TOTAL.VAL + SUB.TOTAL.

2.

Avoid large dynamic arrays (greater than 1000 bytes).

3.

Always use “:=“instead of <-1> when building a large dynamic array. There is little difference when performed at FIELD level, but this is expensive on multi and sub values.

4.

Construct case statements so that the most often used condition is at the top.

5.

Do not perform counts in the controlling section of a loop:

E.g. FOR CNT = 1 to DCOUNT(array, FM)

It should be written as two separate statements:

E.g: NO.ITEMS = DCOUNT(array,FM) FOR CNT = 1 to NO.ITEMS

6.

The system will evaluate the DCOUNT for every pass of the FOR.. NEXT loop, which can be very expensive with large arrays, where it only needs to be evaluated once.

7.

Do NOT use DBR to read single fields from a record as this reads the whole record, it is better to read the entire record once and extract the values required. A typical subroutine will access more than value from a record, and even if it does not do, then further enhancement will be easier if the entire record is available.

8.

Ensure that new files created have a sensible modulo. Do NOT release new file control records with a modulo of 3 or 9731, try to work out a projected record size and base the size on a database with a reasonable volume.

9.

Make sure that operations are not needlessly repeated within a loop, for example avoid re-reading the same parameter record every time a loop is executed.

10.

Do NOT select files that are known to be likely to grow large in installations, use concat files or other alternative methods of finding the records required. When developing new applications / processes. If a process will be dependent upon selection of a file that will grow large, build an alternative access method, e.g. a concatfile. Example files include: STMT.ENTRY CATEG.ENTRY RE.CONSOL.SPEC.ENTRY LIMIT.TXNS SC.POS.ASSET For extracting data from STMT.ENTRY , CATEG.ENTRY AND RE.CONSOL.SPEC.ENTRY please use the below core contact tables to get data as per the business logic RE.CONSOL.SPEC.ENT.KEY RE.CONSOL.STMT.ENT.KEY

11.

Be very careful in the use of concatfiles. A poorly designed concatfile can result in a performance overhead when updated due to the large record size created and system locks if the key is a poor choice. E.g. the concatfile LMM.CURRENCY is a poor file since the key is likely to be common with the majority of contracts, this has the effect of allowing only a single contract to be entered at any one time for a given currency, and is likely to contain massive records (e.g. for local currency). If a concatfile is likely to contain more than 1000 ids in it a different structure / process should be used.

12.

Use standard system routines and functions wherever available. This will optimise the performance.

13.

Avoid unnecessary select statements; if a record key can be obtained using direct access, a select

is an unnecessary overhead. Do not select a file with a specific key, put into a select list, and then read the record. 14.

Use SUM etc to add all multi-values in a field together. Do not use a loop to process each multivalue separately.

15.

When dynamic arrays are used they become more and more in efficient to store data when the number of values and multi-values become large. Even at around 100 the processing will noticeably degrade

16.

The cache must ONLY be used when the result of the query is static at run time, e.g. CATEGORY or COMPANY. Caching must NOT be used where variable data is used in the selection. Once the query results have been returned, they are added to the cache mechanism and further invocation of the named select will always use the cached results

17.

Do not use condition selection in query file like CUSTOMER, ACCOUNT, STMT.ENTRY, etc… chiefly in oracle database. This is because the condition query on huge files may take up more time to extract values from the files. Instead use SELECT condition and validate the condition criteria using LOOPS.

18.

Select which has a possibility of multiple record selections should consider using the EQ clause instead of LIKE in it. Eg. To select accounts with category = 1001,6001 & 5001 consider using it as SELECT FBNK.ACCOUNT WITH CATEGORY EQ 1001 6001 5001. This works faster with traditional databases which make use of drivers to communicate.

19.

Using convert is a performance issue since it is more time consuming and hence use CHANGE instead of CONVERT. The benchmark result shows that CONVERT on large arrays is 20 times slower than using CHANGE under similar circumstances. The first program that uses CONVERT completed in 40-50 minutes and the second program using CHANGE completed in less than 2 seconds.

The TEST.REC has 20000 lines of code written.

E.g:

Wrong way of Coding

CONVERT FM TO '' IN R.REC

E.g:

Proper Way of Coding

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

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.

11.1 In BR/FS-You must definitely collect this information Volume of transactions to be processed in a day.   Is the volume consistent through the day or there are peaks and troughs. E.g. peak transactions during the morning or during the month end etc. If that is the case volumes during peak period and volumes during normal period.   If the volumes are from multiple channels then volume per channel must be provided. Also, an indicator to indicate whether it is a client facing channel (e.g. – ATM, Internet Banking) or internal user must be clearly indicated  

11.2 In the technical specifications-the following must be indicated If the transaction is posted Online or a Service Online 

Each online transaction we must provide consideration to the following. 



Number of fields on screen including number of multi values on screen. There must be a

 restriction on the number of fields input/displayed as loading data in the screen on browser will be slow  



When COS is displayed care must be taken that the landing screen is never the COS and even in a COS scenario very minimal applications are shown together. If too many enquiries are placed in COS then all the requests will clog the agents in parallel. This being the case the number of enquiries and applications must be limited in a COS. 





Have the following consideration on I/O.

Activity No of Files Opened

       

Guidelines

X

All files must be opened using OPF. Repeatedly opened files must be put in a common variable rather than being repeatedly OPF‟ed

X

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 and IDS must be always set to Unique. 2. Size of the record read should always be small < 4096 bytes. 3. All parameter files must be always CACHE.READ

No of Files Written

X

1. No Locking contentions 2. Size of record written should always be small. 3. Never have redundant writes

No of Selects

X

1. Restrict Selects - must always be reads unless the selected file is a nongrowing file and small in size

No of Files Read



Numbers

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

Programming Standards

Activity

No of Files Opened

Numbers

Guidelines

X

All files must be opened using OPF. All OPFs must happen in the LOAD section of the multi-threaded process unless required to be in the record routine

X

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 2. Size of the record read should always be small < 4096 bytes. 3. All parameter files must be always CACHE.READ and must be read in the load routine

No of Files Written

X

1. No Locking contentions 2. Size of record written should always be small. 3. Never have redundant writes

No of Selects

X

There must be only one select from the .SELECT routine. Any other selects is not permitted

No of Files Read

The largest transaction in a record routine must be less than the review seconds, i.e. 60 seconds   Any auto service must not run with a review time of less than 60 seconds. There will be requirements for <5 second review time but this should not be permitted   Logging must be enabled only on request and must have brief and full options. Logging must be switched off by default   If the process is a COB process then all consideration must be given to check if this can be placed outside the COB process and in the online stage.    

12. USE OF IN2 ROUTINES IN2 routines are generally used for the field definitions of the applications. IN2 routines can also be used elsewhere if it is called correctly. 1. The T array setting for IN2 routines can be initialized depending on type of field F(Z) for which the IN2 routine is invoked. IN2 routines can validate upon fields like alphanumeric text, Amounts, Dates, Account Numbers, Category, Currency, Charges, Commissions and tax, Customer. Refer IN2 subroutin

guide for further clarifications

13. T24- SECURE CODING STANDARDS 13.1Basic 1. 2.

Avoid using common variables to pass as parameters in subroutines Avoid using transaction, boundary related core common variables – except in core programs where it is specifically required. Any update to core COB files – eg JOB.LIST, its related locking updates etc should be avoided.

3.

Ensure that code does not alter global common variables like TODAY, ID.COMPANY, R.COMPANY, R.DATES etc within application code. Only the components/subroutines that own these common variables could change them. For example ID.COMPANY could be changed by LOAD.COMPANY.

4.

Ensure that named common variables are only assigned in the appropriate routines. For example named commons used in batch – should only be assigned in the load routine. The record /Select routine should only use them not alter values in them unless functionality demands it

5.

When common variables need to be used in programs ensure that they are reset after they are expected to be out of scope.

13.2Information leakage 1.

Ensure not to log highly sensitive information where possible. Logging should only use T24 logger framework

2.

System memory variables should not be used to log any sensitive information as it can be misused /monitored by others

13.2.1 Access control 1.

Ensure not to log highly sensitive information where possible. Logging should only use T24 logger framework EB.CALL.API should be used where an API request to be done. This will ensure that core common variables are preserved so that it cannot be tampered by API‟s

2.

DAS should be used for selecting records from applications. No Direct SELECT should be used. This will have a control on SELECT‟s performed on applications are permitted by application owner.

13.2.2 Insecure Storage 1.

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

http://uni-t.temenos.com/teams/DA/Product Standards/Product - Secure Coding standards - T24.pdf

14. FILE HANDLING File handling defines the way how to handle files and make call to files using F.READ , F.WRITE and other available commands which are basically defined in the core API. These files simply replace the use certain base commands or statements and also increase the performance of the routine.

1.

When F.READ is used to read a file, all the arguments in the F.READ should be initialized. No empty braces should be used instead of arguments. 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 )

4.

READ or F.READ or CACHE.READ on SPF file to be removed. Instead use the common variable R.SPF.SYSTEM

5.

Use F.DELETE to delete a single record form a file. Do not use multiple F.DELETE to delete records from the file. E.g: CALL F.WRITE(FN.ACCOUNT.PATH,ACCOUNT.FILE.PATH.ID,R.ACCOUNT.FILE.ERR) CALL F.DELETE(FN.ACCOUNT.FILE.PATH,R.ACCOUNTL.FILE)

6.

Use EB.CLEAR.FILE when you want to clear a file or delete selected records from a file.

7.

In case there is a need to bypass T24 subroutines to perform delete (F.DELETE) and write (F.WRITE), the syntax in these statements must avoid ELSE and THEN statements.

8.

Use F.MATREAD instead of F.READ to read a dimensional array from a file.

E.g: CALL OPF(FN.ENQUIRY.REPORT,F.ENQUIRY.REPORT) CALL F.MATREAD (FN.ENQUIRY.REPORT, Y.ENQ.ID, MAT R.NEW, 100, F.ENQUIRY.REPORT, ENQ.REP.ERR)

9.

Use F.WRITE command instead of WRITE to write a file. When WRITE is used each record will be individually updated in database. Whereas when F.WRITE is used, it will update records in cache memory initially and then update the entire records in database once the cache size exceeds the maximum capacity

10.

When audit fields needs to be updated on LIVE record and HISTORY needs to be updated on $HIS record file use F.LIVE.WRITE. Since this is wrapped around a CALL to external subroutine AUTH.AND.HIST.WRITE, updates are processed automatically.

11.

When using audit field checks, care should be table to include multi-value checks based on the setup in SPF record for DATE.TIME field. In general, care should be taken in the code to consider if the field is multi-value or sub value and then should be used appropriately

12.

Use F.MATWRITE instead of F.WRITE when you actually write a dimensional array (records) into a file.

13.

Avoid using F.LOAD & F.MATLOAD to refresh the Read and Write Cache without doing a Write

14.

Release of Lock on Data file should be done using F.RELEASE and avoid using RELEASE directly.

15.

When audit fields needs to be updated on LIVE file record and HISTORY file needs to be updated on $HIS file record file use F.LIVE.MATWRITE. Since this is wrapped around a CALL to external subroutine AUTH.AND.HIST.WRITE, updates are processed automatically.

16.

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

17.

Use the routine EB.NO.OF.MONTHS to arrive the number of months between two specified date records.

Syntax

:-

SUBROUTINE

EB.NO.OF.MONTHS(START.DATE,

END.DATE,

NO.OF.MONTHS)

18.

To read Parameter files use EB.READ.PARAMETER as it has the intelligence of returning correct parameter setup in a Multi Company installation.

19.

Avoid using EB.READLIST routine for selecting data files

20.

To get calendar days for days displacement use the core routine CALENDAR.DAY

21.

To cycle dates always use the core routine CFQ

22.

Use the routine WORKING.DAY for any calculation with respect to working day for a business day definition

23.

Use the core routine AWD to check if a given date is a holiday or working day

24.

Use the core routine DIETER.DATE to convert dates from the format used throughout T24 (YYYMMDD) to the standard jBASE format (either internal or external. External dates formatted as per jBASE CONVERSIONs)

25.

Use GET.CURRENCY.RECORD for getting the Currency record and Do not get the details by directly accessing the file. To read a history CURRENCY record

please

use the core

API

GET.CCY.HISTORY. To get a specific static values from of currency table use the UPD.CCY

26.

To get Currency Market details for Particular product and specific movement, FIND.CCY.MKT should be used.

27.

To

format

a

currency

SC.FORMAT.CCY.AMT.

amount

to

the

respective

decimal

places

use

the

routine

28.

Enquiry Subroutine E.GET.LOCAL.AMOUNT can be used to calculate the local currency equivalent using MIDDLE.RATE.CONV.CHECK.

29.

For getting interest rate of Periodic interest setup TERMRATE routine need to be called.

30.

For getting interest rate for BASIC.INTEREST rate setup, EB.GET.INTEREST.RATE need to be used

31.

To get the Number of days for Interest processing for a Interest basis, routine BD.CALC.DAYS should be used.

32.

No direct read is allowed on the file ACCT.ACTIVITY table always use the routine EB.GET.ACCT.ACTIVITY to read the values

33.

Any read or write to EB.CONTRACT.BALANCES should use EB.READ.CONTRACT.BALANCES and EB.WRITE.CONTRACT.BALANCES.

34.

Use the routine INT.ACC to check if a given account number is an internal account number

35.

To

validate

the

category

of

an

account

with

ACCOUNT.CLASS

use

the

routine

CHECK.ACCOUNT.CLASS

36.

Any read or write to EB.CONTRACT.BALANCES should use EB.READ.CONTRACT.BALANCES and EB.WRITE.CONTRACT.BALANCES.

37.

For getting the external Account details for the respective Nostro account from AGENCY file, the routine GET.EXT.ACC.NO should be used.

38.

EB.ROUND.AMOUNT routine to be used for all rounding off variables

39.

Getting the details on whether the Particular application is in Trade dated or Value dated, use the routine AC.VALUE.DATED.ACCTNG.

40.

Use E.GET.STMT.NARRATIVE to return a calculated statement entry narrative for enquiry purposes. The narrative is calculated according the definitions in TRANSACTION, STMT.NARR.FORMAT and STMT.NARR.PARAM.

41.

Use

GET.NARRATIVE

to

return

calculated

statement

narrative

using

TRANSACTION,

STMT.NARR.PARAM and STMT.NARR.FORMAT applications.

42.

To get the Accounting entries for a Contract for a particular date range, use the routine EB.GET.CONTRACT.ENTRIES.

43.

Use the routine EB.GET.ENTRY.DETAILS for the reconciliation entries for a Consolidated entry.

44.

Conversion of Amount with respect to Limit currency should use the routine LIMIT.CURR.CONV.

45.

To get Account balance for checking Overdraft purpose use the routine GET.WORKING.AVAIL.BAL.

46.

Use LIMIT.CHECK from applications both online and end of day to verify and update the limits system. The application is required to supply the correct values from the transaction in order to give the correct update to the system.

47.

Use LIMIT.GET.PRODUCT from applications to validate and default the Limit Reference used in a given transaction.

48.

T24 Interest Accrual processing should use EB.PERFORM.ACCRUAL for calculating the Interest.

49.

Charge Accrual process should use the routine EB.ACCRUAL.UPDATE to update Accrual information in Entry array to initiate e Core Charge Accrual process.

50.

Any read to Account related Files which has High Volume should use EB.READ.HVT routine instead of reading the file directly. This routine will do a notional merge and will give consolidated details. Below files need to be categorised as High Volume files. Example of some files are STMT.PRINTED, ACCT.STMT.PRINT, EB.CONTRACT.BALANCES, STMT.VAL.ENTRY

51.

Getting details on GL asset types should use the routine RE.TYPES.

52.

GL

setup

details

from

CONSOLIDATE.COND

should

use

the

routine

RE.READ.CONSOLIDATE.COND.

53.

Any GL related setup file for an Application need to use the routine RE.APPLICATIONS to get the details for CRF key formation.

54.

Asset type Validation should use the routine AC.CHECK.ASSET.TYPE.

55.

To check an Account for Contingent use the routine AC.CONTINGENT.

56.

Any cash flow update from contract should use the routine EB.CASHFLOW.HANDOFF to update the contract cash flow in relevant file.

57.

To get Credit check setup of the system for Account Cashflow use the routine GET.CREDIT.CHECK.

58.

For getting Group from the group setup for XX.GEN.CONDITION setup , use the routine EB.GROUP.

59.

The routine CALCULATE.CHARGE need to be used for any Charge , commission and Tax calculation in T24.

60. Routine APPL.GRP.CONDITION need to be called when we need the details of Contract group for an application based on XX.GEN.CONDITION setup.

61. Where there is a processing of data that belong to other company in a Multi company environment, use LOAD.COMPANY to load and Company basic Data like ID.COMPANY, R.COMPANY, DATES etc. They variables should not be set directly without calling LOAD.COMPANY.

62. Use GET.ACCOUNT.COMPANY to get the Company of an Account.

63. Get the Branch details of an Account using GET.ACCT.BRANCH.

64. Use FIND.CHARGE.REC to get CUSTOMER.CHARGE details for customer.

65. Any routine called from T24 hooks should be called after checking whether the routines exists using CHECK.ROUTINE.EXISTS.

66. System Cache uses inbuilt FUNCTIONS and provide better performance. •Use System.fetchFromCache to retrieve value for a table provided key to table is known. •Use System.putCache to load the record in specified cache bucket •Use System.getCache to retrieve value from a bucket •Use System.deleteCache to delete an item from bucket . Care to be taken when deleting cache only if functionality is not required 67. Use FIELD.NAMES.TO.NUMBERS for converting the Standard selection field names to numbers. For doing vice versa use the routine FIELD.NUMBERS.TO.NAMES

68. To check whether an application is NS enabled, use the routine NS.CONTRACT.CHECK. 69. Any Manipulation of common Variables should call COMMON.SAVE before processing and use COMMON.RESTORE after processing.

70. Avoid using OFS.GLOBUS.MANAGER. Instead use OFS.POST.MESSAGE to posts a message to an OFS queue which will be processed by the OFS message service.

71. Use EB.CLEAR.FILE to either clear file or selected data in a file.

72. Use EB.FORMAT.RATE to format rate values depending upon the system settings. If extended precision is on, the maximum no. of decimals allowed is 9 else it is 6. Total no of digits allowed for a rate value is 11.

73. Use EB.LOCREF.SETUP to get data based on local reference setup in an application.

74. Use GET.SETTLEMENT.DEFAULTS to get the default account and settlement details for a particular customer and application. Defaults may be obtained from Portfolio SEC.ACC.MASTER, AGENCY, CUSTOMER.CCY.ACCT or NOSTRO.ACCOUNT files.

75. Use EB.GETFIELD to retrieve a field or a set of fields from the current application record, another record within the same file or from another file using literal field names.

76. Use EB.OBJECT application for fields like ACCOUNT, DEPT.ACCT.OFFICER etc where length of field can be changed at EB.OBJECT definition across applications

77. Avoid using direct input commands through TXTINP, REM as User intervention is needed which is against T24 browser principles

78. Avoid using PRINT and CRT statements as it will simply display nothing in the user interface

79. Avoid using INPUT statement as the user cannot feed any data for the command and hence will lead the session to hang and/or terminate abnormally

80. Use UPDATE.HEADER to set enrichment against ID / Header details which is compatible with Desktop and browser interfaces

81. Please use EB.OVERRIDE.TOOL if any specific browser tool to be overwritten due to business functionalities

82. It is recommended to use the variable SESSSION.NO to fine tune any record ids

83. No SELECTS to be found within any looking structure or iterative processing.

84. There shall never be more than two levels of iterative processing. This is not from a performance perspective but from a code readability . However, if the level is more than two levels required, then branch out for better readability. Earliest opportunity to break out of a loop shall be considered and not a ceremonial completion of the iteraction

85. Key to a table where a lock is being acquired should never be a constant

86. The argument to F.READU for retry shall be passed as null unless the calling program has logic to handle the locking failure

87. Locking should not be applied for keys that gurantee uniqueness example SESSION.NO

88. User F.READU to lock a record which is already being read.

89. Do not write batch routines to be run the ONLINE stage of the COB rather do the same as service running during the intra day.

90. Do not alter core variables such as CACHE.OFF/WRITE.CACHE/ RUNNING.UNDER.BATCH shall never be tampered in application programs

91. Bulking shall be enabled in jobs only when the underlying transaction does not do heavy processing. (no rule here but good example would be accounting jobs are never put under bulk processing in COB ) or for jobs that do not do contentious locks

92. No log file is written by applications without a provision of parameter to turn on/off the log

93. Do no use a direct call to the System.getCache routine in the local routines.

94. Do not set HOT.FIELDS in field definitions. Always use them at version level validations.

95. Multiple calls to EB.ACCOUNTING from a single transaction/message has to be avoided.

96. LOCATE causes performance issues as it needs to scan through entire value and hence use it only if it cannot be avoided

97. Before

reading

a

record,

check

for

availability

in

common

variables

–

eg

Global/Product/Application/Batch commons etc and use it.

98. Concat files are not good but if it is on a static table and it helps selection it is fine to use. It has to be on case to case as the introduction of concat should not end up in locking contentions.

99. Avoid using VERSION AND VERSION.CONTROL routines for local template. All validations should be done in .VALIDATE or .AUTHORISE routines

100.

Following below needs to be avoided / considered when building a SELECTS 

No SELECTS should be written when you activation list concept



Do not hardcode the select for bulking. Specify them in the PGM.FILE



Avoid selection on huge files like STMT.ENTRY, CATEG.ENTRY



Do not do a READ operation inside a .FILTER routine



Use I_BATCH.FILES if you are using common variables for BATCH variables



Do not modify the incoming argument in a record routine unless you want to add a new ID to the job list



Avoid using SELECTS or any selection on field names if this is really not necessary. Selection on @id is much faster than selection done on fields

101.

For TAFJ related calls being done always assign the routine name to a variable and then

use the @ symbol to make calls to the routine. This is to avoid TAFJ compilation error 102.

In TAFJ, Do not specify the length of a record ID more than 200 characters. Failing to

adhere to this standard will cause the driver to throw ID constraints error at runtime

103.

In TAFJ, Always execute online or batch related service using the standard TAFJEE servlet

which will increase the performance of the jobs running rather than in a classic session for a TAFJ environment.

104.

In TAFJ, usage or variable increment like i++ should be avoided. Explicit imcrementing of

variables like i = i + 1 should be used in the codes

105.

In TAFJ, The use of CALLJ is obsolete, hence please do not use CALLJ instead CALLJEE

is enabled for any messages to be posted to queues. Below is the syntax for CALLJEE CALLJEE(ACTIVATION, INFO) ACTIVATION Specifies the activation string INFO  Contains the message string to be posted 106.

In TAFJ, there are only certain ITYPES supported. Hence  Any Itype that begins or contains SUBR  Any IF Itype that contains ENQ.TRANS OR SUBR  Any IF Itype that doesn’t start with IF

All the above should be avoided in TAFJ coding

107.

In TAFJ, Avoid hardcoding any characters like ‘{‘ and comparing the same using

MATCHES function For Example IF X MATCHES ‘{‘ will fail to produce the result when internalisation is turned on as UNICODE representation of ‘{‘ defers based on the where UTF8 is turned on or off. For TAFJ there is no specific handling as by default TAFJ is UTF-8

15. EXCEPTION HANDLING

Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program or subroutine execution.

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

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

IF INTERFACE.PARAM.ERR NE '' THEN

MESSAGE.INFO<3>='IDA.STAMP.RPT.GEN' MESSAGE.INFO<4>="Cannot find the record STAMP.DUTY.IND in

INTERFACE.PARAM table" TEXT = "Please create the record STAMP.DUTY.IND in INTERFACE.PARAM table" MESSAGE.INFO<1>='IDA.STAMP.RPT.GEN' MESSAGE.INFO<2>='' MESSAGE.INFO<5>='YES' CALL FATAL.ERROR (MESSAGE.INFO) END

16. MULTITHREAD ROUTINES

Multithreading in T24 is all about sharing the load or in other words task to be executed. One process at system operating level processing at list of id‟s will be slower than multiple copies of same process processing on the list of id‟s. This section explains the do‟s and dont‟s that needs to kept in mind before adopting multithreading concept in the routine, 1.

In a multithread routine, there should be a call to BATCH.BUILD.LIST in the SELECT routine which contains the selection list as its arguments.

E.g: SEL.CMD = "SELECT ":FN.ACCOUNT:" WITH CATEGORY EQ 1001" CALL EB.READLIST(SEL.CMD,SEL.LIST,'',NO.OF.REC,RET.CODE) CALL BATCH.BUILD.LIST(„ „,SEL.LIST)

2.

When requirement of the job is to perform different operations in sequence with the ability of the job to run parallel, CONTROL.LIST common variable can be used. CONTROL.LIST is initialized in the SELECT routine, which invokes the select routine for n number of times thus sequencing the different jobs within which every job can have parallel processing..

3.

The SELECT routine should contain only the CONTROL.LIST common variable and the SELECT statement to be executed. Do not define the process of the routine in SELECT statement. This is because, the select routine is executed only with one agent and hence defining the entire process of the routine in SELECT routine may cause serious performance issue. Define the process of the routine in the RECORD (PROCESS) routine.

4.

For multithread routines, do not use OPF in the PROCESS routine. This is because PROCESS routine is executed by number of agents, and hence the performance of the routine may go slower. So all OPF calls should be made in the LOAD routine since LOAD routine is executed only once and all the agents running the PROCESS routine will pick up the files from the LOAD routine.

5.

For multithread routines, variables must not be initialized in POST routine. This is because, if the POST routine is executed with any other agent other than the one which executed the load routine,

then the variable holds only NULL value.

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

17. CORE ROUTINES

Core routines are the routines that are developed inside T24 which cannot be modified but can be used in the in the program by calling the routine. Core routine reduces redundant set of statements that are called repeatedly and also reduces the complexity of the routine. Hence there is no need to code the statements instead simply make a call to the routine and pass the arguments For example, core routine CDD can be used to calculate the difference between two dates which not only reduces the complexity of routine but also reduces the time required to code these routines.

17.1DATE ROUTINES This section defines the set of core routines that can be used to calculate either forward or backward dates.

1.

When date routine CDD is used, it calculates the difference in dates when two dates are supplied. The return argument is the number of day‟s difference.

E.g: IF LAST.INT.SCHED LE VAL.DATE THEN PERIOD = 0 NO.OF.DAYS = 'C' CALL CDD("",VAL.DATE,TODAY,NO.OF.DAYS) CD.PROCESS = '1' END

2.

Call to routine CDT, calculates the forward or previous date from the start Date and number of day

E.g: IF DATE EQ TODAY THEN NO.OF.DAYS = '+3C' CALL CDT(" ",TODAY,NO.OF.DAYS) CD.PROCESS = '1' END

3.

Call to routine JULDATE will convert Julian date to Gregorian date or vice versa depending on which date is passed as argument in the routine. The other date must be NULL.

E.g GREG.DATE = '' TEMP.DATE = TODAY CALL JULDATE(GREG.DATE,TEMP.DATE.VAR)

17.2VALIDATION ROUTINES This section defines validation routines that can be used for validating particular field,

1.

For checking the duplicate occurrences of values in multi and sub valued fields at cross validation, call to DUP routine can be enabled.

2.

For validating a particular field whether, the field is multi-valued or sub-valued or null valued, call to FT.NULLS.CHK routine can be enabled.

18. EXCHANGE RATE

This section explains the available core routines that can be used for calculating the exchange rates

1. To calculate the exchange rate between foreign and local currency, call to the routine CALC.ERATE. foreign currency and foreign currency amounts are passed as the incoming arguments.

2. Call to the routine CUSTRATE performs all tasks involved in foreign exchange on two currencies on buy/s 3. Call to the routine EXCHRATE performs all tasks related to foreign exchange of two currencies 4. Call to the routine FCY.CONVERT.CHECK performs the following functions like,

1) Converts the local currency to foreign currency or vice versa when either of the currency amounts 2) Calculates exchange rates when both local and foreign currency amounts are passed, 3) Recalculates local and foreign amount and returns the difference, 4) Calculates percentage exchange rate difference, when a rate is passed.

19. COB ROUTINES

This section explains the criteria that should be considered while writing COB routines, 1. All new batch records must have an equivalent record in BATCH.NEW.COMPANY application. 2. All new batch process should be written to use multithreading. 3. Do not test the SPF status of the routine during the COB procedure because this will be set as soon as the COB is initiated. So the routine doesn’t know if it has been invoked from „action line‟ or run as a part of the routine. 4. Do not call template programs from batch. Isolate the program you require into subroutine and then call the subroutine and the template program 5. Never prompt during Close of Business. Use “OCOMO” instead of CRT to record the progress of the job 6. Do not use HUSH or! HUSHIT since the output from the commands are very useful in analyzing the COB execution. 7. Never use “STOP” to terminate a batch process. Always use “FATAL.ERROR” to terminate a batch job when error condition occurs. 8. The FATAL.ERROR should be used with proper text only if you don‟t want the COB process to proceed. This will log the errors in EB.EOD.ERROR. For low level errors, EXCEPTION.LOG can be used to flush the errors.

20. CORE REUSABLE ROUTINES The other available core routines in T24 which can be used in the routine are as follows,

1.

The available core routine EB.ACCT.ENTRY.LIST can be called to get the list of statement entry details provided the account number, start date and end date is provided as incoming arguments to the routine.

CALL EB.ACCT.ENTRY.LIST (ACCOUNT.NUMBER, FROM.DATE, END.DATE, YID.LIST, OPENING.BAL,ER) 2.

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

CALL EB.READ.WRITE.TABLE (APPS.ID, APPS.NAME, RD.WRITE.DEL, IN.DATA, OUT.MSG

3.

Before running COB, if user want to verify the unresolved Errors of the last COB, then routine EB.EOD.UNRESOLVED.ERR can be used which gives the list of errors for the date inputted, EB.EOD.ERROR Record id must be passed as an Input, where as the EB.EOD.ERROR id, is the combination of Company Id and Date

CALL EB.EOD.UNRESOLVED.ERR (UNRESOLVED.FLAG, RECORD.ID)

4.

The core routine EB.VALIDATE.FREQUENCY will validate a frequency supplied in short frequency format (M0101/D/W). It will validate the values entered and return the corresponding entry.

CALL EB.VALIDATE.FREQUENCY (IN.FQU, OUT FQU, ERR.MSG)

5.

The routine EB.HIST.REC.WRITE helps to write a new record to a live file while moving the existing record to history file.

CALL EB.HIST.REC.WRITE (FILE.NAME, RECORD.ID, MAT RECORD, RECORD.LENGTH)

6.

The subroutine EB.GET.ACCT.BALANCE is used to return the balance of an account on a requested date. We can also get the CREDIT and DEBIT movement on this date.

CALL EB.GET.ACCT.BALANCE (ACCT.ID, ACCT.REC, BALANCE.TYPE, BALANCE.DATE, SYSTEM.DATE, BALANCE, CREDIT.MVMT, DEBIT.MVMT, ERR.MSG)

7.

The routine EB.DATE.FORMAT.DISPLAY displays date in alphanumeric format. If a value of „20080102‟ is supplied, it will return as „02 JAN 2008‟.

CALL EB.DATE.FORMAT.DISPLAY (DATE.VALUE, DATE.DISPLAY

Standards 8.

The subroutine EB.FORMAT.RATE simply formats the rate supplied. It extends the decimal places to 9 digits (following by 0‟s) else truncate and round off decimal places, if it‟s more than 9 digits, then leading 0‟s are replaced.

CALL EB.FORMAT.RATE (RATE)

9.

The routine EB.COPY.LOCAL.FIELDS is used to copy data of local reference fields to another application. Input arguments would be the ID and application of source and destination. Output would be record with local reference fields from source record.

CALL EB.COPY.LOCAL.FIELDS (APPS.ID.FROM, APPS.FROM, APPS.ID.TO, APPS.TO,TO.REC)

10. The routine EB.INTEREST.BASIS can be called in any process when we need the description or interest basis text for corresponding interest basis. Input argument would be the interest basis ID and output would be the interest basis text.

CALL EB.INTEREST.BASIS (INT.BASIS, INT.BASIS.TEXT)

11. The subroutine GET.NOSTRO.CUST can be invoked to get the customer ID of a given NOSTRO.ACCOUNT. It checks LIMIT.REF field is NOSTRO in the account application and will give customer id as output.

CALL GET.NOSTRO.CUST (NOS.ACC, NOS.CUST.ID)

12. The subroutine EB.CALL.JAVA.API is used to call java API from EB.API. Suppose if the EB.API file is having an entry and source type as java then this is the routine used to call Java API. EB.CALL.JAVA.API routine has the following function

1) It will check the EB.API having the value in JAVA.PACKAGE, JAVA.CLASS, JAVA.METHOD 2) If the above fields are having value and source type is equal to JAVA then this routine will trigger the CALLJ engine through EB.CALLJ routine

CALL EB.CALL.JAVA.API(EB.API.ID,CALLJ.ARGUMENTS,CALLJ.RESPONSE, CALLJ.ERROR)

13. The subroutine EB.CALC.REPAYMENT is used to calculate the repayment amount for a particular contract by providing the appropriate data like principle amount, currency, annual rate of interest and interest basis etc.

CALL EB.CALC.REPAYMENT (PRIN, CCY, RATE, LIFE, FREQ, TYPE, INTEREST, RESIDUAL.AMOUNT, START.OR.END, DAY.BASIS, ROUNDING, REPAY.AMOUNT)

14. EB.LEAP.YEAR is a subroutine to find out whether the year is a Leap year or not. If year and T24 Internal date is passed to check for leap year, It will send the Leap year YES/NO flag through the output parameter.

CALL EB.LEAP.YEAR (I.YEAR, I.DATE, LEAP.YEAR, NO.DAYS.IN.YEAR, CONTROL.VAR, RES1, RES2)

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

CALL EB.MSK.FIELDS (APP.NAME, RECORD.ID, R.RECORD, MASK.FLD.LIST, APPL.MSK.CHARS)

16. The routine GET.CCY.HISTORY is used to find the values of the CURRENCY record or FORWARD.RATES record in a historic date supplied. If the date passed does not match, it will return the earliest or nearest match, where as it will tell using RETURN.CODE

CALL GET.CCY.HISTORY (HIS.DATE, YCCY, CCY.DATE.REC, RETURN.CODE)

17. The routine EB.IN2.CALL is used to validate any value against T24 IN2 Routines. The value to be validated is passed from COMI and incase of any Error, ETEXT will hole the error message, it performs two types of validation, ID and Field level validation, which is mandate to be mentioned.

CALL EB.IN2.CALL (INPUT.TYPE, N1, T1)

18. The routine EB.GET.OVE.ERR.ID generates a unique error/override number code to be attached in the error/override record. Simply increment the counter value in F.LOCKING file.

CALL EB.GET.OVE.ERR.ID (ACTION, THE.ID)

19. The routine EBS.CREATE.FILE is used to create DATA and DICT files. We can specify the path where the DATA file to be created. We can also specify the type and modulo. It is mainly used to create files for archiving.

CALL EBS.CREATE.FILE (FILE.TO.CREATE, DATA.OR.DICT, ERROR.MSG)

20. The routine EB.RECORD.MOVE is used to delete a record from a LIVE file based on the values in the incoming arguments and write the record back to the history.

CALL EB.RECORD.REMOVE (FILE.ACTION, REC.ID, RET.CODE)

21.

The Core routine EB.CALC.TERM is called to return the number of due payments provided principal

amount, currency, rate of interest, repayment amount are passed as incoming arguments in the routine.

CALL EB.CALC.TERM(PRIN, CCY, RATE, LIFE, FREQ, TYPE, INTEREST, RESIDUAL.AMOUNT, START.OR.END, DAY.BASIS, ROUNDING, REPAY.AMOUNT)

22.

The Core routine EB.GET.APPL.FIELD can be called to return either the field number or field name from the Standard Selection table if either of these fields is provided as argument for the called routine.

CALL EB.GET.APPL.FIELD (APPL.NAME, FLD, R.SS, ERR.MSG)

23.

EB.READ.HISTORY.REC is used to READ the HISTORY FILES.

CALL EB.READ.HISTORY.REC (F.FUNDS.TRANSFER.HIS,TEMP.FT.REF,R.FUNDS.TRANSFER.HIS,FUNDS.TRANSFER.HIS.ER R)

24.

Do not use CALL OPF for STANDARD.SELECTION. Kindly Use Core API.

CALL GET.STANDARD.SELECTION.DETS (X.APPLICATION, R.STANDARD.SELECTION)

25.

Kindly use OFS.CALL.BULK.MANAGER () instead of using OFS.BULK.MANAGER ().

26.

Use Public API ofs.addLocalRequest (...) for BULK OFS Transaction

21. UTILITY ROUTINES

Utility routines are developed as part a local development. These routines can be called from any program by passing proper arguments. For further clarifications, refer the RAD Utility Document.

1.

COMP.ACCT.BALANCE : The routine COMP.ACCT.BALANCE is used to compare the online cleared balance and working balance of the account. If the online cleared balance is not equal to working balance and working balance is greater than online cleared balance, the results are taken out.

2.

CHECK.ADI.FOR.AC: The routine CHECK.ADI.FOR.AC is used to check the debit interest for the account. This subroutine can be used to get ACCOUNT.DEBIT.INT records which are used to calculate interest amount for the group of customers

3.

GET.T24.FILE.LIST: The utility program GET.T24.FILE.LIST is used to list down all the files present in VOC. This can be used when there is a need of all the files in T24, their size, product code, size, record count, and file type. The output of the program is stored in the &SAVEDLISTS& file..

4.

GET.CUST.ACCT.DETS: The routine GET.CUST.ACCT.DETS , is a called subroutine, with one I/O Argument. If the Customer number is passed as input, it will return the list of accounts for that customer. If customer is not available it will return the error.

5.

S.MONITOR.COB.TSA: The program S.MONITOR.COB.TSA is used to monitor the agents during close of business. It accepts agent number and display the details of COMO. It will also accept the time delay which we should refresh every time. The system will check for each selected record whether the agent is in the monitored list.

6.

LOC.DEV.LISTING : The utility routine LOC.DEV.LISTING will provide list of details about the given BP can be fetched through the routine. The details are Routine Name, Code lines of the Routine, Command lines of the routine, total number of lines and code efficiency of the routine. At last .CSV file will be created with the routine details in &COMO&

7.

GET.CATEG.LIST : The GET.CATEG.LIST is used to get the list of Category Entry for the supplied Category within the range of given Booking date, consolidate the category for a date and sum up the Amount Lcy and Fcy, along with STMT.ENTRY Id‟s.

8.

GET.LOCKED.EVENTS : The mainline routine GET.LOCKED.EVENTS, is used to display the unlocked amounts for the given date and descriptions. Data is retrieved from the application, AC.LOCKED.EVENTS..

9.

VIEW.JOB.LIST : The utility routine VIEW.JOB.LIST is used to get and display the job lists count and Ids; Job List start and end number is inputted by the user. This is very useful while running COB, and multi threaded Services.

10.

PROCESS.ACTIVITY.MONITOR : The info basic program PROCESS.ACTIVITY.MONITOR is used to monitor the process, commands or background activities. E.g., SELECT, COUNT. Output will be updated in the log file PROCESS.ACTIVITY.MONITOR.LOG.

11.

PROCESS.MONITOR: The info basic program PROCESS.MONITOR is executed from jbase prompt to monitor the process and update the log file in the given frequency.

12.

ADD.FUNC.TO.SMS: The routine ADD.FUNC.TO.SMS is used to add a function to a record in USER.SMS.GROUP. The routine must be called from T24, along with the USER.SMS.GROUP id and the function (A B 2 C D E H I L P Q R S V) to be included in that record.

13.

GET.ROUTINE.DETAILS The routine GET.ROUTINE.DETAILS is used to get the list of all files and find out the location of the actual code; it takes the full path of a „lib‟ as argument. It opens the respective „objdir‟ under that „lib‟ to process all „obj‟ files to find the actual location of each file.

14.

VERSION.RTN.DETAILS : The routine VERSION.RTN.DETAILS is used to get the various routines attached to a specified version. It takes an array with list of version to be processed. The result will be stored in .csv file under a specified directory.

15.

SYSTEM.APPL.SEARCH: The routine SYSTEM.APPL.SEARCH is used to find the occurrence of local routines in various applications. It also searches various BP‟s to return the list of routines calling this routine. It takes the list of routines and BP to process and return with the .CSV file that contains occurrence of routine in various applications and list of routines which call this.

16.

GET.PROGRAM.DETAILS.JBASE : The routine GET.PROGRAM.DETAILS.JBASE is used to get the details of routines using „jshow c‟ command. It checks for I.

Whether the routine compiled or not

II.

Have VOC entry or not

III. Is the local or core program

17.

IV.

Compiled BP and Source BP details

V.

Core duplicate or not

GET.VERSION.DETAILS : The routine GET.VERSION.DETAILS is used to get the details of all versions. It process each routine attach to the various field of version (INPUT, AUTH, ID, VALIDATION, etc.). For each routine it gets the following details, Whether the routine compiled or not Have VOC entry or not Is it a local or core program Compiled BP and Source BP details Core duplicate or not All details are written to a file named „VERSION.LIST‟ under a directory

AA – THINGS TO REMEMBER

22. LOCAL COMMONS in AA AA has a defined set of variables which are exposed as commons to be used in Local APIs. These are available in I_AA.LOCAL.COMMON. The following are the details of these variables: c_aalocArrId, ;* Arrangement id c_aalocArrangementRec, ;*Main arrangement record c_aalocArrProductId,

;* Stores the product used by the arrangement

c_aalocArrCurrency,

;* Store the currency used by the arrangement

c_aalocActivityId,

;* Activity id loaded in the property

c_aalocTxnReference, c_aalocCurrAction,

;* Arrangement activity transaction reference ;* 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, c_aalocPropertyId, c_aalocProdPropRec, c_aalocActivityStatus, c_aalocArrActivityId,

;* Property class ID of current property ;* Current property ;* Stores the published product property for the arrangement ;* Stores the status of current activity like . UNAUTH, DEL, REV-DEL ;* Store the arrangement activity id

c_aalocActivityEffDate, ;* Effective date c_aalocAccountDetails,

;* Account Details

Programming Standards

23. VERSIONS and APIs in AA

1) No routines should be defined in the versions defined in ACTIVITY.PRESENTATION. The versions should only define screen layout. 2) Pre and Post routines (if any) are called during all stages of template – like Input, Delete, Authorization, Reversal etc. Hence the developer should branch the control to specific codes in the local routine. 3) Avoid using AA commons in the local routines. Equivalent local common variables have been released use these common variables (Refer the insert file I_AA.LOCAL.COMMON) 4) AA Commons if used should never be modified by local routines. 5) Both the Pre and Post routines currently do not have any arguments. 6) Never read the files on Catalog/Arrangement directly using F.READs. Use the API(discussed later) for the purpose. 7) All arrangement records are dated, For example if a record already exists for 01-Jan and a new record is currently being updated for 01-Mar, the ID.OLD/R.OLD of the property would NOT be NULL. They would refer to 01-Jan date and record respectively. 8) AA would not allow modification on an authorised record. When a similar activity is attempted, system creates a new SEQ number for the date and ID.OLD/R.OLD would refer to the previous sequence record. 9) When a Change-on-change is performed on a property, system would first delete the record and then commit the new record. So, do not be surprised if the local code for Delete gets executed during Input. 10) Usage of R.NEW.LAST should be avoided in Local routines for the reason stated above. Since delete clears the previous input, the actual Input record would not load R.NEW.LAST 11) Local

developers

should

not

assume

all

requests

would

hold

OFS$SOURCE.REC would hold SESSION even if it is a browser request. AA mixes SESSION and T24 requests frequently. 12) Even if the user Authorises the request through Browser front-end, the requests are all processed as Vanilla requests. 13) There would be no local provision to do ID checks or defaulting through .RECORD routine. All defaults should be driven by product condition. 14) If there is a need to generate secondary or child activity for the given arrangement in the local routine

use

the

core

APIs

–

AA.GEN.ARRANGEMENT.ACTIVITY.FIELDS

and

AA.GEN.NEW.ARRANGEMENT.ACTIVITY (Explained in detail under the section Useful APIS)

15) A new function – called M- has been introduced. The feature of this function is that it still flows through the template, but does not leave any trace of its execution. There would not be any new ids created after a M function has run on the template. M function does execute the Pre and Post APIs that have been written for the activity. M function does not commit the property record, 16) Classic and Desktop are not supported - no support for online prompts or displays.

24.

CORE TABLES IN AA FOR LENDING The AA product line which offers retail and lending functionality is LENDING. Temenos has

released the LENDING product line with its required property classes, activities and action routines. The client can design lending products using the product builders. The activity to create new arrangements for lending product is LENDING-NEW-ARRANGEMENT. When this activity is triggered using AA.ARRANGEMENT.ACTIVITY, new arrangement is created with a unique number. New record is created in the live application AA.ARRANGEMENT. For lending product lines, the related core application that is affected is ACCOUNT. Every new arrangement creates a new account record. Account record is the actual contract for the product (equivalent to LD contract). The arrangement id is stored in the account record. This account will be accessible only thru AA activities. AA.ARRANGEMENT

The AA.ARRANGEMENT record stores the static information of the arrangement like customer, currency, the related application id, the start date of the arrangement, its product and the product properties. The current status of the arrangement can also be known from this record. AA.ACCOUNT.DETAILS

AA.ACCOUNT.DETAILS is another live file which holds account and bill information for a given arrangement. This file holds value date of the arrangement, its drawdown date, maturity date, payment start date. The bills generated for the arrangement, the bill statuses, payment information, bills repaid and whether the arrangement is suspend or not – all the above information is stored in this file

25. TRANSACTION BOUNDARY FOR AA

1. System issues a TRANS.START even before the processing of application starts. 2. Processing issues F.WRITEs, F.DELETEs. These do not go to the disk directly. They are updated in the T24 IO cache(FWT, FWC, FWF variables) 3. Direct WRITEs and DELETEs DO NOT hit the database directly. Since the transaction is already in a boundary, system only updates the jBase cache. Local code developers should keep this in mind. 4. JOURNAL.UPDATE (for templates, these are called in UNAUTH.RECORD.WRITE, and AUTH.RECORD.WRITE) would flush the T24 cache to jBase cache. 5. System processes multiple transactions(this currently applies only for AA) 6. All updates are held now in jBase cache. 7. If all transactions get processed successfully, system issues a TRANS.END to update the jBase cache to disk. 8. If any of the transaction fails, system issues a TRANS.ABORT to clear the jBase cache. 9. Please refer to the Core Transaction management document for further details on this. NOTE: TRANSABORT, TRANSTART, TRANSEND are not to be used anywhere in the local development code

26. SPECIAL ABOUT AA BATCH PROCESSING 1. There is a single major difference between AA batch execution and other T24 batch processing. Even whilst executing the scheduled activity, system would always pass through normal Template route i.e. process activities via AA.ARRANGEMENT.ACTIVITY. All activities performed either - online or COB - share the same code since they are all executed through templates. So the way a scheduled Rate change is executed in COB would be no different from a rate change triggered by the user online. In COB, the AA.ARRANGEMENT.ACTIVITY would be triggered through an OFS message (since that is the standard T24 methodology by which a template is accessed if it is not user initiated). 2. Please be noted that currently ALL AA COB jobs are .NTX which means they do not use the Transaction management initiated by BATCH.JOB.CONTROL. Since AA uses the new Transaction boundary and there is no difference between Online and COB transactions, it deviates from the BJC‟s transaction management. 3. Users performing local development should keep this in mind. So, if there is a local API which gets triggered during –say rate change- the same would be triggered during COB process as well. If an update is not supposed to happen during COB process, then it is the developer‟s

responsibility to add RUNNING.UNDER.BATCH condition and stop the execution

27. USEFUL APIs

There are lots of core API‟s which are never being used in local codes, which may save time as well as performance. So try to check the availability in core routine, before coding it locally. Most of the API‟s are like AC.GET …, FT.GET…, LD.GET… etc. (e.g.) AC.GET.ACCT.ENT.TODAY.LWORKDAY, can be used to fetch the Entry id‟s from ACCT.ENT.TODAY,ACCT.ENT.LWORK.DAY. Find below few AA API‟s which may help in your Developments

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

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

areequated

commonsin

I_AA.APP.COMMON IN(Mandatory)

Product.property.Id

The Id of the product or the property name for which details are sought.

IN(Mandatory)

effectiveDate

The date for which property/product details are sought. If the property record does not have a record on that date, the past record nearest to that date is returned.

OUT

Published record

The record of product/property returned from the stage requested

OUT

returnError

Errors if any during the processing

AA.GET.PROPERTY.CLASS This simple routine returns the class to which the property belongs. 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

AA.GET.ARRANGEMENT.PROD UCT 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)

AA.GEN.ARRANGEMENT.ACTIV ITY.FIELDS This

method

maps

the

arrangement properties, its field name and its value to new arrangement

activity

Values

be

can

record.

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 record

AA.GEN.NEW.ARRANGEMENT.

ACT

Fields The formatted arrangement activity record

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

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

EB.CONTRACT.BALANCES as

as on

in the

requested date. If the balance type is virtual then sum of all the virtual balance is returned OUT

Return error

Error if any

VERSION

VERSION is a standard T24 application which allows users to create customised screens for input, authorisation, display etc. It may also be used to automate the replacement of data on records. In fact T24 comes with many useful VERSION records for the majority of T24 applications. It is also possible to add local sub-routines which can be used for field, input and authorisation validation. These small programs will allow even greater customisation of T24 by the user.

The following points must be adhered while creating versions in T24,

1.

Number of Versions used must be limited.

2.

Redundant codes used in Version can be defined in VERSION.CONTROL

DOCUMENT DETAILS

1.

Document approach should be from Test Cases.

2.

Use “Snag it” tool for Screenshots.

3.

Document should contain the detailed functionality of the module along with Workflow diagram.

4.

Document should contain all the Parameter setup required for the respective module.

REDESIGNING A DEVELOPMENT

1.

If reusable components are identified while redesigning the code, it must be informed to TL or PL, so that the same can be packed and can be used later by all.

E:g: Requirement for NBF : Utility routine done for NBF

In Reuters Dealing TOF, if the deal has incorrect information, the deal will be put in IHLD status and the OFS RESPONSE will be sent with the error status “-1”. If the OFS RESPONSE is received with the “-1(Failure)” status, table OF.REUTERS.SEQN will not get updated. Because the deal was picked up again and again; this caused more no of deals in IHLD.

To avoid this utility routine was written to amend the Status in the OFS RESPONSE. Since the deals are available in IHLD or INAU status, in all the cases, OFS.RESPONSE was sent with the Success status “1”.

This utility routine was handover to RLM team and it is now reused by many clients.

Similarly reusable codes or utility routines done for a particular bank should be identified and informed to RLM team for reusability.