CLOSE OF BUSINESS

Introduction
T24 Batch Processing is handled by the Close Of Business (COB). Close Of Business is used
for processing events, calculating and posting interest, rolling the bank date forward and
productions of various reports. The Close Of Business triggers various activities based on the
scheduled date and based on any specific condition.
The Close Of Business consists of the following five stages in sorted order.

Figure 1 The five stages of Batch mode

The Close Of Business runs various processes based on the order above. The Close Of
Business runs the process in sorted order of stages and within the stage based on the sequence
number.
Each Batch stage consists of a number of processes with same or different sequence number ,
which correspond directly to records on the BATCH file, and each process consists of a
number of jobs which are routines defined on PGM.FILE as type B. Each Batch process
defines the stage and sequence at which it has to be run, the jobs to be run and the frequency
with which it has to be run.
At no stage, the stage and the sequence of the batch process will be violated thus ensuring
data integrity and proper processing of jobs if they are dependant on a earlier stage.

Initialisation
T24 COB is run as a T24 Service.
To invoke a COB, a record needs to be created by the TSM service with the key as COB. This
service has to be defined with the appropriate profile and the server it has to run and the
OPERATOR who will be running the Close Of Business. Other details such as the
REVIEW.TIME and DEATH.WATCH have to be entered otherwise the details will be
defaulted from the TSA.PARAMETER record.
Once the COB record is created, the service status can be set to START thus making the
service ready for running.
Temenos Service Manager runs the COB service as a background service by invoking the
appropriate agents as defined in the profile of COB service.

If there are any unresolved errors on the EB.EOD.ERROR file (which were produced as a
result of a previous Close Of Business) and if the errors are critical, then the Close of
Business will stop for the errors to be resolved first.
Start COB with Users Signed On
Non Stop Processing and Close Of Business compliment each other. Close Of Business
disallow input and processing of records in all applications other than one supported by NonStop service.
The applications that are available in NS stop service will be available without any
restrictions and will be using the next working date for processing thus ensuring the
concurrent transactions are not picked up processing by the Close Of Business which is
running in parallel.
To support this, Close Of Business distinguishes the dates by two different records per
company in the DATES application. Close Of Business at the beginning cycles the dates
record and restores the old dates record with the key as the CO.CODE-COB thus ensuring
that all COB processing happens based on the COB record in DATES and online processing
happens with the cycled record in DATES application.
Initiate the COB Service
To initiate the COB service, the record in TSA.SERVICE application called COB has to be
marked for Starting. If the TSM service is not started, then it needs to be started before the
COB is initiated.

Figure 2 Starting the Temenos Service Manager

Figure 3 Invoking the Temenos Service Manager

Figure 4 Starting the COB Service

This makes the COB service available and also TSM allocates the number of agents that are
available for running the COB. The agents replace the sessions which were used to run the
job in a multi thread architecture to save upon the time and to maximise the system resources.
Temenos Service Agents are invoked to run the Close Of Business and they run and update
the file TSA.STATUS of their progress and status.

Multiple Session End of Day

T24 COB processes have been designed to run in multi thread way to reduce the time taken
and to maximise the usage of system resources. Multiple agents can be used to run the COB
and load on the jobs will be shared by them.
However, this will not affect the sequence or the verification of the COB. The agents will
compliment each other within the same stage and sequence and will not violate the agents
thus ensuring data integrity.
The number of agents can be defined in the TSA.WORKLOAD.PROFILE record, which can
be attached to the TSA.SERVICE record COB.

Figure 5 TSA.WORKLOAD.PROFILE Record

The agents available for the COB record as defined in the profile will be used by the Temenos
Service Manager to run the COB sessions. Close Of Business will be invoked in parallel for
the n number of agents as defined in the profile.
Thus the COB can run with the help of multiple agents and the performance could be
improved.
COB per company

There is a facility in Close Of Business to run it specifically for one or a set of companies.
This ensures that Global Processing feature of T24 is maintained. The companies could be
grouped together and COB shall be run only for them. While the COB is running for a
company, the other companies will be in online mode and will perform on a different date.

COB in Interactive Mode

Close Of Business can be run in interactive mode for testing purposes. The agents then have
to be manually started for every session. This requires the Temenos Service Manager to run
in debug mode and thus the subsequent agents have to be manually started. It is advised that
this method is used for testing purposes only. After starting the TSM, the individual agents
allotted to COB should be manually started.

Figure 6 Invoking the Temenos Service Manager

Figure 7 Invoking the COB in Interactive Mode

Figure 8 COB Running with Two Agents

List Files

Every job during the Close Of Business uses a LIST file for storing and sharing the records
for processing between different agents. The LIST file is dynamically determined based on
the session number doing the SELECT processing of a multi-threaded job. The other agents
use the allotted list for sharing their load of the job. The list file is empty at the end of the job
thus making it available for a different job.
Como

Since the introduction of multi threaded architecture, the Como will be written with the
session no to distinguish processing between different threads. The Como will be written
with the key as tSA_<agent no>_datetime.
Monitoring COB

Three enquiries are available that help in monitoring the progress of COB and the records
processed with the time taken. They can be accessed via the Temenos Enterprise Console
(tEC).
COB.PROGRESS A listing of active companies and an indication (progress bar) of their time

to completion

JOB.PROGRESS This enquiry lists all active and completed jobs by descending start times (i.e.

current on top).It shows the start time, end time, elapsed time, contracts
processed, total contracts to process, throughput (contracts/minute) and individual
server rate. The latter is the number of contracts processed in one minute by a
server process this will be compared historically to see if thee job is slowing
down as time passes.
JOB.HISTORY Drilling down from JOB.PROGRESS, the user can see a graph of the elapsed time
of the last ten runs of the job and the individual server rate. If the latter figure rises
over time, this indicates a problem which could be badly sized files.
Batch Output
All reports, COMOs etc. produced by the batch system are output using the T24 report
control system. This enables the operator to determine the destination printer, user addressing,
number of copies etc. The following applications are used in this process:

Figure 9 COB Output Applications

It is recommended that all COB COMOs be retained securely for at least six weeks.
If there is an occasion to restore and rerun, then the COMOs should be printed or copied to a
secure medium before the restore takes place.
Error Handling
As described in the introduction, a process can consist of any number of jobs, which in turn
can execute a number of programs or operating system commands. If an error occurs the
system may return immediately to the monitor screen and display the process and the job in
error, or in the case of less severe errors, update the record for the current batch run and the
current company on the EB.EOD.ERROR file and continue.
The details of these errors can be found be examining the records on the EB.EOD.ERROR
file and on the EB.EOD.ERROR.DETAIL file.
The COB processes are wrapped around jBase transaction management. Hence, in case of any
crashes during COB the concerned transaction will be rolled back and the COB will continue.
This ensures that COB can continue after an error and partial updates are rolled back to keep
the database in sync.
Jobs can abort for a variety of reasons, both system and application orientated
Identify the aborted job.
Any system related crashes will be sensed by the Temenos Service Manager and the dead
agent will be started again. The Temenos Service Manager if there is no activity in a agent for
a period of time as defined in the DEATH.WATCH field of TSA.SERVICE, restarts the agent
thus ensuring that the COB Crashes are monitored and restarted by the Service Manager.

Any application related crashes will write into EB.EOD.ERROR with the information on the
job name, the record and the text of the crash. The underlying record from the .LIST file will
be removed and the updates done till then for the particular transaction will be rolled back.

Figure 10 EB.EOD.ERROR Record

There will be some critical jobs which will crash and abort the COB due to business reasons
as further continuance of COB is not advocated. These jobs will be defined as .CRITICAL in
the ADDITIONAL.INFO field of PGM.FILE.
Error Messages
There are a number of error messages produced directly from the COB monitor which are:

Figure 11 Batch Control Error Messages