Temenos T24

T24 Non Core Development Standards

___________________________________________________________________
Aaliptha [Link]
T24 Non Core Development Standards

Document Control

Document Reference: Standard Programs

Document Author: Priya Shetty (For Aaliptha)

Version History:

Version Date Section Description of Change

1.1 04 August Various New stuff added for Non core developments
2007 Temenos Americas regional development
standards added

Globus Programming Standards Date: 10 February 2026 Page 2 of 10

T24 Non Core Development Standards

Table of Contents

1 Introduction 4

1.1 Document Purpose 4

1.2 Ownership and Readership 4
1.3 Related documents 4
2 Template Programming 5

2.1.1 [Link] 5
2.1.2 [Link] 6
2.1.3 [Link] 6
2.1.4 [Link] 6
2.1.5 [Link] 6
3 Subroutines 7

3.1 SKELPROG 7
3.2 [Link] 8
3.3 [Link] 8
3.4 [Link] 9
3.5 [Link] 9
3.6 OFS 9
3.7 GUI/Desktop/Browser/STP/OFS Compatibility 10
3.8 jBASE compatibility 10

Globus Programming Standards Date: 10 February 2026 Page 3 of 10

T24 Non Core Development Standards

1 Introduction
1.1 Document Purpose
This document defines Standard Programs developed for T24. These programs are created
to assist and ease the process of NON CORE development done on-site or offsite in the
T24 programming environment. In addition, it would ensure that the locally developed
routines are written in a consistent manner implementing good programming techniques and
are in compliance with the standards, so that long-term maintenance will be as easy as
possible for the local support team.

1.2 Ownership and Readership

It is the responsibility of developers to understand, be familiar with and follow these
standards. Any of the standards programs or its execution may be challenged at any time,
but until such challenges have been made and resolved, developers should continue to
conform to the current standards.
All developments done for the Temenos Americas region should refer to the US Platform
USPL.0016.002 - R.A.D Components Reference Guide [Link] & for packaging the same
please refer to the Build Control package.

1.3 Related documents

Document name Actual Document
T24 Programming [Link]

US Platform reference guide

Build Control for packages

Globus Programming Standards Date: 10 February 2026 Page 4 of 10

T24 Non Core Development Standards

2 Template Programming

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 an associated
[Link].

In the template the Field definitions should be defined in the CALL ROUTINE & not in the DEFINE
parameters.

New template programs should contain very little code, all code should be called from the
subroutines defined in the template e.g. [Link], [Link] & CROSSVAL.

Example:
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

TEMPLATE

This is the standard template for a T24 application. In it will be calls to the other template programs
listed below,[Link], [Link], [Link], [Link] and
[Link]. Apart from the call to [Link] the other calls will be commented
out.
You should not have to change any code within this template apart from uncommenting the calls to
the other template subroutines.

2.1.1 [Link]
This is the standard template for field definitions, called from the TEMPLATE. Add the application
fields as per the technical specification. Unless specifically noted the last two fields should be
[Link] & [Link].
Remember to add a block of RESERVED fields to allow for immediate enhancements without
resorting to conversion routines.
When setting CHECKFILE use a named variable, such as [Link], which will be
defined in the INITIALISE subroutine as [Link] =
"[Link]":FM:[Link]:FM:"L", this will enable easier re-use should other
fields require the same application check.

Globus Programming Standards Date: 10 February 2026 Page 5 of 10

T24 Non Core Development Standards

This application should be named as application [Link], i.e.

[Link]. If any abbreviation is required then do not abbreviate the
application name.

2.1.2 [Link]
This is the standard template for checking field input. Any checking required over and above the
CHECKFILE settings should be performed in this subroutine. Any errors should be defined as a
record in the application [Link], do not use text.
This routine will be called after data is entered in a field and the N array contains a C as the third
element.
Care should be taken when coding the check fields, as all the checks will be repeated during the
cross validation stage. It may be necessary to check for a change in the data.

2.1.3 [Link]
This is the standard template for cross validation (F5). This routine will be called when the T24 user
commits a record. This routine will automatically re-run the check fields subroutine for every field. As
per the check fields, any error messages should be defined as a record in the application
[Link].

2.1.4 [Link]
This is the standard template for application override messages. It should be noted that accounting
override messages will automatically be generated by the accounting system and need not be coded
into the application. This also applies to Limits.
This program should consist only of application driven overrides. All override messages should be
defined as a record in the OVERRIDE application.

2.1.5 [Link]
This is a template routine to set up the data required for a call to [Link]. This routine may
require extensive modification to generate the required accounting entries.

Globus Programming Standards Date: 10 February 2026 Page 6 of 10

T24 Non Core Development Standards

3 Subroutines
3.1 SKELPROG

This program is used to generate a skeleton program and should be invoked from the jbase
prompt.

Large routines should be structured so that the first part of a routine is a series of
commented calls to internal or external subroutines. In this way it should be possible to
understand the flow of the routine by reading just call statements at the start of the routine.
This is not necessary for small discreet routines that are easy to [Link] subroutines
should have a meaningful name that describes its function.

To ease the above process, the SKELPROG program should be run which will create a
SKELETON programme structure. This Routine when run will ask for the following
information
Target Directory  [MANDATORY] should be a valid jbase directory
Subroutine name [MANDATORY] name of the subroutine to be created
Files to Open [OPTIONAL] should be type H,U,L or T type application.

SKELPROG will insert I_F (File layout) files and also opens the file pointer using OPF for
each of the specified files.

For example:

0001 SUBROUTINE SUB1

0002 *-------------------------------------------------------------------------
0003 * DEVELOPER :
0004 * DATE : 30 MAR 2005
0005 * DETAILS :
0006 *-------------------------------------------------------------------------
0007 $INSERT I_EQUATE
0008 $INSERT I_COMMON
0009 **
0010 $INSERT I_F.ACCOUNT
0011 $INSERT I_F.[Link]
0012 **
0013
0014 GOSUB INITIALISE
0015 GOSUB PROCESS
0016 RETURN
0017
0018 PROCESS:
0019 ********
0020
0021 RETURN
0022
0023 INITIALISE:
0024 ***********
0025
0026 [Link] = ''
0027 [Link] = '[Link]'

Globus Programming Standards Date: 10 February 2026 Page 7 of 10

T24 Non Core Development Standards

0028 CALL OPF([Link], [Link])

0029
0030 [Link] = ''
0031 [Link] = '[Link]'
0032 CALL OPF([Link], [Link])
0033
0034 RETURN
0035
0036 END

3.2 [Link]

This core routine must be used to get the position of the local ref field or if your doing any
development for the American region you can use the non core routine
[Link] (Part of [Link])
Eg;

CALL [Link]("CUSTOMER","[Link]",[Link])
[Link] = [Link]<[Link]><1,[Link]>

3.3 [Link]

Prefix – LP
Type: FIN
Module: EB (Core)
Pgm type :H

A parameter file [Link] has been created to store the values necessary for the
business process which is not stored in any Application.
During the implementation of GLOBUS, it is a common practise to develop a number of
client specific local programs, based on their specific business requirements. This leads to
hard coding of certain values within the programs (e.g. for certain category ranges,
departments, etc). In order to reduce hard coding of the values and allow flexibility, the
[Link] file can be set up in GLOBUS (naming to be specific to the client e.g.
[Link] for HFC Bank, or [Link] for Bank, Al Bilad) and values to
be hard coded can be stored in this parameter file. The same can then be referred in the
local program. This process is designed to eliminate the hard coding of values in
subroutines.
A call routine [Link] should be called from the subroutine to get the value
stored in the parameter file.

Field Field Name Type Description

No
0 [Link] 35,A The id for the parameter record.
1 [Link] 35.3, A Description
Mandatory
2 XX<[Link] 35, A Should be a valid application to be used as a
look up table. The application screen title is
displayed as an enrichment.
The fields from [Link] to VALUE.2 are a

Globus Programming Standards Date: 10 February 2026 Page 8 of 10

T24 Non Core Development Standards

set of associated multi-value fields

3 [Link] 3, A The field of the corresponding [Link]
application to be used as enrichment for
associated fields VALUE.1 and VALUE.2.
The field name is displayed as enrichment for the
field.
The [Link] field is mandatory only if
[Link] field is not NULL
4 XX-ATTRIBUTE 35, A Attribute name (or label name) for the associated
Mandatory field VALUE.1 and VALUE.2
5 XX-XX<VALUE.1 35, A The allowable value for the field. This field along
Mandatory with VALUE.2 is further sub-valued together so
as to allow multiple values of a list or starting
range for the range of values.
6 XX>XX>VALUE.2 35, A The ending range for the range of values.
16 RESERVED 13*35,A Reserved for future use.

3.4 [Link]

A parameter file [Link] has been created to store the values necessary for the
business process and with the intention of reducing hard coding of values in the local
programs. The call routine [Link] (naming to be specific to the client e.g.
[Link] for HFC Bank, or [Link] for Bank, Al Bilad) is then
used in the program to retrieve the values from the parameter file.

The routine accepts four arguments as follows:

([Link], [Link], [Link], [Link])

Incoming:

[Link]: Record id to the Table [Link]

[Link]: Keyword “[Link]” – to return the entire record
OR A specific label (attribute) to return Start and End Values for that label

Returned:
[Link]: Start values returned for a specific label Or Complete record returned
[Link]: End Values returned

3.5 [Link]
 Don’t use [Link] in VERSION Routines

 Don’t use [Link] from within a local template application except when required
and that must be only in the [Link] stage (for 1 auth) and
[Link] stage

Globus Programming Standards Date: 10 February 2026 Page 9 of 10

T24 Non Core Development Standards

3.6 OFS

 Don’t use [Link] from Version routines. Please use the

[Link] & [Link]

 Don’t use [Link] from local Template applications except when required
& that must be only in [Link] or [Link] stages.

 Do not use a coma version in OFS, all versions that are used in the OFS message should
have a version name followed by the coma

 Do not hardcode the Version name & the [Link] in the routines where
[Link] or OFS .[Link] is used. Use a parameter table to define
the version name & OFS source

 While Building [Link], DO NOT include [Link] &

[Link] record, these two must always be setup manually (except when
building a Master environment within the same client)

 When calling [Link] from version routines, ensure that [Link](V-10) is saved
before calling [Link] and after return from [Link], copy the value of
[Link](V-10) to a local ref and restore the saved value of [Link](V-10) – this is to make
sure that the [Link] of the core entries are not lost.

3.7 GUI/Desktop/Browser/STP/OFS Compatibility

OFS and Browser are completely stateless, any ‘conversation’ will stop them working. Direct
input through TXTINP or REM should not be used.
You must use the routines [Link] and [Link] otherwise your code will not
work with the T24 Graphical User Interface. Commands such as INPUT, PRINT and CRT must never
be used in a routine / program.
PRINT and CRT statements will simply display nothing in the GUI, whilst the INPUT statement will
have severe implications and may cause the session to hang and/or terminate abnormally.
You should never use the [Link] (used as a keyboard type ahead) variable for defaulting
data or navigation commands e.g. moving to a new field, expanding a multi-value etc.
[Link] cannot be interpreted by the GUI. Use the standard mechanisms of [Link],
[Link] and [Link] to refresh the screen, although the latter should be used
sparingly as it means that all field definitions and all data are resent to the GUI.
There are ‘standard’ methods for determining whether an application or subroutine is running in any
specified environment:
For OFS the common variable GTSACTIVE will be set.
For GUI the common variable TTYPE will contain the text GUI.
For Browser the common variable GTSACTIVE will be set.

3.8 jBASE compatibility

In order to keep T24 compatible with the jBASE platform there are certain restrictions that will apply to
code development within T24. These have been listed in the attached T24 programming standards:

Globus Programming Standards Date: 10 February 2026 Page 10 of

10