• Author / Uploaded
• Coba Coba

Citation preview

Client Specific Development PROGRAMMING STANDARDS

Information in this document is subject to change without notice. .

Internal Use V 10.0

Author

Version

Ponnarangam Shanmugam Shameem Ahmed

V.01

Date 20 Jan 2008

Reviewed V.01

Arun Prakash. R

V.02

Shameem Ahmed

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

Reviewed V.06

Mohanraj. R

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

Jude

Updated V 10

6-Sep18

EPG

Baselined V10

21-Sep018

Internal Use V 10.0

Table of Contents 1.

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

2.

Reference Documents ...................................................................................................................... 6

3.

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

4.

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

5.

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

6.

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

7.

USAGE OF VARIABLES ................................................................................................................ 17

7.

CODING STANDARDS .................................................................................................................. 19

7.1 GENERAL STANDARDS ................................................................................................................. 20 8.

USE OF LOOPS .............................................................................................................................. 34

9.

USE OF MULTI.GET.LOC.REF .................................................................................................... 36

10.

jBASE STATEMENTS AND COMMANDS .............................................................................. 37

11.

PERFORMANCE CONSIDERATIONS ................................................................................... 47

11.1

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

11.2

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

12.

USE OF IN2 ROUTINES ........................................................................................................... 54

13.

T24- SECURE CODING STANDARDS ................................................................................... 55

13.1

Basic ......................................................................................................................................... 55

13.2

Information leakage ................................................................................................................ 55

13.2.1

Access control ................................................................................................................ 55

13.2.2

Insecure Storage ............................................................................................................ 55

14.

FILE HANDLING ......................................................................................................................... 56

15.

EXCEPTION HANDLING ........................................................................................................... 66

16.

MULTITHREAD ROUTINES ..................................................................................................... 68

17.

CORE ROUTINES ...................................................................................................................... 70

17.1

DATE ROUTINES................................................................................................................... 70

17.2

VALIDATION ROUTINES...................................................................................................... 72

18.

EXCHANGE RATE ..................................................................................................................... 73

19.

COB ROUTINES ......................................................................................................................... 73

20.

CORE REUSABLE ROUTINES ................................................................................................ 74

21.

UTILITY ROUTINES ................................................................................................................... 81

22.

LOCAL COMMONS in AA ......................................................................................................... 84 Internal Use V 10.0

23.

VERSIONS and APIs in AA ....................................................................................................... 85

24.

CORE TABLES IN AA FOR LENDING .................................................................................... 86

25.

TRANSACTION BOUNDARY FOR AA ................................................................................... 87

26.

SPECIAL ABOUT AA BATCH PROCESSING ....................................................................... 87

27.

USEFUL APIs .............................................................................................................................. 89

Internal Use V 10.0

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 Product-Secure coding standards. This document shall be reviewed on a periodic basis in order to ensure consistency with T24 release specific developer guides.

Internal Use V 10.0

Programming Standards

2. Reference Documents Procedure / Process Name http://uni-t.temenos.com/dms/QMS/L2L3/Documentation/Coding_Procedure.doc?Web=1 http://gva2flare.temenosgroup.com/doc/ Developer Guides available in each T24 Release

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

Internal Use V 10.0

Programming Standards

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

5. 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 Internal Use V 10.0

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

Internal Use V 10.0

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

Internal Use V 10.0

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

Internal Use V 10.0

Programming Standards 6. NAMING CONVENTION & PACKAGING

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.

6.1 Subroutines All subroutines to follow the below naming conventions. can be meaningful name along with Dev Name / Interface Name / BRD Name 

Interface Name ( Example : BACS, CHAP )



DEV Name ( Example : APR, IRR ) Example: CSD.ANC.BACS.ID.UPDATE CSD.INP.APR.CALC.UPDATE

Internal Use V 10.0

Routine Type

Sample Routine Name

Auto New Content Routine

CSD.ANC.

Check Record Routine

CSD.CHK.

Id Routine

CSD.ID.

Validation Routine

CSD.VAL.

Input Routine

CSD.INP.

After Unau Routine

CSD.UA.

Before Auth Routine

CSD.BA.

Auth Routine

CSD.AUT.

Deal Slip Routine

CSD.DS.

Delivery Routine

CSD.DE.

Build Routine

CSD.BLD.

Conversion Routine

CSD.CNV.

Nofile Routine

CSD.NOF.

Batch Routine

CSD.B.

Main Line Programs

CSD.MNL.

Generic Routines

CSD.GEN.

OFS Routines

CSD.OFS.

Hook Routines

CSD.HK.

Archive Routines

CSD.ARC.

Correction Routines

CSD.COR.

AA Activity API Pre Routine

CSD.AA.PRE.

AA Activity API Post Routine

CSD.AA.POST.

AA Activity API Record Routine

CSD.AA.REC.

AA Activity API Validation Routine

CSD.AA.VAL.

AA Activity API Pre Validation Routine

CSD.AA.PRE.VAL.

AA Charge Routine

CSD.AA.CHG.

AA Source Calculation Routine

CSD.AA.SRC.CALC.

Internal Use V 10.0

6.2 Data Records All Data records to follow the below naming conventions

Data Record Type

Sample Name

TEMPLATE VERSION ENQUIRY EB.ERROR

CSD. ,CSD. CSD. EB-CSD.

EB.COMPOSITE.SCREEN EB.TABBED.SCREEN BATCH / TSA.SERVICE OVERRIDE DEAL.SLIP.FORMAT OFS.SOURCE

CSD. CSD. /CSD. CSD. CSD. CSD.

STANDARD.SELECTION LOCAL.TABLE HELPTEXT.MENU BATCH.NEW.COMPANY AA.PRD.DES.

CSD. CSD. CSD. CSD. CSD.

AA.PRD.DES.ACTIVITY.PRESENTATION

CSD.

AA.PRD.DES.ACTIVITY.CHARGES

CSD.

REPORT.CONTROL

CSD.RC.

ENQUIRY.REPORT

CSD.ER.

Note: All L3 specific data should have the keyword “CSD” irrespective of the above table. The sections given in Angular brackets (* *) should be meaningful and short name Example: For a BATCH record /CSD. the name could be BNK/CSD.APR.CALC Where  BNK  APR.CALC

Internal Use V 10.0

6.3 Packaging 6.3.1 Source Jar Naming Convention: _.jar Example: CSD_1906640.jar DPGP03 _1906640.jar

6.3.2 Insert files Jar Naming Convention: __Inserts.jar Example: CSD_1906640_Inserts.jar DPGP03 _1906640_Inserts.jar WI Number – Temenos will provide Work Item number CSD or BRD/FSD Reference – CSD to be the default-naming prefix for projects, BRD/FSD Reference to be added based on client recommendations

4.

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

5.

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. Internal Use V 10.0

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

Internal Use V 10.0

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

Internal Use V 10.0

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

7. 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 Internal Use V 10.0

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.

Internal Use V 10.0

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). Internal Use V 10.0

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: Internal Use V 10.0

/Statements RETURN

Internal Use V 10.0

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) REM > PROCESS.GOAHEAD = 0 REM > END ELSE REM > SIGN.POS = CU.LREF.POSNS; TAX.ID.POS = CU.LREF.POSNS; TAX.ID.TYP.POS = CU.LREF.POSNS REM > END END CASE LOOP.CNT += 1 REPEAT

Internal Use V 10.0

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.

Internal Use V 10.0

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 = @ (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)

Internal Use V 10.0

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

Internal Use V 10.0

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' Internal Use V 10.0

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 EQ "DIS" THEN Y.PRE.VAL.DATE = OUT.ARR.VAL.DATE BREAK END J+=1 REPEAT RETURN

E.g:

Proper way of Coding PROCESS: LOOP WHILE J LE PRE.CN IF OUT.ARR.MG.DESC EQ "DIS" THEN Y.PRE.VAL.DATE = OUT.ARR.VAL.DATE RETURN END J+=1 REPEAT RETURN

Int ern al Us e V 10. 0

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

Internal Use V 10.0

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

Internal Use V 10.0

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 = Y.RES.DELIN.CUST REPEAT WRITESEQ Y.DELINQ.ERROR TO DELINQ.RESPONSE.PTR ELSE STOP END END RETURN

Programming

Internal Use V 10.0

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 = 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 Internal Use V 10.0

field properties alone 27.

Do not use more than ten local fields.

28.

Use CALLJEE instead of CALLJ from R10 release onwards.

Internal Use V 10.0

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

T24 Standard Core API's.xlsx

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

Internal Use V 10.0

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

Int ern al Us e V 10. 0

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,

Internal Use V 10.0

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

Internal Use V 10.0

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 NBU.B010.POS= POS MFO.CODE.POS= POS

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,

Internal Use V 10.0

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.

Internal Use V 10.0

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)

Internal Use V 10.0

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.

Internal Use V 10.0

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.

Internal Use V 10.0

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 Internal Use V 10.0

complex expressions.

Internal Use V 10.0

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. Internal Use V 10.0

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 Internal Use V 10.0

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.

Internal Use V 10.0

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 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) Internal Use V 10.0

FOR CNT = 1 to NO.ITEMS

Internal Use V 10.0

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. Internal Use V 10.0

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 Internal Use V 10.0

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

Internal Use V 10.0

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.

Internal Use V 10.0

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

Internal Use V 10.0

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