Infobasic Programming and T-24 Standard

 Introduction
 Structure of Infobasic Program
 Control Structure of Infobasic
 Built in Infobasic functions
 Infobasic Commands
 Writing subroutine in Infobasic
 Practice session
 Assignment

Versions and Version Routines

 Basic concepts of Versions

 Important fields of Version
 Version Designer
 Version Control
 Practice session
 Assignment

Usefull Routines in Version

 The need of version routine
 Varios types of version routines
 Execution of version routines
 Common Variable
 Practice session
 Assignment

I_COMMON and I_EQUATE are two main insert files available in Globus.
I_COMMON defines all common global variables that can be used across subroutines and the file
I_EQUATE initializes those common variables

(It is a good practice to include these files in every subroutine we write irrespective of whether we are to use common global
variables or not. These insert files are available under the directory GLOBUS.BP.)
common variables are accessible as long as you include “$INSERT I_COMMON” in your programs.

Example of common variable:

ID.COMPANY
Branch Id

ID.NEW
FT Id

PGM.FILE

This file is an inventory of all T24 programs

(whenever an application or batch job is selected, the PGM.FILE table is read to firstly see if the program or process
exists, and secondly to see what its characteristics are. If there is no entry on the PGM.FILE table then it cannot be
executed from within the T24 environment.)

This table can also hold the names of all subroutines within T24

Inorder to open the Customer file we can use the Infobasic command OPEN.
OPEN FBNK.CUSTOMER ………………….
When we use the UniVerse command OPEN to open a file, we need to supply the
exact file name(along with the prefix). If programs are written using OPEN statements , they do not
become portable across branches of a bank as each branch will have a different mnemonic to indentify
itself uniquely.
For Instance
Bank XYX
In Branch1
In a subroutine we open the customer file by using UniVerse OPEN statement
OPEN FBR1.CUSTOMER
In Branch2
If the above subroutine with the OPEN statement were to be executed in this branch,
the subroutine would return a fatal error saying that it cannot open the file. The name
of the customer file in this branch is FBR2.CUSTOMER.
Inorder to overcome this problem or program portability, we need to use the core
Globus subroutine OPF instead of Open.
When the OPF subroutine gets executed, the COMPANY file is read inorder to obtain
the mnemonic of the bank. Then the FILE.CONTROL record of the file is read to find out the type of
file(INT,CUS or FIN). Once the file type is extracted, the ‘F.’ in the file name gets replaced with
“FBankMnemonic” - FBNK thus making subroutines portable across branches.
 OPF Description: File open routine. Handles company modification
of file name hence it must be called for all file
opens.
Arguments: (FILE.NAME, FILE.VAR)
Incoming:
FILE.NAME Name of the file to be opened, this should not
include any mnemonic as this will be determined
by the program itself allowing for the file
classification and multi-company or multi-book
setup e.g F.CUSTOMER.
Returned:
FILE.NAME The full file name including the company
mnemonic if applicable e.g. FXXX.CUSTOMER.
FILE.VAR File variable.

Here we're opening our local application using OPF wrapper subroutine.
It supports caching of opened _les so if this _le is already opened by another
subroutine, whether a core or a local one, _le wouldn't be reopened and
performance wouldn't su_er.
After the _le has been opened the variable FN.FCM contains full _le hame.
(It's FBNK.FT.CREATION.METHOD in case we're working in the main company
with mnemonic \BNK" used for _nancial _les.) In fact, sometimes OPF is
used only to obtain full _le name, e.g. for subsequent SELECT.
112
In order to obtain the mnemonic and the nationality of the customer, we need to
access the dynamic array R.CUSTOMER. To extract values from a dynamic array, angular brackets
“< >” need to be used.(Use ‘()’ for dimensioned arrays)
We can extract data from the dynamic array by specifying field positions as follows

Y.MNEMONIC = R.CUSTOMER<1>
or by specifying the actual name of the field.It is always advisable to use field names ‘coz field
positions could change from one release of Globus to another. Here 1 is the field position of the
field mnemonic in the CUSTOMER file.
How does one know the field numbers and the field names?
Most of the files in Globus have insert files which begin with ‘I_F.’ followed by the name
of the file. They will be available under GLOBUS.BP.These files hold the names and the field positions
of the various fields. These fields could have prefixes/suffixes.
And for a person who knows jBASE or Universe well it's a bit embar-
rassing to learn that some thing absolutely valid in \pure" jBASE doesn't
work in T24 environment (like adding something to dictionary manually { it
lives only until STANDARD.SELECTION record is rebuilt next time).

What's an application after all in T24 context? The answer is: it's a
combination of at least one subroutine containing table structure and busi-
ness logic (based on so-called \template"), one or several data _les (read {
jBASE tables), dictionary _le and several setup records. You'll be surprised
to know that setup records and data records actually are stored the same way
{ setup records in setup applications and data records in data applications

W hy not program? Actually, in our case a subroutine is better than a

program because a subroutine can work indside T24 and therefore can have
access to T24 global variables pool.

First thing to do is to create a directory for our subroutines and programs.

The names of such directories are usually in uppercase and end with \.BP".
That su_x is handy when you need to transfer the source code to another
environment (such names are allowed in DL.DEFINE application which is
used for this purpose).
This directory was created in our home directory bnk.run. To create
a subroutine we _rstly need to invent a name for it. This name is to be
meaningful. Moreover, this name has to be unique to our T24 environment.
How do we know that? For example, we like the name \TEST.RTN".

To run this subroutine as a standalone one

inside T24 it's necessary to create a record in application PGM.FILE:

Performance, code analysis,

Example 1:

* Read current COMPANY record

FN.COMPANY = 'F.COMPANY'
F.COMPANY = ''
CALL OPF(FN.COMPANY, F.COMPANY)
CALL F.READ(FN.COMPANY, 'US0010001', REC.COMPANY, F.COMPANY,LOC.ERR)

What's wrong:
There is a global variable ID.COMPANY which is to be used instead of 'US0010001'.
We don't need to read company record since it's already available in global array R.COMPANY.

So, to end up applications theme: we saw di_erent parts of application

{ data _les, dictionary, subroutine with business logic, FILE.CONTROL
record. What else? See also corresponding records (i.e. with id = application
name) in PGM.FILE (_eld type) and STANDARD.SELECTION.