Programming Standards – T24

Day 1 - Session 1-4

Administration
Dates
MM/DD/YYYY Technical Courses
Venue
xxxx
Objectives
 Objective:

 At the end of this session participants will know:

• Basic Rules and Standards
• Templates to be used
• Naming convention
• Commands to be used
• Commands not to be used

3 Thesys Training Centre

3
 Introduction

 Defines standards that must be followed when writing

program to operate in T24 environment.
 Defines rules that are designed to make the code legible,
maintainable and operational within both T24 and T24
graphical user environments.
 The structure of T24 is designed around the use of business
objects, so rules have to be strictly adhered to the code to
make it operate correctly even if functionality of object is
increased.
 The standards allow other people to support and maintain
the program.
4 Thesys Training Centre

4
 Why coding conventions?

 To standardize the structure and coding style of T24

applications, so that others can easily read and understand
the code.
 Good coding convention:
• Results in precise, readable and unambiguous source code that
is consistent with other language conventions.
• Allowsprogrammer to freely create programs logic and
functional flow, by defining minimum requirement to accomplish
purpose.
• Makes program easy to read and understand, without cramping
natural creativity and arbitrary restriction.
5
• Standardizes the program that do not comply with standard
Thesys Training Centre

5
 Program structure:

 Template programs should be < 2000 lines

 All code should be called from subroutines defined in
template e.g. FIELD.DEFINITIONS, CHECK.FIELDS &
CROSSVAL.
 Subroutines should be < 600 lines. Code should contain
internal subroutines so that it can be viewed in one screen.
 Do Not write TOP DOWN code.
 Do Not Assume field 1 will be input before field 2,
Remember client Versions.
 All code should be structured in modular fashion and broken
6 into small units/paragraphs i.e. < 100 lines containing
Thesys single
Training Centre

6
 Program structure:

 Avoid deeply nested IF and large case constructs.

 Labels and variables should have meaningful name and
should not use the same names.
 Do not use multi-statement lines:
• E.g. FOR X = 1 TO 10; G.TOTAL += S.TOTAL<1,X> ; NEXT X.
 Do Not use STOP, ABORT or RETURN TO.
 Do Not Use GOTO unless it is to exit a unit.
 Fields must be referenced with the corresponding field name
supplied in standard inserts.

7 Thesys Training Centre

7
 Program structure:

 Avoid FOR..NEXT loop, use LOOP..REMOVE syntax.

 Do Not cut and paste code, use internal
subroutine/paragraph for code.
 Rewrite the section to avoid duplication, when enhancing
older programs.
 Do not pass common variables as arguments to subroutines
e.g. ETEXT should only be used as the error value returned
from F.READ. The use of common variables in this way can
lead to unexpected errors.

8 Thesys Training Centre

8
 Program structure:
 When calling API interfaces or user defined subroutines, Do Not
Use the program as the flag as this is replaced by a direct memory
address for the routine once it is called.
E.g. IF USER.ROUTINE THEN
CALL @USER.ROUTINE
END
The above code will fail if executed second time, as
USER.ROUTINE will be memory address not a string.
 Additionally the API should be checked to ensure that the call will
not fail, using the standard routine CHECK.ROUTINE.EXIST.
 This check should be performed once only as the check takes
some time to execute, especially in jBASE.
9 Thesys Training Centre

9
 Comments in Programs:

 Do Not comment the existing code. If the code is not

required delete it.
 Don’t use asterisks (*) to create coding breaks, use “*-----” to
break up the section or use blank lines to make the code
more readable.
 Every internal subroutine/paragraph must begin with
comments explaining the purpose of that section of code.
Again this should include a description of the supplied and
returned values that are the same as the main routine.
 All the called arguments and common variables should be
documented in the routine.
10 Thesys Training Centre

10
 Naming convention:

 Use I_RULES in T24.BP for the common variable used in

T24.
 Refer User Guide -> Technical -> Programming standard for
the structure of routines.

11 Thesys Training Centre

11
 Constants and Variables:
 Global Variables
• Defined in I_COMMON
• Inserted in every T24 programs
• Prefixed with C$ e.g. C$EB.PHANTOM.ID
 Product level Variables
• Defined in product level common block e.g. I_RP.COMMON
• Inserted in all subroutines
• Prefixed with XX$ e.g. RP$ for repo
 Subroutine level Variables
• Defined only in subroutine in which it is to be used
• Can be passed to another subroutine as argument in CALL
12 Thesys Training Centre

statement 12
 Subroutine name and variables:

 Should be in Upper Case.

 Should define its purpose.
 Should have maximum 35 characters.
 Should be prefixed with product name e.g.
RP.CHECK.FIELDS.
 Use abbreviation if subroutine name exceeds 35 characters
e.g. use XX.application.FIELDS.DEFS
 Do Not Use numeric label.
 Do Not Use $ and underscore (_).
 Do No Use extension of B or other extensions interpreted by
13 Thesys Training Centre

system e.g. windows extension. 13

 Standard Variables and Abbreviations:

 Naming of Files and Records should be as follows:

• File Variable -> F.filename e.g. F.ACCOUNT
• File name -> FN.filename e.g. FN.ACCOUNT
• Record variable -> R.filename e.g. R.ACCOUNT

 Filename variables should only be used when required,

normally a constant should be used e.g. CALL
OPF(‘F.ACCOUNT’,F.ACCOUNT).
 Use consistent abbreviations throughout the application.

14 Thesys Training Centre

14
 Field names and numbers:

 Don’t reference field by field number, except in conversion

subroutines.
 Use field name as specified in standard inserts.
 Standard field name for corresponding fields are as follows:
 ACCOUNT – ACCOUNT.NO
 CUSTOMER – CUSTOMER.NO
 CURRENCY – CURRENCY
 Long Description – DESCRIPTION
 Short Description – SHORT.DESC

15 Thesys Training Centre

15
 Commons and Inserts:

 All routines must have I_COMMON and I_EQUATE inserted

at the start of program.
 All common blocks must be specified in insert, where the
inserts are maintained easily.
 All common variables should be prefixed by C$, so as to be
readily identified in the routine.
 File name must be stored in their own insert as created by
FILE.LAYOUT.
 Code must not be written in inserts. Use Called Subroutines.

16 Thesys Training Centre

16
 Commons and Inserts:

 Add reserved variables to common block, so as to avoid

mismatches when adding new variables.
 All common blocks must be ‘named’ commons.
 If any local development uses the insert files residing in
PATCH.BP directory, then copy them from PATCH.BP to
T24.BP directory and recompile any associated programs.

17 Thesys Training Centre

17
 Standard subroutine:

18 Thesys Training Centre

18
 GUI/Desktop/Browser/STP/OFS
Compatibility:
 GUI is a standard client server architecture that relies on
structured message for its communication, hence it cannot
respond to direct ‘screen’ input and output commands.
 Dont’s:
• Direct
input through TXTINP or REM should not be used, as
OFS and browser are completely stateless.
• Donot use INPUT, PRINT and CRT commands in
routine/program, as PRINT and CRT will not display anything in
GUI, whereas INPUT will have severe implications and causes
session to hang and terminate abnormally.
• Neveruse INPUT.BUFFER variable for defaulting data or
19 navigation commands. Thesys Training Centre

19
 GUI/Desktop/Browser/STP/OFS
Compatibility:
 Do:
• Use DISPLAY.MESSAGE and UPDATE.HEADER routines, else
code wont work with T24 graphical user interface.
• Usestandard mechanisms of T.SEQU, REFRESH.FIELD and
REBUILD.SCREEN to refresh the screen.
• STP uses OFS to generate transaction without user
intervention.
 The ‘standard’ methods for determining whether an
application or subroutine is running in any specified
environment:
• For OFS the common variable GTSACTIVE will be set.
20 Thesys Training Centre
• For GUI the common variable TTYPE will contain20
the text GUI.
 GUI/Desktop/Browser/STP/OFS
Compatibility:
 If an application is to execute any code specific to OFS, then the relevant
call is made if GTSACTIVE is set as follows:
IF GTSACTIVE THEN
*Do OFS specific processing
END
 Functionality only applicable to the GUI interface is executed as follows:
IF INDEX(TTYPE,”GUI”,1) THEN
* do GUI functions
END
 Browser is identified as follows:
IF OFS$SOURCE.REC<OFS.SRC.SOURCE.TYPE> = 'SESSION' THEN
* do Browser functions
END

21 Thesys Training Centre

21
jBASE compatibility issues:

 Restrictions applied to code development within T24 are

described below:
• The keywords and functions are restricted to be used as variables.
 Refer User Guide -> Technical -> Programming standard for
detailed list of keywords which should not be used as variables.

22 Thesys Training Centre

22
 Function and Display:

 These keywords are in I_COMMON and in every

TEMPLATE program.
 They have been changed to be V$FUNCTION and
V$DISPLAY both in common and in all the code.

23 Thesys Training Centre

23
Ambiguous THEN & ELSE Statements:

Compilers can treat ambiguous statements differently, for example:

IF condition THEN READ record FROM F.FILE, ID THEN ID.OK = 1
END ELSE
* Do something else
END

The above code is wrong as ELSE is common to READ and IF, hence the right
code will be:
IF condition THEN
READ record FROM F.FILE, ID THEN
ID.OK = 1
END
END ELSE
* Do something else
END

24 Thesys Training Centre

24
 CHAR, CHARS, SEQ and SEQS:

 These functions are supported only in jBASE, and they are

incompatible in EBCDIC environment, hence they are
replaced by T24 functions through CHARX(), CHARSX(),
SEQX() and SEQSX().
 C$CHARX() is a dimensioned array, populated in
OVERLAY.EX, which will ALWAYS return the ASCII character
of the number requested. If running in an EBCDIC
environment the EBCDIC characters will be re-ordered in
C$CHARX(), hence CHARX(10) will always be a linefeed.
 CHARX() is a function, defined in I_COMMON, that will
return the character at the position requested from the
Thesys Training Centre
C$CHARX() array. Hence CHARX() will always use the
25

25
 CHAR, CHARS, SEQ and SEQS:

 CHARSX() is similarly a function defined in I_COMMON that

works off a list as opposed to a single value.
 SEQX() is a function, defined in I_COMMON that will return
the index position in C$CHARX() of the character supplied.
Hence SEQX() will always give you the ASCII code for a
character, even when running in an EBCDIC environment.
 SEQSX() is a function defined in I_COMMON that works off
a list as opposed to a single value.

26 Thesys Training Centre

26
 SUBROUTINE<name>:

 When coding a subroutine it must be ensured that the

<name> portion code is identical to the source code name.
 jBASE compiles programs to executables and libraries. The
executables and libraries are stored in lib and bin
respectively with the name as used in the routine
SUBROUTINE <name> or PROGRAM <name>.
For example, if the program is called as E.GET.ACC.DET,
but in the program it is declared as :
SUBROUTINE E.GET.ACC.DET.TEST.
The routine will be catalogued as E.GET.ACC.DET.TEST
27 and not as E.GET.ACC.DET. Hence the routine willThesys
beTraining
notCentre
27
 CHOICE BETWEEN ‘PROGRAM’ AND
‘SUBROUTINE’:
 Most programs in T24 must be coded to be ‘SUBROUTINE’.
 In case it is required to call a program from the
UniVerse/jBASE prompt or call the program using an
EXECUTE statement, then program must be coded as a
‘PROGRAM’.
 In case the program has been coded as ‘PROGRAM’ the
statement used to exit the program must be coded as
‘STOP’ and not ‘RETURN’, since ‘RETURN’ is associated
with a ‘SUBROUTINE’ in jBASE.

28 Thesys Training Centre

28
 WRITE.ON.ERROR or
DELETE.ON.ERROR
 These commands should be used when bypass of T24
subroutines is required to perform delete (F.DELETE) &
write (F.WRITE).
 The syntax in these statements must avoid the ELSE &
THEN verbs.

29 Thesys Training Centre

29
 DYNAMIC ARRAY USAGE:

 The dynamic array must always be used with single ‘<‘ and
single ‘>’ symbol.
 The dynamic array is inefficient to store data, when the
number of multi-value becomes large

30 Thesys Training Centre

30
 DIMENSIONED ARRAY USAGE:

 They are defined as single or multi-dimensioned array.

 It should be used in the same way as it is dimensioned.
 Do not use multi-dimensioned array as a single dimensioned
or vice versa.
E.g. for Single dimensioned array:
IF R.NEW(AC.SUS.CURRENCY) = "" THEN …
E.g. for Multi-dimensioned:
R.NEW(AC.SUS.CR2.TAX.AMT,1) = YTAX.AMT

31 Thesys Training Centre

31
 KEYWORD USAGE:

 All keywords must always be coded in capital letters.

E.g. print “Hi” – invalid
PRINT “Hi” – valid

32 Thesys Training Centre

32
 EQU LIT Usage:

The use of EQU LIT can become ambiguous.

EQU VM TO @VM
EQU A.VAR LIT ‘CUST’:VM:’ACCOUNT’
The second line of code is ambiguous and the pre-compiler in
jBASE will not convert the VM to @VM thereby giving
unexpected results. The code should be re-written as:
EQU VM TO @VM
EQU A.VAR ‘CUST’:VM:’ACCOUNT’

33 Thesys Training Centre

33
 EQU Usage:

jBASE will allow the EQU statement to be used more than once
for the same variable. E.g.
EQU VAR1 TO ‘abc’
EQU VAR1 TO ‘def’
Therefore, care must be taken to ensure that such mistakes are
not made, as the jBASE compiler will not report these errors.

34 Thesys Training Centre

34
 Warnings in Jbase:

 UniVerse does not give warnings when a dimensioned

variable is defined but not used, but jBASE gives a warning
when the dimensioned variable is defined but not used.
E.g.
DIM ABC(100)
DEF = 10
PRINT DEF
END

Note: The setting of the environment variable

35
JBASE_WARNLEVEL in jBASE suppresses the appearance
Thesys Training Centre

35
 UV Special Routines:

 UV routines beginning with ‘!’ is not supported in Jbase.

 !HUSHIT(), !SLEEP$() are supported in Jbase as they are
commonly used, but they are replaced by HUSH ON/OFF
and SLEEP.

36 Thesys Training Centre

36
 LOCATE Statement:

 LOCATE() will not work in jBASE, use LOCATE statement.

E.g. The following will not work in UniVerse and jBASE.
LOCATE COMI IN
YR.LOCTAB<EB.LTA.VETTING.TABLE,1> SETTING
YLOC.LOOP
ELSE ETEXT = "NOT DEFINED IN TABLE" ; RETURN
The correct Syntax is
LOCATE COMI IN
YR.LOCTAB<EB.LTA.VETTING.TABLE,1> SETTING
YLOC.LOOP ELSE
37
ETEXT = "NOT DEFINED IN TABLE" Thesys Training Centre

37
 ON GOSUB/ON GOTO:

 E.g.
FOR X = -1 TO 6
ON X GOSUB A,B,C,D
NEXT X
The above code will result in error in jBASE at two conditions,
when x < 1 and when x > 4.
Whereas the above code will run in UniVerse.

38 Thesys Training Centre

38
 TOOLBARS IN BROWSER:

 Toolbar is created using two tables:

• BROWSER.TOOLS
» Defines button to be used in any toolbar.
» Each button is described by a number of fields in table.
• BROWSER.TOOLBAR
» Defines toolbar as a grouping of individual buttons
» Each toolbar is made of multi-value of tools.

 Several subroutines should be called to build the toolbar.

39 Thesys Training Centre

39
 API for Building Toolbar in application:

 The following API’s are required for building the toolbar in

applications:

• EB.ADD.TOOLBAR (TOOLBAR.ID, TOOLBAR.LOCATION)

• EB.ADD.TOOL (TOOLBAR.ID, TOOL.ID)
• EB.CHANGE.TOOL (TOOLBAR, TOOL, FIELD, NEW.VALUE)

40 Thesys Training Centre

40
 EB.ADD.TOOLBAR(TOOLBAR.ID,TOOL
BAR.LOCATION) :
 This routine is passed the key to record on
BROWSER.TOOLBAR table.
 Loads toolbar into memory.
 1st parameter -> TOOLBAR.ID sets text for toolbar or
override the text from BROWSER.TOOLBAR file.
 2nd parameter -> TOOLBAR.LOCATION sets location at
which tool will be displayed.
• If
value is HEADER –> displays toolbar at the top of contract
below the main function toolbar.
• Ifvalue is CONTEXT.TOOLBAR -> displays toolbar upon
commit.
41 Thesys Training Centre

41
 EB.ADD.TOOL(TOOLBAR.ID,TOOL.ID):

 This routine is passed:

– The key of toolbar that is already in memory and
– The key of record on BROWSER.TOOLS table that is to be
added to the toolbar in memory.
 Adding a tool to toolbar in memory will not amend the record
on BROWSER.TOOLBAR file.
 A BROWSER.TOOLBAR record is manually built and
passed in the place of TOOLBAR.ID, instead of passing the
key to a tool.

42 Thesys Training Centre

42
 EB.CHANGE.TOOL (TOOLBAR, TOOL,
FIELD, NEW.VALUE)
 This routine is passed:
• The key of a toolbar that is already in memory and
• The key of a tool that is currently on the toolbar in memory.
• It is also passed a field number and a new value to set that field.
 Equates in BROWSER.TOOLS e.g. BRTL.TEXT or
BRTL.ENABLED insert should be used for the field number.
 If toolbar is not in memory, or if the tool is not on toolbar that
is in memory, then the routine will pass no value.

43 Thesys Training Centre

43
 Handling Context Workflow:

 When trying to run a new task in T24 or when giving the user
a new option of new task to run based on current context,
two functions should be called. They are:
• EB.SET.NEXT.TASK(NEXT.TASK)

• EB.CREATE.CONTEXT.WORKFLOW(DISPLAY.TEXT,INPUT.O

PTIONS,OPTION.COMMANDS)

44 Thesys Training Centre

44
 EB.SET.NEXT.TASK(NEXT.TASK):

 This sets the value of next task to be run.

 NEXT.TASK should be passed in the command line
e.g. ACCOUNT I DBL.
 This should be set after commit.

45 Thesys Training Centre

45
 EB.CREATE.CONTEXT.WORKFLOW(DI
SPLAY.TEXT,INPUT.OPTIONS,OPTION.
COMMANDS):
 This subroutine is passed the options to be given to the user,
when committing deal, and then action is run depending on
choice.
 The steps for input are:
• Display for options is set in DISPLAY.TEXT.
• Captions for different options should be set in a dynamic array
delimited by field markers in INPUT.OPTIONS parameter.
• The corresponding action to run should be in a correlating
dynamic array in OPTIONS.COMMANDS.
• Format of command should be from command line.
• Key to toolbar can be passed in the first parameter, when
46 Thesys Training Centre
running in browser. 46
 Close Of Business Routines:

 Batch Records:
• All
new batch records should have an equivalent record in
BATCH.NEW.COMPANY application.
 Code Requirements:
• All
new batch processes should be written to use multi-
threading.
• CloseOf Business routines must be structured using “close of
business routines” section in “development guide”.
• A flag
RUNNING.UNDER.BATCH should be tested, when a
routine requires to know that it has been called during COB
procedure.
47
• Do Not test the SPF status, as it will be set when the COB is
Thesys Training Centre

47
 Code Requirements:

 Do Not call template program from the batch. Isolate the

functionality required in the subroutine and call the
subroutine from Close of Business and template program.
 Do Not prompt during the Close of Business. Use CRT
statement to record progress of job.
 Do Not use HUSH, or !HUSHIT, the output from the
‘commands’ is useful when analyzing the COB failure.
 Always use FATAL.ERROR to terminate batch job when
error condition occurs. Never use STOP.
 The FATAL.ERROR should be called with proper TEXT, such
that error logged in EB.EOD.ERROR is helpful for further
analysis.
 End of day reports have to be attached to EB.PRINT either
as routine or repgens or enquiries.
48 Thesys Training Centre

48
 Summary of Standard Multi – Thread
process
 It is mandatory to write multi-threaded batch jobs, so that
there is minimal impact on the performance, and the usage
of processing capabilities of hardware is optimal.
 Multi-threading of routines is mandatory to ensure that
transaction management is provided by the system.

49 Thesys Training Centre

49
 Summary of Standard Multi – Thread
process
 Main Process:
• Name : xxxx(list_record_id)
where
• xxxx is a name defined in PGM.FILE and used in BATCH record.
• list_record_id is key extracted from last record which is keyed in
sequence.
• The field BATCH.JOB in PGM.FILE for standard multi-thread
process should be @BATCH.JOB.CONTROL. If the field is left null,
then the system defaults it to @BATCH.JOB.CONTROL.
• The above routine should process single piece of transaction of
job, thus ensuring better split between different agents.
• It is invoked by system with transaction management wrapped
around it.
• It should not perform heavy load and should avoid select/clearfiles.

50 Thesys Training Centre

50
 Summary of Standard Multi – Thread
process
 List file
• Name : xxxx.LIST
– This mandatory file is used to drive the multi-threaded processing.
– The records in this file are built by the SELECT routine

 Load process
• Name : xxxx.LOAD
– This mandatory process is required to set up common area used by
the main process.
– A local common is created for each main process.
– This routine is invoked once per agent.
– It should avoid any locks and any writes to database.
51 Thesys Training Centre

51
 Summary of Standard Multi – Thread
process
 Select process
• Name : xxxx.SELECT
– It is a mandatory process to build LIST file that will be handled by
main process.
– It is called after LOAD routine.
– List file is built by calling
BATCH.BUILD.LIST(ListParameters,IdList)
– List file is allocated based on availability of pool.
– This routine is invoked per job.
– The CONTROL.LIST common variable is populated and system
invokes SELECT routine for n number of times, based on the
requirement for performing different operations in sequence with
every operation having ability to run in parallel.
– Thus ensuring that every stage of job has parallel processing.

52 Thesys Training Centre

52
 BATCH.BUILD.LIST(ListParameters,IdList
)
 ListParameters<1> - It is name of list file
 ListParameters<2> - Extracts file name. It is file holding Ids.
 ListParameters<3> - Extracts selection. It is a list of
selection criteria to be supplied to select and build from
extract file. This command supplies SELECT or SSELECT
when ordering is important.
 ListParameter<4> - It is no. of record Ids written to work list
record. The value is increased to reduce overhead of
building work file.
 IdList – It is a list of Ids prepared by SELECT program to
53
build the list file. Thesys Training Centre

53
 Summary of Standard Multi – Thread
process
 Post process
• Name : XXXX.POST
– It is an optional process for handling processing required after list
file and all multi-threading is over.
– This process is defined in BATCH.

54 Thesys Training Centre

54
 Template Programs:

 Every file created must have an associated template

program.
 Use the correct template program for the file type.
 Never modify the template control code.
 The basic minimum for a new application will be the
application and associated FIELD.DEFINITIONS.

55 Thesys Training Centre

55
 PERFORMANCE CONSIDERATION:

 Use the faster operators “:=“ “+=“ etc. e.g. TOTAL.VAL +=

SUB.TOTAL instead of TOTAL.VAL = TOTAL.VAL +
SUB.TOTAL.
 Avoid large dynamic arrays (greater than 1000 bytes).
 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.
 Construct case statements so that the most often used
condition is at the top.
 Do Not perform Counts in controlling sections of a loop.
• E.g. Use NO.ITEMS = DCOUNT(array,FM)
FOR CNT = 1 to NO.ITEMS
instead of FOR CNT = 1 to DCOUNT(array, FM)
56 Thesys Training Centre

56
 PERFORMANCE CONSIDERATION:

 Do Not Use DBR to read single field from a record, as DBR

reads the entire record. Its better to read the whole record
for ensuring easier enhancement.
 Ensure new files created has a sensible modulo. Do Not
release new file control records with a modulo of 3 or 9731.
The size of projected record on database has to be with
reasonable volume.

57 Thesys Training Centre

57
 PERFORMANCE CONSIDERATION:

 Ensure that the operations are not needlessly repeated

within a loop, e.g avoid re-reading the same parameter
record every time a record is executed.
 Do Not select files e.g STMT.ENTRY that are likely to grow
in an installation. Use concat files or alternate method for
finding the required record.

58 Thesys Training Centre

58
 PERFORMANCE CONSIDERATION:

 Take care in the usage of concat files. A poorly designed

concat file results in performance overhead when updated,
due to the large record size created and system locks if the
key is a poor choice. E.g. the concat file LMM.CURRENCY
is a poor file since the key is likely to be common with the
majority of contracts.
 Do not re-invent the wheel. Use standard system routines
and functions where available, these will have been
optimized for performance.

59 Thesys Training Centre

59
 PERFORMANCE CONSIDERATION:

 Avoid unnecessary select statements. If a record key can be

obtained using direct access, a select is an unnecessary
overhead.
 Use SUM, etc. to add all multi-values in a field together. Do
not use a loop to process each multi-value separately.

60 Thesys Training Centre

60
 EB.COMPILE – ONSITE
DEVELOPMENT
 In G12.2.00, EB.COMPILE has been amended for jBASE
users, to automatically set JBCDEV_BIN and JBCDEV_LIB
when cataloging programs. The following rules are applied:
• If JBCDEV_BIN/LIB is currently set to globusbin/lib (the default):

– When compiling from BP or GLOBUS.BP,

globusbin/lib will be updated.
– When compiling from any other BP, bin/lib will
be updated.
• If JBCDEV_BIN/LIB is set to anything other than globusbin/lib:

– When compiling from BP or GLOBUS.BP,

61
globusbin/lib will be updated. 61
Thesys Training Centre
 EB.COMPILE – ONSITE
DEVELOPMENT:
 Therefore, GLOBUS.BP and BP should only be used for T24
core programs by Temenos.
 BP should not be used for any on-site developed software,
as globusbin and globuslib are overwritten by the T24
upgrade process. Therefore adopt specific naming
convention for the program directories, e.g. TEST.BP, or
ABC.BANK.BP.
 EB.COMPILE should ALWAYS be used to compile T24
programs, it has been adapted to copy $INSERT records to
the source file and perform some rudimentary checks on the
code.
62 Thesys Training Centre

62
 ERROR MESSAGE HANDLING:

 EB.ERROR
• This table defines the T24 error messages
• Field Definitions:
– FIELD: KEY (Product code-Abbreviated Description) – Record key
– Maximum 35 alphanumeric characters.
– The key to the record is used to identify the required error
message. This field consists of 2 parts:
» PRODUCT code e.g. OF
» An abbreviated description of error message. E.g. “Mandatory
for IB user”, that is produced by OFS.SOURCE application.

63 Thesys Training Centre

63
 ERROR MESSAGE HANDLING:

 FIELD: ERROR.MESSAGE - Error message text - Maximum

50 characters. Alpha, numeric and symbol input accepted.
• This multi-language field contains the message that will be
displayed in the event of an application triggering this error.
• On selecting and validating a second multi-language field, a
mirror record for the multi-language text will be created in
DYNAMIC.TEXT with this field as the key.
Note: When multi-valuing language fields, the fields appear in a pre-set
order, so in order to use a set language it is required to have the
languages preceding it multi-valued.

64 Thesys Training Centre

64
 ERROR MESSAGE HANDLING:

 FIELD: ERROR.INFO - Error message definition – Maximum

50 characters long. Can accept alpha, numeric and symbol
data.
• This multi-language field is only visible in the Browser and has
no presence in Classic.
• It contains an explanation of the error in detail.
Note: When Multi-valuing language fields, the fields appear in a pre-set order,
so in order to use a set language the language fields preceding it must be
multi-valued.

65 Thesys Training Centre

65
 ERROR MESSAGE HANDLING:

 FIELD: ERROR.SOL – Error Solution – Maximum 50

characters long. Can accept alpha, numeric and symbol
data.
• Thismulti-language field contains solutions to the error
message.
• This field is only visible in Globus Browser and has no presence
in Classic.
Note: When Multi-valuing language fields, the fields appear in a pre-set order,
so in order to use a set language the language fields preceding it must be
multi-valued.

66 Thesys Training Centre

66
 ERROR MESSAGE HANDLING:

 FIELD: ALT.ERROR.CD – Alternative Error Code –

Maximum 35 characters long. Can accept Alphanumeric
input.
• This field has been created to:
– Stop duplication of same error messages in the same application.
– Stop duplication of same error message in different applications.
– Reduce maintenance of duplicated error messages in one, or more
applications. Only the “Alternative” Error record has to be updated.
The ALT.ERROR.CD field acts as a link.

67 Thesys Training Centre

67
 ERROR MESSAGE HANDLING:

 New items is created in DIM.NEW.ITEMS

 New EB.ERROR record is populated and attached to CD.
 Description is extracted and displayed in enrichment section,
on entry of valid error code.
 The 2 fields to be filled when linking error record to
alternative error record, are field and RECORD.ID.
 Message, information and solution fields is extracted from
alternative error record, when error record is referenced by
T24.
 Only RECORD.ID of original record is reported, and error
68 message, error information and error solution fieldsThesys
areTraining
not Centre

68
 TRIGGERING AN ERROR MESSAGE:

 The subroutine called ERR is invoked to present the message

to the user.
 The following needs to be followed to present the message:
• Set the element of COMMON variable E to:

1. Error code
2. Data to replace & in element 1.
3. Name of program/subroutine.
4. Developers comment.
5. XX.LL.ERROR.INFO – Error message definition.

69
6. XX.LL.ERROR.SOL – Error message solution. Thesys Training Centre

69
 TRIGGERING AN ERROR MESSAGE:

• Set
common variables AF, AV and AS with field, multi-value and
sub-value positions.
• Make CALL to ERR. Where ERR will establish if the user is
working in Globus Browser or Classic.

70 Thesys Training Centre

70
 Minimum Testing Requirements:

 A minimum number of tests have to be carried out always.

E.g. If a new field is added to an application or the check
field or cross validation is changed, then test is to enter new
transaction and press F5.
Or if a change is made to batch process, then a full batch
run has to be done.

71 Thesys Training Centre

71
 jBASE testing:

 It is mandatory to set environmental variable

JBASE_WARNLEVEL to 4, before running a test in jBASE,
so as to ensure that errors are displayed.
 Other setting of the above environmental variable will
suppress the error message.

72 Thesys Training Centre

72
 Code Coverage:

 A minimum number of transaction is set by the test in the

code, when a test is written to either process or ignore a
transaction based on a set of criteria.
 It is mandatory to enter 2 transactions to ensure code
coverage, where one should pass the test, while the other
should fail the test.
 When there are many test criteria, the number of transaction
required to ensure code coverage will multiply.

73 Thesys Training Centre

73
•
All product names and other company names used herein are for identification
purposes only and may be trademarks or registered trademarks of their respective owners. Errors and
omissions excepted,
all specifications are subject to change without notice.

•
© 2009 Thesys Technologies Incorporated. All rights reserved.

FOR MORE INFORMATION

Visit : www.thesys.co.in
email : marketing@thesys.co.in