1. Welcome to the “Services In T24” learning unit.

This learning unit will help you to

understand the concept of services in T24.

SER1.Services In T24-R10.01 1
 After completing this learning unit/course, you will be able to:

•Differentiate between Phantoms and Services in T24

•Understand how a service works

SER1.Services In T24-R10.01 2
 Many software in the market, have processes that need to be run without user
intervention. The processes may vary from simple jobs of backing up historical data to
clearing of temporary files or as important as interacting with interfaces to another
system. These processes may be required executed once a day or may be required to
be executed continuously for a period of time. T24 is no different and also has a
number of these background processes.

In the T24 releases prior to R05, these were called Phantoms.

They were subroutines created in jBASE BASIC using T24 APIs if required and could
be executed once or in an infinite loop until manually stopped.

This was handled via an application called EB.PHANTOM. This application was used
to start and stop the processes.

With the introduction of multi threaded programming in release R05, this application
can not be used if the background process is multi threaded.

This application is not obsolete and can still be used if required.

SER1.Services In T24-R10.01 3
 1.Services are also background processes in T24. But they are multi threaded.

2.They too can be executed just once or in an infinite loop until manually stopped.

3.Services are controlled using an application called TSA.SERVICE

SER1.Services In T24-R10.01 4
 1 A service must be multi threaded, otherwise it must be run as a phantom. A multi
threaded routine consists of the following components. A LOAD routine to load
common variables used in the subroutine, a SELECT routine to select the Ids to be
processed, a record routine which contains the logic to process each id selected and
finally an insert file defined for the routine.

2 Each multi threaded routine in T24 must have a PGM.FILE entry with TYPE = B
which stands for BATCH.

3 Each B type routine has an entry in the BATCH application, and a service is no
different. A service could be made up of one multi threaded routine or multiple routines
that must be run in an order. You will use the BATCH record to define this order using
the JOB field. The BATCH record that you will create will NOT have a BATCH.STAGE
defined as this record must NOT be picked up during COB.

4 Finally, you must create a record in the application TSA.SERVICE. The ID of the
record must match the BATCH record Id. Why is this? – This is because when you
start off a service, T24 looks for a record in the BATCH application and then finds out
which routine it must execute in the background.

SER1.Services In T24-R10.01
 In this learning unit, an existing service called BNK/SWIFT.OUT is used as an
example. The screen shots above show the identical TSA.SERVICE and BATCH
record Ids.

From the BATCH record, you can find out the actual name of the multi threaded
routine and check it’s PGM.FILE entry

SER1.Services In T24-R10.01
 TSA.SERVICE is the application where all services are defined and controlled by the
end user.

ID: The id of the service record must match a record in the BATCH application.
DESCRIPTION : This field holds the description of what the service is used for.
SERVER NAME : This field holds the IP address or the host name of the server where
the current service needs to be executed. This will be used on in a multi application
server architecture.
The whole idea behind a service is that you will have multiple copies of the process
running so that the load can be shared. How many such copies do you want running?
That is defined in the field WORK PROFILE. This field holds the ID of the record in
TSA.WORKLOAD.PROFILE application which defines the number of copies that will
actually execute.
USER : This field should hold a valid T24 user name, whose details are used to
update the audit fields of records that get created or updated by the service.
SERVICE CONTROL : This field can hold three values – AUTO, START and STOP.
STOP can be set in this field to stop the service when it is executing.
You will learn about the other fields in the next few slides.

SER1.Services In T24-R10.01 7
 1. With the advent of multi threading in T24, two new programs (they are not
subroutines) have been coded to execute services. They are tSM and tSA.

2. tSM is stands for T24 Service Manager and tSA stands for T24 Service Agent

3. The tSA program is in charge of actually executing the service(s). Each copy of the
program executed, in turn executes one copy of the assigned service.

4. Since multiple copies of the tSA program can execute – only ONE tSM program
executes to take care of the entire situation.

You will now see how a service is executed so that this slide makes more sense.

SER1.Services In T24-R10.01 8
 You must first turn the service on using the SERVICE.CONTROL field in
TSA.SERVICE. This change must be authorised. You must remember that this action
does not start off the service in the background. Its only a flag to say that the service
will be picked up and executed.

You must then start the tSM program. This can be done only from the jBASE prompt.
This will cause all service records with either START or AUTO to be picked up to be
started.

SER1.Services In T24-R10.01
 Start the tSM by using START.TSM at the jBASE shell prompt. You have two options
when starting the tSM – to start it in DEBUG mode or to leave out the DEBUG option.

The DEBUG option allows you to manually start tSA’s to execute your service. In the
screen shot above, OFS.MESSAGE.SERVICE has one tSA assigned to it, but
SWIFT.OUT has two. How is this possible?

When defining a service in TSA.SERVICE, the field WORK.PROFILE links to an

application TSA.WORKLOAD.PROFILE where you can define how many tSA’s are
required. Each tSA represents one copy of your multi threaded service being
executed.

Now in the screen shot above, you must understand that the services have not been
started as yet.

SER1.Services In T24-R10.01 10
 TSA.WORKLOAD.PROFILE is the application which defines the number of tSAs
required. The ID of a record in this application can be any alphanumeric text.

The number of agents in TSA.WORKLOAD.PROFILE can be set based on time if

required.
TIME and AGENTS.REQUIRED : These fields are associated multi value set which
holds the specific time and the number of agents required at that point in time.

The number of agents that can run on server is directly proportional to the number of
processors available. Just because T24 supports multi threaded services doesn’t
mean you can start a 100 tSA’s in the background. It will kill the server. The thumb rule
to be followed is a maximum or 2 tSA’s per processor available.

SER1.Services In T24-R10.01 11
 After the agents are assigned jobs, in DEBUG mode, type tSA <agent number> at the
jBASE shell prompt to actually start the agents to the service. After the job is finished
successfully, a message ‘Agent Stopped’ will be displayed and the cursor will go back
to jBASE shell prompt.
When a service stops, the field SERVICE.CONTROL is set to STOP automatically.

SER1.Services In T24-R10.01 12
 Services can be configured as a periodic activity using the FREQUENCY field. This
field holds a value in the format
Date Time Frequency- where,
Date is the system date which is entered in T24 date format
Time is entered in the format HH:MM(T24 hour format)
Frequency is entered in the format 1D,2D etc.,
EXAMPLE : 20100215 14:00 1D

TSM would normally build the service profile only for the services which are set to
START or AUTO. But when the frequency is specified for the service and
SERVICE.CONTROL is set as ‘STOP’, the TSM would check whether the specified
frequency has been reached taking into account the time as well as frequency and
would start the service. When the service is stopped, the frequency would be cycled to
the next date. This field is not allowed for an AUTO service. The service control cannot
be changed if the frequency is present. This is mostly using for archiving.

SER1.Services In T24-R10.01
 1. To configure services as a periodic activity, input a date, time and frequency when
the service has to be started in the corresponding TSA.SERVICE record. Note that the
service control for the service PW.MAPPING is set to stop. The frequency configured
for PW.MAPPING service is 20100216 11:35. The TSM has been started in interactive
mode. The time when the TSM is started is 11:32 on 16th Feb.

SER1.Services In T24-R10.01 14
 TSM builds the service profile for all services with service control set to ‘STOP’ and
which have a ‘FREQUENCY’ set. Once the time as specified in the frequency field of
the service has been reached, TSM automatically sets the service control for the
service to ‘START’ and prompts the user to launch the required agents for the
service(in DEBUG mode). Once the service has stopped, the service control for the
service is set back to ‘STOP’ and the FREQUENCY gets cycled.

SER1.Services In T24-R10.01 15
 After the agents actually start performing the service, if you wish you have a look at
the status of the agents, an application TSA.STATUS can be used. If you list this
application, all the services that are to be executed by the agents will be displayed.
The ID of the record in this will be the agent number.

SER1.Services In T24-R10.01 16
 You know tSM launches and controls the tSAs. How does an end user know what is
happening with the tSAs? Use the enquiry AGENT.STATUS

Agent ID is the allocated Agent Number for the service

T24.SESSION.NO is updated with a unique number that identifies every session in

T24. A number between 1 -99999 is allocated when a session is started in a port to
uniquely identify that particular session in T24(both for online and COB).
Note: This random number is generated using a routine called
EB.ALLOCATE.SESSION.NUMBER and is stored in a common variable called
C$T24.SESSION.NO. This helps in improving the monitoring capabilities of T24.
A live file called T24.SESSION gets updated with record key being the
T24.SESSION.NO and contains information regarding the agent to which this session
number was assigned. A record in this application gets deleted, when the
corresponding process terminates(session expires).

Server Name is the name of the server where the agent is running. Note that details of
tSAs and tSMs across application servers will be updated here

COB1.Close Of Business - Introduction-R10.01 17

 Last Message is the message displayed by the agents as they are performing the
jobs. The agent running tSM will not display any message as it is just monitoring
agents.

Como Name is the name of the log record ID that holds the log information of the
agent. These log records are stored in a directory called &COMO&. The contents of
these records cannot be viewed from browser. You will have to open these records at
the jBASE prompt. The log file name is in the format ‘tSA_<agent
number>_<date>_<time>’
LAST.MESSAGE is the message displayed by the agents as they are performing the
jobs. The agent running tSM will not display any message as it is just monitoring
agents.
COMO.NAME holds the name of the log file that has the log information of the
particular agent.
JOB.PROGRESS holds the status of the jobs being performed.

COB1.Close Of Business - Introduction-R10.01

 COMO.NAME in AGENT.STATUS holds the name of the log file. Log files are stored
under a directory &COMO&. To view the log files use the command ‘LIST &COMO&’.
Use the command ‘JED &COMO& <Log file name>’ to view the contents of the log file.
If an agent is restarted, there will be two log files for that agent as the log file ID is
based on date and time. Log files do not get cleared automatically from the &COMO&.

SER1.Services In T24-R10.01 20
 When multiple application servers are part on the T24 architecture, all processors can
be made use of when executing services. One tSM must be started on each server
and the tSA’s started appropriately.

You must remember that data resides centrally – so in the TSA.SERVICE record, you
will need to specify a workload profile for each server and also mention the server
names in the corresponding multi-value fields.

SER1.Services In T24-R10.01 21
 1. An activation file is a file in the backend that contains all the ID’s to be processed
by the service. Once an ID is processed from the activation file, it is removed from
there

2. Since we have populated the file with the ids that the service needs to process,
there is no need for a SELECT routine separately

3. For a service to use an activation file, it should be mentioned in the PGM.FILE

entry for the job that is running as a service. The field Activation File should be
set to “YES” or the name of the activation file. If you choose the option as yes,
then the name of the activation file will be F.<SERVICE.NAME>.LIST
For eg: BNK/SWIFT.OUT, runs DE.OUTWARD job as a service. Now, as you can
see in the screenshot, the field ACTIVATION.FILE has been set to yes.

Q. Based on what you learnt just now, what would be the name of the activation
file?
A. F.SWIFT.OUT.LIST (the BNK part is not included)

NOTE: When you start a service by setting the SERVICE.CONTROL field to

“START” in the TSA.SERVICE record of that service, you would expect the
service to run once and then stop. This is not the case for services having
activation files. When a particular service has an activation file, it keeps running
even if the SERVICE.CONTROL field is set to “START”.

SER1.Services In T24-R10.01 22
 1. FALSE – Single Threaded mode
2. FALSE – Each server should have one tSM running
3. TRUE
4. FALSE – TSA.STATUS
5. TRUE
6. FALSE – TSA.STATUS

SER1.Services In T24-R10.01 23
 You will now be able to:

•Differentiate between Phantoms and Services

•Explain the working of Services in T24

SER1.Services In T24-R10.01 24
SER1.Services In T24-R10.01 25