0% found this document useful (0 votes)
17 views16 pages

Day4a T24 Programming Standards

The document outlines programming standards for T24 subroutines, emphasizing modular structure, naming conventions, and performance considerations. Key guidelines include keeping routines concise, avoiding deeply nested constructs, and adhering to specific naming formats for variables and subroutines. Additionally, it stresses the importance of using capital letters for keywords and provides examples of proper syntax and variable usage.

Uploaded by

Krishna Tejap6
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views16 pages

Day4a T24 Programming Standards

The document outlines programming standards for T24 subroutines, emphasizing modular structure, naming conventions, and performance considerations. Key guidelines include keeping routines concise, avoiding deeply nested constructs, and adhering to specific naming formats for variables and subroutines. Additionally, it stresses the importance of using capital letters for keywords and provides examples of proper syntax and variable usage.

Uploaded by

Krishna Tejap6
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

T24 Programming

Standards

Slide1
Introduction

There are some standard rules to be considered while writing T24


subroutines. These standards allows other programmer can easily
read, understand and support your programs.

Slide 2
Program Structure
• All routines in T24 are called subroutines. Routines must not be written in such a way
that they are executed directly from jSHELL.

• TEMPLATE programs should be less than 2000 lines.

• Subroutines should be less than 600 lines. Ideally the code should be broken down
into internal subroutines.

• Each routine should have one main controlling section with the detailed code written
as subroutines.

• All code should be structured in a modular fashion and broken into small
units/paragraphs (less than 100 lines) and each unit should have a single entry and
exit point.

• Avoid deeply nested IF's and large case constructs. If an IF construct exceeds 20
lines then use a GOSUB

• Keywords should not be used as Variables. E.g IF, THEN, ABORT, ABS etc..

• Labels, Variables and Routines should not use the same names.
Slide 3
Program Structure
• Labels must exist on their own line with no other text appended to the label.
E. g.. The following way in incorrect.
OPEN.FILES: *This section open all required file
FN.ACCOUNT = „‟
F.ACCOUNT = „‟
The correct way is:
OPEN.FILES:
* This section open all required file

FN.ACCOUNT = „‟
F.ACCOUNT = „‟

• Do not use multi-statement lines:


E.g.
FOR I = 1 TO 10; Y.TOTAL.CNT += S.TOTAL<I>; NEXT I
Use the following instead:
FOR I = 1 TO 10
Y.TOTAL.CNT += S.TOTAL<I>
NEXT I

Slide 4
Program Structure
• Code should not be commented out - remove it.

• File variable names must be F.filename (Where file name is the EXACT name
of the file e.g. F.ACCOUNT);
similarly record variables should be R.filename.

• Fields must never be referenced by their field number (except in conversion


routines). You must use the field names supplied in the standard inserts.

• Avoid using FOR…NEXT loops, use the more efficient LOOP…REMOVE


syntax.

• All subroutines, both the subroutine itself and internal subroutines, should
return from a single exit point.

• Do not pass common variables as arguments to subroutines,

Slide 5
Routines to be structured like:

Slide 6
Naming Conventions

Constants and Variables:

There are 3 basic levels of variables in T24 programs


1. Global
2. Product
3. Subroutine

1. Global Variables: are defined in I_COMMON. This insert is included in


every T24 program. The variable prefix is C$.

2. Product level Variables: are defined in product level common block. E.g
I_ENQUIRY.COMMON. The variable prefix is XX$

3. Subroutine Level Variables: are used only in the subroutine in which


they are defined.

Slide 7
Subroutine Names

• Subroutine names and variable names should be in upper case

• Subroutine names are limited to 35 characters.


(Because of Length Restriction in PGM.FILE)

• Subroutine names should begin with the product prefix and then
describe the routine, e.g. FT.INPUT.RTN.

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

• Subroutine names cannot be named with an extension of B. The


extension b is a reserved extension for c code. Best to avoid using
extensions like, .doc, .xls, .c, .cpp, .jar, .java, .class.

• When coding subroutine, it should be ensure that <name> portion


code is identical to the source code name.
Slide 8
MCB Specific
• Routine names should end with .MCB.MU
Ex: E.SIG.AC.MCB.MU

• All routines attached to Versions should have a prefix V.


Ex: V.LD.NUMERIC.MCB.MU

• All routines related to Enquiries should have a prefix E.


Ex:E.LN.POST.RESTR.TRACK.MCB.MU

• All Enquiry routines, written in Stream Serve Format should have


SSF as part of routine name
Ex:E.SSF.LOAN.DTLS.MCB.MU

• All Batch Routines should have a prefix B.


Ex: B.T24.TABLE.EXTRACT.MCBMU
B.T24.TABLE.EXTRACT.MCBMU.LOAD
B.T24.TABLE.EXTRACT.MCBMU.SELECT
I_B.T24.TABLE.EXTRACT.MCBMU.COMMON

Slide 9
File and Record Variables

Example

File Variable F.fileName F.ACCOUNT


File Name FN.Filename FN.ACCOUNT
Record Variable REC.Filename REC.ACCOUNT

Standard Field Names

Field Type Field Names to be used

ACCOUNT field ACCOUNT.NO


CUSTOMER field CUSTOMER.NO
CURRENCY field CURRENCY
Long Description DESCRIPTION

Short Description SHORT.DESC


Slide10
Some Rules

WRITE ON ERROR or DELETE ON ERROR

While using F.WRITE OR F.DELETE, avoid to use ELSE & THEN verbs,
instead make use of ON ERROR verb.

Dynamic Array Usage

Dynamic arrays must always be used with a single „<‟ & a single „>‟ character.
Any other use of dynamic arrays is illegal in jBASE.

Dimensioned array usage


Dimensioned arrays are defined as single or multi-dimensioned array. Used
with „(„ and „)‟ character.

Slide 11
Keywords Usage
All keywords used must always be coded in capital letters.
E.g.
PRINT “Welcome”

LOCATE statement

Syntax is:

For a FM Separated Value


LOCATE Y.ID IN R.RECORD<1> SETTING Y.POS ELSE
ETEXT = “NOT FOUND”
END
For a VM Separated Value
LOCATE Y.ID IN R.RECORD<1,1> SETTING Y.POS ELSE
ETEXT = “NOT FOUND”
END

For a SM Separated Value


LOCATE Y.ID IN R.RECORD<1,1,1> SETTING Y.POS ELSE
ETEXT = “NOT FOUND”
END

Slide 12
Performance Considerations
• Use the faster operators := , += etc..

• Avoid large dynamic arrays (Greater than 1000 bytes)

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

• Do not use counts in the controlling section of the loop.


E.g. FOR CNT = 1 TO DCOUNT(ARRAY,FM)
This should be in two statements
NO.ITEMS = DCOUNT(ARRAY,FM)
FOR CNT =1 TO NO.ITEMS

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

• Always try to Optimize the SELECT Statement

• Do not use EXECUTE statement, Use EB.READLIST instead.

Slide 13
Ready to use Core Routines

Slide 14
Ready to use Core Routines (Contd…)

Note: Please use the PDF “Subroutine Guide.pdf”, to know more


Slide 15
Thank You !!!

Presented By:
Prakash Parupudi

Slide 16

You might also like