CLOSE OF BUSINESS

DateOf Issue Version Changes By

th
30 July 2004 1.0 Initial Alagammai
Palaniappan

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Close Of Business - COB

Table of Content
Table of Content ................................................................................................................................... 2
Close Of Business – An Introduction .................................................................................................... 3
COB – Stages....................................................................................................................................... 3
BATCH Application – An Overview ....................................................................................................... 5
Fields In The Batch Application ......................................................................................................... 7
Date Change - In COB........................................................................................................................ 12
1st Date Change .............................................................................................................................. 12
2nd Date Change ............................................................................................................................. 12
tSM And tSA – An Overview ............................................................................................................... 13
COB configuration........................................................................................................................... 14
TSA.SERVICE............................................................................................................................. 14
TSA.WORKLOAD.PROFILE........................................................................................................ 15
TSA.PARAMETER ...................................................................................................................... 16
TSA.STATUS .............................................................................................................................. 17
Initiating COB Using tSM And tSA................................................................................................... 17
Stopping tSA and tSM ................................................................................................................. 20
Execution Of Jobs In COB – Overview ............................................................................................... 20

TEMENOS Training Publications Page 2 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Close Of Business – An Introduction

In the traditional End Of Day mechanism, in order to execute the End Of Day process, we would first
take a backup of the system, then execute the various End Of day jobs defined in the BATCH
application and once all the jobs complete successfully, a post End Of Day backup would be taken
and only after this the system will return to its ‘ONLINE’ stage. It is only from this point will the users
will be able to input transactions. If any one of the End Of Day jobs fail, then the entire process would
stop.

To reflect the fact that the system is now always available there is now no concept of an end of day,
i.e. a period where the system is not available to users. Instead there is a close of business process
that runs when the bank wishes to close the bank’s books for the day. The tasks performed should be
viewed as automated transactions running in a particular order whilst other work on the system takes
place. The end of day or batch process is now referred to as Close of Business or COB.

Please note, only of the product NS is installed, the system will be available for input even while COB
is running.

COB – Stages
During the COB number of routines get executed. These routines need t get executed in a particular
order. For this purpose, the routines are classified into one of the following sections.
Stage Description of Activities
1- APPLICATION Individual application processes (Forex, Funds Transfer etc.)
2- SYSTEM WIDE System wide processes (Interest & Charges, Revaluation etc.)
3- REPORTING Main system reports (trial balance, general ledgers, transaction journal
etc.)
4- START of DAY Change date (Standing orders, split month end events, cash flow
maintenance etc.)
5- ON-LINE Any non-critical reports and processes, which need to be run after the
system has returned to on-line mode. (This stage is available only form
T24 release 14)

TEMENOS Training Publications Page 3 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

The following diagram gives a high level overview of the activities that take place during COB.

Initiate COB

System mode changed

to B(atch)

Execution of jobs in
A-S-R-D order

System mode changed

back to O(nline)

Execution of jobs in
O(nline) stage

An important point here is that, in COB, unlike EOD, back procedures are not part of the COB process.

TEMENOS Training Publications Page 4 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

BATCH Application – An Overview

As we had discussed earlier, there are number of routines that get executed as a part of the COB
process in T24. These routines need to be defined in the BATCH application if they need to be
executed as a part of the COB process.

For the routines to be part of COB, the need to have an entry in the PGM.FILE with the type set to ‘B’.
Each BATCH record is a process and can contain one or many jobs within it.

Company Mnemonic/Batch Job Name

Batch Stage: Starts with an ‘A’ that denotes that it is
an Application Wide job
Batch Stage: Starts with a ‘D’ that denotes that it is a
Start Of day job

Batch Stage: Starts with a ‘S’ that denotes that it is a

System wide job

Batch Stage : Starts with a ‘R’ that denotes that it is a

Reporting stage job

TEMENOS Training Publications Page 5 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Sample BATCH record in Desktop

TEMENOS Training Publications Page 6 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

In Browser

Fields In The Batch Application

ID The Process name (Company Mnemonic/Process Name)

BATCH.STAGE
This field allows the user to group the processes into four distinct stages which is the first character –
A(pplication), S(ystem), R(eporting) and D(Start of day). Within the batch control system, each stage
verifies that all the processes in the previous stage have completed successfully before continuing.

If no sequence number (process dependency) has been appended to the batch stage, then this
process can be run concurrently within the stage. However if a sequence number (e.g. A009) has
been specified then the process can be run only when all other processes with sequence numbers
lower than this have completed successfully. Processes with the same sequence number can be run
concurrently.

Sequence numbers in the range 000 to 099 should not be modified.

TEMENOS Training Publications Page 7 of 21 July 2003
T2ITT – R05 – 1.0
Close Of Business - COB

Sequence numbers in the range 100 to 899 - only the last two digits should be modified.
Sequence numbers 900 - 999 should not be modified.

Generally the sequential numbers are given in multiples of 10 to enable insertion of process at a later
date. Otherwise, the EOD routine may be attached to the preceding application as a last set of jobs.

DEFAULT.PRINTER
Specifies the default printer and form name to which all output is to be directed for the process.
If no printer name has been specified in field PRINTER.NAME for the individual jobs, then this field
allows the user to define a default printer to direct all output to for the process. If this field is left blank
and no printer has been specified for the individual jobs, then the output is sent to the default SYSTEM
printer defined in DE.FORM.TYPE.

PROCESS.STATUS
Indicates the current process status. Some common status values are:

0 - Ready
1 - Running
2 - Completed successfully
3 - On hold or in error

This is a NOINPUT field.

BATCH.ENVIRONMENT
A foreground process will be run directly on the users terminal, whereas a background process will run
as a phantom task. The background facility allows the user to run a number of processes concurrently
and may be used for the processes that are in the reporting stage.

JOB.NAME
Job name contains the subroutine name that is to be run. The job name entered must be an entry on
the main program file PGM.FILE with the TYPE set to ‘B’. The PGM.FILE record should define the
actual information commands or application routines to be executed as part of the job.

TEMENOS Training Publications Page 8 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

The subroutine has to be defined in the PGM.FILE with type B.

The routines thus attached can be multi threaded or single threaded. If it is a multithreaded routine,
then the field BATCH.JOB can contain ‘’ or @BATCH.JOB.CONTROL. If it is single threaded routie,
then the field contains the BATCH/JOB.

VERIFICATION
The job name entered in field JOB NAME (6) can be made to be dependent on other jobs by
specifying valid job name(s) in this field. The batch control system verifies that all the jobs referenced
here have completed successfully before executing the job specified in field JOB NAME (6).

Note: The job(s) referenced in this field must have entries setup in the main job field JOB NAME (6).
This ensures that the jobs to be verified are all part of the same process.

FREQUENCY
Following are the valid frequencies

D - Every working day.

Dnn - Every nn working day.
W - Weekly every Friday.
M - Last working day of every month.
Mnn - Every nn or previous working day of each month.
A - Ad hoc.
Y - Last working day of the year.
Ynn - Last working day of the nn'th month.
TEMENOS Training Publications Page 9 of 21 July 2003
T2ITT – R05 – 1.0
Close Of Business - COB

NEXT.RUN.DATE
Specifies bank date on which the job is to be next run.
When COB is initiated, all jobs with daily frequency and all jobs with the NEXT.RUN.DATE set to
today’s date are run. Please note that from T24 release 14, daily jobs will not have any value in the
field NEXT.RUN.DATE .

If no date is entered in this field then the next run date is automatically calculated (when the record is
updated) using the FREQUENCY specified and the LAST.RUN.DATE (field maintained by batch
control system). However if no last run date exists (i.e., new job) then the current bank date and
frequency is used to calculate the next run date.

PRINTER.NAME
This field allows the user to control at which printer and form type the output from the specific job is to
appear. It overrides the default process printer specified in field DEFAULT.PRINTER.

DATA
This field should be used to pass any data values that may be required by the job when it is being run.
When specifying data to be used with the routine EOD.REPGEN.PRINT it is possible to define either a
report or an enquiry report to be produced ;

ENQ enquiry.name Specifies an enquiry report

report.name Specifies a report

JOB.STATUS
Indicates the current status of the job. This is a NOINPUT field.Some common status values are:

0 - Ready
1 - Running
2 - Completed successfully
3 - On hold or in error

LAST.RUN.DATE
Indicates the date on which the job was last run.

JOB.MESSAGE
Stores the job error message number.

USER
Specifies the user name whose user profile is loaded when the job is run.This field allows a particular
user environment (i.e company details etc.) to be established for a job when it is run as part of the
batch control system.

TEMENOS Training Publications Page 10 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

The actual user profile (setup in file USER) for the user name entered is used. If no user name is
entered in this field then the default profile for the user OPERATOR is used.

TEMENOS Training Publications Page 11 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Date Change - In COB

There are a number of tasks that get executed as a part of the COB process. The following are the
most crucial ones, as they relate to date change.
Assumption
COB is run for company US0010001 whose mnemonic is BNK.

1st Date Change

The first job to get executed as a part of the COB process is

Batch Process ID : BNK/COB.INITIALISE

Job Name : EB.CYCLE.DATES
Batch Stage : A000

This job will cycle the dates for the online user. The start of the COB is the business cut-off for
processing, any work apart from that in the COB itself after this point is treated as tomorrow’s work.
The system will now maintain 2 DATES records for each company. The record keyed on company
code will be used by any non-COB processing session. A second record with ID ‘company code –
COB’ will be used by the COB process.

Pre Image of the DATES Record :

Company Code Today Next Working Day Last Working Day
US001001 13th July 2004 14th July 2004 12th July 2004

Post Image of the DATES Record

Company Code Today Next Working Day Last Working Day
US0010001 14th July 2004 15th July 2004 13th July 2004
US0010001-COB 13th July 2004 14th July 2004 12th July 2004

The record with ID – Company Code (US0010001) will be used by any online transaction that is input
while COB is in progress. This facility will be possible only when the NS product is installed.

The record with ID – Company Code-COB (US0010001-COB) will be used by all COB routines.

This job also changes the value of the field ‘CO.BATCH.STATUS’ field in the DATES record from ‘O’
to ‘B to denote that the system is in ‘BATCH’ mode. The is the replacement for the ‘OP.MODE’ field in
the SPF.

In stage O000 – RESET.CO.STATUS, the CO.BATCH.STATUS in the DATES record is reset to ‘O’ to
denote that the system is in online mode.

2nd Date Change

The first process in the start of day stage (D) section of the COB will cycle the date for the COB
process only, since the dates have already been cycled for the non-COB sessions. Note that this
process is a financial level process now (i.e. will run in each company) not the INT level it was in
previous releases.

TEMENOS Training Publications Page 12 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Batch Record : BNK/DATE.CHANGE

Job Name : B.DATE.CHANGE
Batch Stage : D000

Pre Image of the DATES Record :

Company Code Today Next Working Day Last Working Day
US0010001 14th July 2004 15th July 2004 13th July 2004
US0010001-COB 13th July 2004 14th July 2004 12th July 2004

Post Image of the DATES Record

Company Code Today Next Working Day Last Working Day
US0010001 14th July 2004 15th July 2004 13th July 2004
US0010001-COB 14th July 2004 15th July 2004 13th July 2004

tSM And tSA – An Overview

The entire COB process is controlled by

tSM : T24 Service Manager

tSA : T24 Service Agent

The tSM as the name implies is the main manager of COB. It is a service that
runs as a background process and its main job is to initiate and monitor tSAs(also background
processes) which will actually be executing the COB. With the installation of T24 we will have 2
services defined for COB purpose namely, TSM and COB. While the TSM service is used for initiating
and monitoring the tSAs as specified earlier, the job of the COB service is to actually execute the COB
jobs using tSAs. Both the tSM and the tSA can be run as fore ground jobs if desired. This is discussed
in detail later in this section

In order to initiate the COB process, the first thing that we need to do is to start the
tSM on each of the T24 servers. Once initiated, the tSM will run in the background and will initiate
agents (tSA) in order to execute the COB service. We can control the number of agents that need to
run in each T24 server. Further, we can increase and decrease the number of agents in a server while
the COB is running and also parameterize the system in such a way that the tSM automatically
increases or decreases the number of agents for specific periods of time. You can compare the tSAs
to the BATCH.SESSIONs that we specify in the SPF. The tSAs are the ones that will actually execute
the COB jobs defined in the BATCH application.

TEMENOS Training Publications Page 13 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

COB configuration

Step 1:

As discussed earlier, both TSM and COB are services. They need to be defined.
Ensure that you have the definition of the above-mentioned 2 services in the file F.TSA.SERVICE.

TSA.SERVICE

This is the file where services need to be defined. The key(ID) to this file is the
service name itself. As a part of the T24 installation, this file will contain 2 records with the following
ids

TSM : Service to run the T24 Service Manager

COB : Service to run the Close Of Business by invoking the jobs specified in the
BATCH application.

File Structure

File Classification : INT File Type : H

Field Name Description

ID (SERVICE) ALPHANUMERIC
XX<SERVER.NAME Name of server to launch tSAs on. Used only for record with ID – COB.
XX>WORKLOAD.PROFILE Profile definition for number of tSAs to dedicate to this service based
on the current time. ID of the TSA.WORKLOAD.PROFILE file.
USER User ID to load when running this service. This is mandatory for
service COB as we require a user record while executing COB jobs.
SERVICE.CONTROL START – indicates service should be started
STOP – indicates the service should be stopped
AUTO – Run continuously. Used only with user defined services
(Discussed in the section ‘Creating user defined services’) and not
available for COB.
REVIEW.TIME The number of seconds after which the tSM will read this profile in
order to dynamically add/remove agents and stop the service.
(Discussed in detail later in this section.)

Sample Records

Field Name Field Value

ID TSM
XX<SERVER.NAME
XX>WORKLOAD.PROFILE ONE
USER
SERVICE.CONTROL START

TEMENOS Training Publications Page 14 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Field Name Field Value

ID COB
XX<SERVER.NAME T24training1
XX>WORKLOAD.PROFILE TWO
XX<SERVER.NAME T24training2
XX>WORKLOAD.PROFILE THREE
USER INPUTTER
SERVICE.CONTROL START

Golden Rules About TSA.SERVICE

1. The SERVICE.CONTROL field in the records TSM and COB have to be set to ‘START’ in
order to start the TSM and COB services and should contain STOP in order to STOP the
services.
2. The USER field in the COB record should contain a valid user id as user information is
required for COB record updates and applying the default account officer / department
codes in processing.

Step 2

In the TSA.SERVICE file, we have defined the ‘WORKLOAD.PROFILE’. The value

that we supply to that field is the ID of the file F.TSA.WORKLOAD.PROFILE.

TSA.WORKLOAD.PROFILE

A workload profile, stored on the table TSA.WORKLOAD.PROFILE, defines the

number of agents which should be launched to support the service. It can either be a fixed number of
agents or it can be based on time – i.e. 2 agents at 09:00, 3 at 10:00 or more likely 10 at 17:00 and 24
at 20:00 to allow online users to share the system with the close of business but at eight o’clock
devoting the whole machine to the COB. If no time is specified then the number of agents will be as
entered, regardless of when the service is launched.

File Classification : INT File Type : H

Field Description
ID Anything
XX<TIME HH:MM
XX-AGENTS.REQUIRED Number of tSAs to dedicate 0-N

This is the value that we specify in

TSA.SERVIE file in field
Sample Records ‘WORKLOAD.PROFILE’

Field Name Field value

ID ONE
XX<TIME
XX-AGENTS.REQUIRED 1

TEMENOS Training Publications Page 15 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Field Name Field Value

ID TWO
XX<TIME 10:00
XX-AGENTS.REQUIRED 2
XX<TIME 12:00
XX-AGENTS.REQUIRED 3

Field Name Field Value

ID THREE
XX<TIME
XX-AGENTS.REQUIRED 3

By using the F.TSA.WORKLOAD.PROFILE, we were able to specify

a. Number of agents required to run a service

b. Number of agents required to be run at specific points in time.

Step 3

We have now defined the services and specified the number of agents required to run
each service.

We know that the number of agents for a service can be dynamically changed
when the COB is running. How does this happen? If this has to happen than the tSM should
constantly keep reading the TSA.WORKLOD.PROFILE and the TSA.SERVICE file to check if the user
has made any changes to it.

We know that the tSM should control all the agents. What happens if an agent dies?
How does the tSM know that an agent has died?

In order to make the above-mentioned possible, a parameter table by name

F.TSA.PARAMETER has been designed. This parameter file enables the tSM to monitor the tSAs at
fixed intervals of time.

TSA.PARAMETER

File Classification : INT File Type : H

Field Description
ID Only SYSTEM
REVIEW.TIME The number of seconds the tSM will sleep before reviewing the TSA.SERVICEs,
TSA.WORKLOAD.PROFILEs and running tSAs (TSA.STATUS) to determine if
more (or less) agents are required. If the REVIEW.TIME field in the
TSA.SERVICE record for a particular service is left bank, then this field’s value
will be defaulted. If left blank, this field defaults to ‘15’ seconds.

DEATH.WATCH Maximum number of seconds allowed for an agent to report to the tSM. If this is
set to 300 then the tSA will assume that an agent has failed if its last contact is
more than five minutes – it will then restart the agent.

HIGHEST.AGENT NOINPUT field. Automatically populated by the tSM depending on the number
of tSAs running at a point in time.

TEMENOS Training Publications Page 16 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Sample Record

Field Field Value

ID SYSTEM
REVIEW.TIME 15
DEATH.WATCH 300
HIGHEST.AGENT 3

Step 4

Now that we have all the tables setup, we also need to know the mechanism to
monitor/know the status of the tSAs and the tSM. The F.TSA.STATUS file will help us do that.
This is the file that the tSM will keep updating in order to show the status of the tSAs.

TSA.STATUS

File Classification : INT File Type : L

Field Description
ID 1–N
SERVER.NAME Server running this tSA
STATUS STOPPED, RUNNING
LAST.CONTACT Date and time of last contact with the tSA.
PID Server O/S process id
SERVICE Current SERVICE being run (ID to TSA.SERVICE)
NEXT.SERVICE The next service as instructed by the tSM (ID to TSA.SERVICE)

Sample Data

Initiating COB Using tSM And tSA

Step 1

To start the tSM, from the jBASE prompt type

jsh…>START.TSM

(OR)

jsh…>START.TSM –DEBUG (Interactive mode or to execute it as a foreground process)

TEMENOS Training Publications Page 17 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

>START.TSM -DEBUG
START.TSM -DEBUG
tSA 1 -DEBUG
COMO tSA_1_1297271750.89 established
19:55:50 07 JUL 2003
Agent 1 started 07 JUL 03 19:55:50
Running on server local
tSM DEBUG
Service Profile TSMÿCOB¤1ÿ2

It is vital to understand that the tSM is itself a background process like the tSA
but the only difference is that it will not execute COB jobs but will monitor tSAs. Therefore, when we
initiate the tSM, it is as good as initiating the first tSA. This tSA is like a master agent and will control
all the other agents. At any point in time, there can be only one tSM running on one T24 server
but we can have as many numbers of tSAs as required. Therefore, WORKLOAD.PROFILE
record used by the TSM service should never contain more than one agent.

Once the tSM is initiated, the first thing that the tSM will do is to start the required
number of agents for the service COB. The ‘COB’ service will always have specific number of agents
associated with it. Each of the tSAs internally will call the S.JOB.RUN program to actually start the
COB process.

Step 2

If you choose to run the tSM in interactive mode as specified earlier, then the tSAs will
not be started automatically. tSM will prompt you to start the tSAs manually.

Execute the following command from the jBASE prompt to start the tSA manually

jsh…>tSA <<agent number>>

(OR)

jsh…>tSA <<agent number>> -DEBUG (Interactive Mode – Can view the COMO)

Please note that one should never start tSA 1 as it is the tSM itself.

>tSA 2 -DEBUG
tSA 2 -DEBUG
COMO tSA_2_1297271935.265 established
19:58:55 07 JUL 2003
Agent 2 started 07 JUL 03 19:58:55
Running on server local
Time 19:58:55 SELECT F.COMPANY

TEMENOS Training Publications Page 18 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Now that all the tSAs are up and running, let us understand how they perform the COB. Each of the
tSAs will call the program S.JOB.RUN in order to initiate the COB process. This program in turn calls
the EB.SORT.BATCH subroutine that sorts all the batch jobs in order of BATCH STAGE and gives it
to each tSA in a dynamic array. with the following details

PROCESSNAME_JOBNAME_ROUTINENAME_JOBDATA_COMPANYID_NEXTRUNDATEFM
PROCESSNAME_JOBNAME_ROUTINENAME_JOBDATA_COMPANYID_NEXTRUNDATE….

Sample Data

COB.INITIALISE_EB.CYCLE.DATES_BATCH.JOB.CONTROL_ _GB0010001_20040101

The important point to be noted here is, when the dynamic array is built for every tSA,
EB.SORT.BATCH will randomize batch records with the same batch stage in order for the tSAs to
process those records simultaneously and to avoid locking conflicts.

Assume that there are 4 batch records namely BATCH1, BATCH2 , BATCH3 and
BATCH4, all with the same batch stage A001. When EB.SORT.BATCH builds the dynamic array for
every tSA, it would randomize these records. See sample data below

tSA1 : BATCH2FMBATCH3FMBATCH4FMBATCH1
tSA2 : BATCH1FMBATCH2FMBATCH3FMBATCH4
tSA3 : BATCH4FMBATCH1FMBATCH2FMBATCH3

TEMENOS Training Publications Page 19 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

Stopping tSA and tSM

Once all the COB jobs are complete, the tSAs would automatically stop. If at any
point in time during the execution of the COB, a tSA needs to be stopped, the appropriate
WORKLOAD.PROFILE specified for the COB service needs to be amended. In order to stop the
TSM, the field SERVICE.CONTROL in the TSA.SERVICE file(ID:TSM) should be set to ‘STOP’.
Please ensure that the TSM is stopped only after all the tSAs are stopped.

Execution Of Jobs In COB – Overview

Assumption
1. Single company – US001001 with mnemonic BNK
2. F.BATCH contents
BNK/LD.EOD
Batch Stage : A001
Job Names : Job1 and Job 2
Frequency : D (For both the jobs)
BNK/LC.EOD
Batch Stage : A002
Job Names : Job3 and Job 4
Frequency : D (For both the jobs)
3. Only one tSA to perform COB
Execution of jobs
Now when the tSA that is perform COB is initiated, it will get the following list
JOB1FMJOB2FMJOB3FMJOB4
a. The tSA will first change the PROCESS.STATUS of BATCH record LD.EOD from 0 to 1 to
denote that the batch record is being process

TEMENOS Training Publications Page 20 of 21 July 2003

T2ITT – R05 – 1.0
Close Of Business - COB

b. Then, change the JOB.STATUS of the job JOB1 from 0 to 1 to denote that the job is being
processed
c. Actually process JOB1
d. Once done, change the JOB.STATUS of JOB1 from 1 to 2 to denote that the job has been
completed successfully.
e. Now pickup the next job – JOB2 and change the JOB.STATUS of JOB2 from 0 to 1 to denote
that JOB2 is being processed.
f. Process JOB2
g. Once done, update JOB.STATUS of JOB2 with 2 to denote that the job has been completed
successfully
h. Change the PROCESS.STATUS of the LD.EOD batch record from 1 to 2 to denote that all the
jobs in that process have been completed successfully
i. Proceed with the next BATCH record – LC.EOD
j. Repeat steps ‘a’ to ‘h’ for LC.EOD.

Once all the jobs have been executed, the following single threaded job resets all the BATCH record
with PROCESS.STATUS – 0 and JOB.STATUS – 0 so that they are ready for the next COB. Please
note that, only if the JOB.STATUS is 2, it will get reset to 0.
Batch Record ID : BATCH.DATE.RESET
Batch Stage : O999
Job Name : BATCH.DATE.RESET
This job, apart from resetting the PROCESS.STATUS and JOB.STATUS, also sets the
NEXT.RUN.DATE for the jobs depending on the frequencies. Please note that from T24 release 14,
NEXT.RUN.DATE will not be updated for DAILY jobs. For ADHOC jobs the system has never and will
continue to not set the NEXT.RUN.DATE.

TEMENOS Training Publications Page 21 of 21 July 2003

T2ITT – R05 – 1.0