Close Of Business - User Guide

Release R15.000
June 2015

©2015 Temenos Headquarters SA - all rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Overview 4
Setup 5
Initialisation 5
Batch Output 11
Error Handling 11

Close Of Business - User Guide - Release R15.000 - Page 2 of 13

Introduction

Purpose of this Guide

Close of business is an important activity to be initiated when all day to day customer operations are completed. This document details about
Temenos Close of Business activity, its configuration and its working.

Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.

Close Of Business - User Guide - Release R15.000 - Page 3 of 13

Overview

Close of Business (COB) is the most important T24 activity that brings together the events of the day for the bank and processes them. The
events could be in terms of loan schedules, accruals, internal bank accounting and could be reports. These constitute important financial activ-
ity and more importantly are scheduled for a specific day. Temenos Close of Business is a robust mechanism through which the above facility
can be achieved with scalability in terms of performance and reliable in terms of recovery.

T24 Batch Processing is handled by the Close of Business. 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.

Stage Description

APPLICATION Individual application processes (Forex, Funds Transfer etc)

SYSTEM WIDE System Wide processes (Interest & Charges, Revaluation etc)

REPORTING Main system reports (trial balance, general ledgers, transaction journals etc)

START OF DAY After date changed (Standing orders, split month end events, cash flow maintenance etc)

ON-LINE Any non-critical reports and processes which can be run after the system has returned to online mode.

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.

Close Of Business - User Guide - Release R15.000 - Page 4 of 13

Setup

Initialisation
T24 COB is run as a T24 Service.

To begin with a Close of Business (COB) record needs to be created in the TSA.SERVICE with the key as COB. The key is hardcoded and shall
remain the same for global close of business. 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. The profile can be defined in the TSA.WORKLOAD.PROFILE record. The profile also
contains the number of agents with which the Close Of Business has to be invoked. Other details such as the REVIEW.TIME and
DEATH.WATCH have to be specified in the TSA.SERVICE record 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 ser-
vice.

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.

1. When there is a fatal error while processing the LOAD or the SELECT routine of a job, the respective service would be STOPPED and
need not try this again and again.
2. When there is a fatal error during online or cob processing , core dump is written on the TAF Log.
3. TSM would monitor frequent crashes happening in a service and would stop the service .There are two fields STOPPAGE.TIME and
STOP.COUNT introduced in TSA.PARAMETER.STOP.COUNT specifies the no.of crashes allowed in a specific time interval given in
STOPPAGE.TIME.When the no.of crashes (identified when the agent is marked as ‘DEAD’) is more than the STOP.COUNT in a spe-
cific time period , TSM would stop the service.
4. A new field LOGIN.STATUS has been introduced in the user application. It would be set to ‘ACTIVE’ when the user is currently logged
into T24 .When the user signs off the LOGIN.STATUS field would be nullified. An enquiry USER.STATUS has been created to find the
active list of users.
5. COMO will have the following tags:

<service>   - at the begining of the tSA

<process > = </process> - Begining and end of every process and within that

<job>   - </job> = begining and end of every job within that process

6. The static cache would be cleared only when the batch stage is changed .A new field CLEAR.STATIC.CACHE has been introduced in
BATCH. Setting this field to ‘YES’ would reset the static cache for each job in that Batch.

Close Of Business - User Guide - Release R15.000 - Page 5 of 13

 TSA.PARAMETER

Stoppage Time : Repeated time period for which the TSM would monitor crashes on a service.

Stop Count : Maximum number of crashes allowed for a service with in the specific stoppage time.

Close Of Business - User Guide - Release R15.000 - Page 6 of 13

 BATCH

Clear.Static.Cache: This field signifies whether to clear the static cache while processing each job in a batch process

Start COB with Users Signed On

Non Stop Processing and Close of Business complement each other. Close of Business disallow input and processing of records in all applic-
ations other than one supported by Non-Stop 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 pro-
cessing 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 pro-
cessing happens based on the COB record in DATES and online processing happens with the cycled record in DATES application.

Close Of Business - User Guide - Release R15.000 - Page 7 of 13

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 star-
ted, then it needs to be started before the COB is initiated.

Starting the Temenos Service Manager

Close Of Business - User Guide - Release R15.000 - Page 8 of 13

 Invoking the Temenos Service Manager

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 Desktop sessions which were used to run the job in 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.

COB besides running as a manual service can be activated on specified date/time/frequency like online services, based on the settings in the
FREQUENCY field in TSA.SERVICE application.

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.

Close Of Business - User Guide - Release R15.000 - Page 9 of 13

 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/company group

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.

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 availability. The other agents processing the same job 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. To define it further, a session starts processing the
job by determining the available list file and populates the data to process in the list file. This session along with the other free sessions now
share the load on the list file and process the job.

TRANSACTION MANAGEMENT

The jobs run as a part of Close of Business are wrapped under transaction management. Transaction Management covers the population of the
list file, the processing of the records in the list file as well as updates the LOCKING/BATCH.STATUS and BATCH files. This ensures com-
plete re-run ability of the process and ability to skip through errors. Partial updates are avoided. Transaction Management is not available for
reporting jobs. Transaction Management for the batch processing is wrapped around a single T24 transaction.

COMO
Since the introduction of multi threaded architecture, the COMO will be written with the session no to distinguish processing between dif-
ferent threads. The COMO will be written with the key as tSA_<agent no>_datetime. The COMO will contain information on the jobs pro-
cessed with the complete run time information.

Close Of Business - User Guide - Release R15.000 - Page 10 of 13

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 indi-
vidual 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 determ-
ine the destination printer, user addressing, number of copies etc. The following applications are used in this process:

Application Description

SPOOL.BATCH.OUTPUT Prints or reprints all output for a specific batch run

SPF Specifies that no printing should take place until all processes have completed

HOLD.CONTROL Stores detail of all output produced

PRINTER.ID Specifies the printers available to the system

USER Defining the reports an individual should receive & where

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 sys-
tem 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.

EB.EOD.ERROR
l Contains one record per company per COB execution date.
l All errors encountered during COB on a specific day are multivalued and stored in a single record in this file.
l The id to a record in EB.EOD.ERROR is <company.code>.<date> For e.g., - GB0010001.20100120

EB.EOD.ERROR.DETAIL
l Every error in EB.EOD.ERROR has a Detail Key populated against it which is ID to EB.EOD.ERROR.DETAIL
l The details of every error raised can be viewed in this file.

COB cannot run the next day without resolving errors encountered during the previous run.

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.

Close Of Business - User Guide - Release R15.000 - Page 11 of 13

Jobs can abort for a variety of reasons, both system and application orientated

Any system related crashes will be sensed by the Temenos Service Manager and the dead agent will be started again. The Temenos Service Man-
ager 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 ensur-
ing 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.

Again locking clashes time out after a minute thus ensuring that agents don’t wait endlessly on a lock. Also this avoids the possibility of dead-
locks on the system.

EB.EOD.ERROR Record

TAFC Log
l Setting the field REPORT.CORE.DUMP in SPF to ‘Y’ will invoke the JBASECOREDUMP function on fatal error. This function writes
the core dump contents onto the centralized TAFC log with a unique ID.

Close Of Business - User Guide - Release R15.000 - Page 12 of 13

l The core dump provides the call stack information which is helpful for analysis.

Console output of tSA

Close Of Business - User Guide - Release R15.000 - Page 13 of 13