T24 PARAMETER TABLES

Objective
To familiarize with some of the T24 parameter tables like:
• PGM.FILE
• STANDARD.SELECTION
• COMPANY
• SPF
• DATES
• HOLIDAY
• INDUSTRY
• SECTOR
• INTERCO.PARAMETER
• LOCAL.TABLE
• LOCAL.REF.TABLE
PGM.FILE
• Contains program files in T24 as an entry.
• A valid entry should exist in PGM.FILE.
• It holds characteristics of a program
Example for PGM.FILE
Definition of the PGM.FILE
• Field 1 TYPE - Type of process
• Field 2 SCREEN TITLE - Meaningful Heading
• Field 3 ADDITIONAL INFO - Other special characteristics
• Field 5 PRODUCT - Product to which the
application belongs to
Types
• Type H - A program that has this type maintains three files
- Unauthorised -- Updated at Input
- Live -- Updated at authorisation
- History -- Updated whenever there is a change in the
authorised record

Example – ACCOUNT
Types
• Type U - A program similar to type 'H' except that history is not
maintained
Example - ABBREVIATION

• Type L - A program that displays the data of a live file but does not
allow updates Directly. Updates to these files would be controlled
by the System automatically
Example - STMT.ENTRY
Types
• Type T - A program that displays data in a table file (such as a list
of keys) but does not allow update
Example – LMM.CUSTOMER

• Type W - A program that permits updates to a work or temporary

file. A typical example would be the REPGEN.OUTPUT program
where print or display parameters for a report can be loaded.
Types
• Type B - A Batch job that can only be accessed during the 'off-line'
processing in BATCH.CONTROL
• Type M - Main-line program that can be run from the action line but has no
file directly associated with it.
• Type A - Access to GLOBUS environment program. There is only one such
program, called "EX" and it is this program that is automatically initiated
when a user logs into "INFORMATION" and enters the GLOBUS
environment.
Types
• Type S - A program used in the GLOBUS system but one that is
executed automatically whenever required.
It cannot be entered by the user either at the action line or from
within the Batch Control system.
It is recommended that these are loaded only when they are
needed by the report generator.
Example – IN2… routines
Types
• Type R - Report Generator routine.
Report programs written via the report generator can use GLOBUS
subroutines.

These type ‘R’ records define the routines to be used and the
validation on the arguments that are present in the calls
STANDARD SELECTION
• This file defines the layout of the data dictionaries and the alternate
indices for all files on the system.
• Defines two types of fields
- System defined (SYS)
- User defined (USR)
• The dictionary and alternate indices are built when the record is
authorised.
Field definition for SS
Name of the field

Type of the field (D-Type)

Field number (Always 0 for @id)

The name of the internal globus routine that does

data type validation

Display format (10 Characters right justified)

Single/Multi Value
Continuation of the above record
SS defined with local reference fields
Field definition for SS
• When the field Rebuild Sys flds is set to ‘Y’ and then authorised, it
will rebuild the fields in specific application. (In this example - it is
CUSTOMER)
DATES
• A Date record exists for each company.
• Contains the current run date, the previous and the next working
day.
• During the End Of Day Process, the current date is changed to the
next working day as stored in the Dates file.
• Refers to the HOLIDAY table to check for holidays in order to set
the next working day .
Example for DATE application
HOLIDAY
• The purpose of this table is to indicate the public holidays for each
Country or Region within a Country, for the calendar years over
which the bank's current business is spread.
• The User must indicate, for each Country or Region, the public
holidays and which day(s) of the week make up the weekend.
HOLIDAY
• The non-working weekend days are then generated automatically
for the year and for this reason they do not have to be specified
individually as public holidays.
• Each GLOBUS Application will refer to this table during input
validation to verify that any dates entered by the user are working
days or to force an override to accept non-working days.
Example for HOLIDAY table
Specify the date in
the respective
month’s field to
declare holiday.
Specify multiple
dates separated by
spaces
COMPANY
• This is the first file that would be set up in any bank that uses
GLOBUS.
• The Company file contains details of the Company's name, the
Mnemonic (by which all the files maintain at this company's level
are prefixed), the file classification details, the applications to be
run and Company level defaults and parameters.
Example for COMPANY table

Contains
mnemonic of
the bank
Example for COMPANY table
Local currency of the site
where installation has taken
place

BUY.SELL.RATE - means
that the Buy and sell rates
are entered and Middle rates
are calculated.
MIDDLE.RATE - means that
the middle rates are entered
and system uses the spread
rates to calculate Buy and
sell rates

Various applications
installed
Example for COMPANY table

This is the next financial year

end with a twelve month
frequency. So at the end of
year, next year end is
calculated. Previous year end
is stored in LAST.YEAR.END
(Field no – 49)

Indicates the number of

month without customer
activity before an account is
declared as inactive

Identifies the mask, the use

wants to apply to customer
type accounts
SPF – System Parameter File
• This file holds the details of the system wide parameters that are
required to run the GLOBUS system.
• Allows to define various parameters such as, the main data
accounts and their associated disk backup areas (for the start/end
of day processes) the backup mode, the shared memory files to be
used
SPF – System Parameter File
• The maximum number of pages allowed to be displayed in the
enquiry system.
• There are the other fields not input by the user but updated by
other processes which includes the system operation mode and
recovery date and time.
Example for SPF table
Machine date as on start of day

O-Online mode (Users can input transactions

when end of day is in execution)
B – Batch
R - Recovery

Contains the number of days to which the

exception log history in
EXCEPTION.LOG.HIST file should be
retained

If the flag is set to ‘Y’ then all output from the

batch is stored in HOLD File

Specifies the number of days after which

reports will be removed from the hold file
&HOLD&
Example for SPF table
Contains Path where the Data
files, The initial attach point on
login for users and The path of
the dictionary files are stored
here.

Specifies the number of days after

which a report that has been
spooled and held will be removed
from the hold file, The customer
held file and the &HOLD& File

Specifies License code

Specifies the date on

which the maintainance
contract is due for
renewal
Continued with SPF record

Product Installed
in the bank

User Licence
INTERCO.PARAMETER
• Tells whether multi-company accounting environment is being
used.
• If yes, tells which part of customer account is unique.
• Only one record with id SYSTEM exists
• Should be setup before creating second company.
INTERCO.PARAMETER
• Before setting up this record, ACCOUNT.CLASS should have
record with id INTERCO
• BALANCE.INTERCOMP indicates whether intercompany
accounting is allowed
INTERCO.PARAMETER
DEPT.ACCT.OFFICER
• To identify Departments & Account Officer in the Bank.
• Each customer will have assigned a Account Officer code. Likewise
each User also gets assigned Department code or Account Officer
code.
• Length of DAO code can be altered in EB.OBJECT file.
DEPT.ACCT.OFFICER
SECTOR
• Sector codes are used for broader classification of Customers to
which they belong like Private, Public, Corporate & Bank
INDUSTRY
• To identify to which industry customer belongs & is trading in.
• Used for more detailed classification of customer along with sector
code.
• Useful for bank to produce reports/information on to which
industries bank is financing
• To analyze the risk involved in the industry
INDUSTRY
LOCAL.TABLE
This table allows the specific details of fields to be defined, like,
• The name of the field
• The minimum and maximum number of characters
• The type of characters
• List of all possible input values
• Whether the input is to be validated against the key of another
table.
The local fields are referenced by a numeric code of maximum 4
digits.
Example for Local.Table
LOCAL.TABLE
• In the above example “ CL.LODGED.CUST”
is a field added to a CUSTOMER application as local element with
maximum character of 35 length and data type “ A” alphanumeric
characters.
• The local element created should be attached to a table
LOCAL.REF.TABLE to view the field in CUSTOMER application
Vetting Table ( LOCAL.TABLE)
• VETTING.TABLE(Field 6.1)
Vetting table values are set where the user is only allowed to input a pre-
defined values from those entered in the LOCAL.TABLE record.

• GB REMARK(Field 7.1.1)
Provide the enrichment for the field value.

• These values may only be specified when the input is not being checked
against another Application (Field 18).
LOCAL.REF.TABLE
• L.R.T, a reference table contains the field defined in local.table
i.e. Local.table ID is attached to the respective application in L.R.T
• This table contains the association of single-valued ,multi-valued
as well as grouped sets.
Example for L.R.T
Attaching a Local Field to an Application

• Define the field and its details in LOCAL.TABLE

• Attach the field to an application using LOCAL.REF.TABLE
• The key to LOCAL.REF.TABLE must be a T24 application name
• Include the LOCAL.TABLE numbers in the LOCAL.REF.TABLE
record
Attaching a Local Field to an Application
• To specifies whether a local reference field for an application is single value, multivalue, or
subvalue associated, attach the LOCAL.TABLE ID as shown below in LOC.REF.TABLE.

Single value

1.1 1 LOCAL REF 1

2.1 left blank

Multivalue

1.1 1 LOCAL REF 1

2.1 XX.
Attaching a Local Field to an Application

• Associated subvalue

1.1 1 LOCAL REF 1

2.1 XX< (XX< denotes start of association)

1.2 2 LOCAL REF 2

2.2 XX- (XX- denotes part of association)

1.3 3 LOCAL REF 3

2.3 XX> (XX> denotes end of association)
Attaching a Local Field to an Application

New field has

been added to
the customer
Workshop
 Design a Local Reference field LOAN.CONFIRM for the CUSTOMER
application which allows either “YES” or “NO” as value. Value “Yes” is only
for customer belongs to sector 1001.

Give enrichments as follows

“YES” - Loan allocated.

“NO” - Loan rejected.
Workshop
• Design a Local Reference field(multi value field) Preferable
language field for the CUSTOMER application which allows only
the LANGUAGE id.

• Design a Local Reference fields for corresponding address of the

customer (multi value set)
CORR.ADDRESS,CORR.STREET,CORR.TOWN,CORR.POST.C
ODE which allows free text.
WORKSHOP SOLUTION

Vetting Table setup

WORKSHOP SOLUTION

This field validates the input of local

field against LANGUAGE
WORKSHOP SOLUTION
 Single field

 Multi value
field

 Multi value
set
WORKSHOP SOLUTION
Summary
• PGM.FILE – Any thing that needs to be executed from within
Globus needs to have an entry in the PGM.FILE
• STANDARD.SELECTION – Contains the various fields of an
application. All valid applications in Globus have an entry in this
file.
• COMPANY – The first file to be set up during an installation.
Contains the bank’s mnemonic etc.
• DATES – Contains the Globus current date, the next working date
and the previous working date that are used during EOD.
Summary
• HOLIDAY – Contains the various holidays, weekends and the
working days of the bank.
• SPF – The SYSTEM PARAMETER FILE. Contains various fields
that help parameterise the system.
• INTERCO.PARAMETER - Tells whether multi-company accounting
environment is being used.
• DEPT.ACCT.OFFICER - To identify Departments & Account Officer
in the Bank.
Summary
• SECTOR - Group customer into broad classifications like Private
Sector, Public Sector, Corporate, Banks etc.
• INDUSTRY - to identify the industry in which the Customer is trading
• LOCAL.TABLE - Local elements may be defined for Applications
which have a Local Reference field
• LOCAL.REF.TABLE - To specify the names of any Applications that
are to include any previously defined Local Table elements as Input
fields and the order in which they are to appear on the screen.
THANK YOU