1

2
3
4
5
In T24 multithreaded routines are executed by service agents.

6
Multithreading in T24 is composed of a set of methods and a controller
known as BATCH.JOB.CONTROL

Components of a multi threaded routine

Routine to initialise common variables – called the Load Routine.

Naming convention <JOB>.LOAD
Routine to fetch the list of ID’s – called the Select Routine. Naming
convention <JOB>.SELECT
Routine to process the record – called the Record Routine. Naming
convention <JOB>. Note although it is called the record routine, the
name is not <JOB>.RECORD

Common variables are declared in I_<JOB.NAME>.COMMON

The complete execution of executing multithreaded routine is controlled
by BATCH.JOB.CONTROL

7
8
If the name of your multi threaded subroutine is GIFT.VOUCHER, then
this subroutine must be called GIFT.VOUCHER.LOAD. In this
subroutine, you must initialise all the common variables declared in
I_GIFT.VOUCHER.COMMON

9
Some variables must be used across all the routines. Hence we need
common variables.

A good practice to follow when creating I_ files to hold common

variables is to define each variable on a new line and use the ;* to add a
comment that describes the use of each variable. For example, if you
open the I_GIFT.VOUCHER.COMMON it would look like this

Remember to include this common file in the .LOAD routine.

10
Once the .LOAD routine is ready, the SELECT routine can be coded.
The name of your select routine must contain the .SELECT key word.
So in the example you are looking at, it must be
GIFT.VOUCHER.SELECT. In this routine, you will form and execute the
select statement. The file that contains the selected ids is created in this
routine using the core routine BATCH.BUILD.LIST. This routine takes
two parameters. The first one is a dynamic array and the second is the
actual list of Ids returned from the execution of the SELECT statement.
Without that line of code, your .SELECT routine is useless.

Note : If the ACTIVATION.FILE in PGM.FILE is set to yes, then the

multi threading execution assumes that the list of ID’s got selected
already and it is available already and hence the select routine may not
be required

11
The call to BATCH.BUILD.LIST is the most important line of code in the
.SELECT routine of any multi threaded routine. This subroutine is
responsible for writing the selected Contract ID’s in to the LIST FILE. It
takes two parameters.
The first parameter is a dynamic array with 7 positions
1.The first position in the array denotes the name of the list file to be
created with the selected ids. This is always null, T24 decides the
name of the LIST FILE. Normally the name of the LIST FILE will be
F.JOB.LIST.<Seq No> for eg: F.JOB.LIST.1
2. The second position can be used to pass an application
(F.APPLICATION name) so that BATCH.BUILD.LIST can form and
execute the SELECT for you.
3.The criteria for the selection can be passed in the third position.
Note: If you provide 2nd and 3rd values in the first parameter, then you
need not write SELECT statement to fetch the list of ID’s.
4.The fourth position contains the last ID in the LIST FILE. So if this
position contains 101, there are 101 records in the LIST.FILE.
5.The fifth position contains the total number of contacts selected and
written on to the list file. Let’s assume you did a select on the
FUNDS.TRANSFER application, and 110 contracts were selected and
written, then 110 will be returned by BATCH.BUILD.LIST to this
position.

12
6. When T24 processes each ID from the list, it is wrapped around a
transaction boundary. Using the sixth position you can decide at you own risk
and bulk transactions. In other words, multiple ids can be processed in one
transaction boundary. The number of ids to bulk is mentioned here.
Note: The value in the 4th and 5th position need not be same. It depends upon
the bulking in the 6th position or in the PGM.FILE. Even if the bulking is not
specified anywhere, T24 does default bulking as:
1-100 Records – 1 Contract per record
101-1000 Records – 10 Contract per record
1001-10000 Records - 100 Contacts per record
> 10000 – 200 Contracts per record
In the example given above, there are 317 CUSTOMER records. The first
100n records will be written one CUSTOMER.ID per LIST.FILE.ID. From 101-
1000 T24 bulks 10 IDs per record..so for the remaining 217 records 22
records are needed in the LIST.FILE. Hence position 4 is 122 (for 122 records
in List File) and position 5 is 317 (for 317 Customer IDs selected)
7. A multi threaded routine can have a .FILTER routine that can contains logic
to further filter the ids selected. This is done before the list file is built.
The second parameter to BATCH.BUILD.LIST is the actual list of IDs
returned after the execution of the SELECT statement.

13
The last component is the RECORD routine that contains the
processing logic. It takes one parameter the ID to be processed.
Note – there is no loop to iterate through each ID in this routine. Each
agent will process the ID received

14
15
17
18
There is a T24 core routine called BATCH.JOB.CONTROL that is
written exclusively to execute multi threaded routines. This multi-
threaded routine can either be run as a Service or as a COB Job. A tSA
(T24 Service Agent) is a program that eventually calls
BATCH.JOB.CONTROL.

1. Once the tSAs are started, each tSA will execute the .LOAD routine
and initialise the global variables
2. Then only one tSA will execute the .SELECT routine while the other
tSAs wait. The .SELECT routine populates a LIST. This list file will
contain the list of ID’s to be processed.
3. Once the LIST.FILE is ready, each tSA will pick up ID from the list
file and execute the record routine. Here you can see the flow of
process routine with the gift voucher example..

19
Write a multi threaded routine to set the status of the debit card issued.

If END.DATE is less than TODAY, then set status as EXPIRED, else set
STATUS as CURRENT

Use DAS routine to fetch the list of Debit Card IDs.

Note: the second parameter for BATCH.BUILD.LIST is the list of IDs. Hence, the
.SELECT routine must contain the lines

CALL DAS(‘AC.DEBIT.CARD’,DAS.AC.DEBIT.CARD$ALL.CARDS,'','')
CALL BATCH.BUILD.LIST(‘’,THE.LIST)

20
21
The .FILTER routine is an optional part of a multi threaded routine in
T24. It filters out the IDs selected before actually building the list file.

This routine is called from BATCH.BUILD.LIST for each Contract ID

selected, to decide whether it must be part of the list file or not. The
routine has one parameter that must be set to NULL in order to discard
the current ID from the list.

The filter routine is a single threaded routine. You must remember never
to perform any IO from within the .FILTER routine as it will be a
performance bottleneck.

22
23
1. CONTROL.LIST is a common variable declared in I_BATCH.FILES
2. Interest accrual processing job in LD over a weekend should accrue
interest for all the contracts on Friday, then again on Saturday and
again on Sunday. Here agents shall must process the accrual for
Friday and on completion of this start the processing for Saturday.
After completing the same, it should go over to Sunday.
Here we cannot do the following:
a.) Select all contracts and accrue for Friday/Saturday/Sunday in
one go
Thus, the requirement is to determine the sequence and multi thread
within every sequence.
3. CONTROL.LIST is initialized in the .SELECT routine (only the first
time) when it is invoked. Then .SELECT will be invoked once for
every value in CONTROL.LIST.

24
3. Since .SELECT is called multiple times, the job can perform the
select accordingly (First time for Friday, second time for Saturday
etc…) and the LIST FILE will be populated. The processing then will
happen based on what is there in LIST FILE and once finished we
will invoke .SELECT for the next value in CONTROL.LIST
4. BATCH.JOB.CONTROL is the core routine that is responsible for
executing a Multi-threaded routine. Within this logic, there is a file
called F.BATCH.STATUS, that contains the status of the routine
(also known as job) being executed. The value in CONTROL.LIST is
written into F.BATCH.STATUS along with the keyword “processing”
to denote that the job is being processed. Once all values in
CONTROL.LIST are over, then the CONTROL.LIST is set as
“processed” and written to F.BATCH.STATUS

25
Here you can see a sample .SELECT routine where sequencing needs to be done
within the same job for LD records. First time the .SELECT routine is called by
BATCH.JOB.CONTROL, the value of CONTROL.LIST will be NULL. the values in
CONTROL.LIST should be separated by FM (Field Markers)
Always the first value in CONTROL.LIST will be the current value to be processed,
and once values are processed in CONTROL.LIST it will be removed.
Note : EB.READLIST is a T24 API used to select the list of ID’s. This API is now
wrapped within DAS, to ensure the SELECT’s are restricted. The syntax for
EB.READLIST is
CALL EB.READLIST(SELECT.STATEMENT, KEY.LIST, LIST.NAME, SELECTED,
SYSTEM.RETURN.CODE)
SELECT.STATEMENT Execute statement (optional - select can be active)
KEY.LIST Id list returned, null if error
LIST.NAME Used as part of SAVE.LIST id
SELECTED Number of records selected
SYSTEM.RETURN.CODE @SYSTEM.RETURN.CODE after select statement.
Status codes returned by system processes

26
27
1. FALSE – Only one entry for the actual process(record) routine
2. FALSE
3. TRUE
4. FALSE – I_BATCH.FILES
5. TRUE

28
29