Upgrading T24

Release: R19 AMR

May 2019

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, for any purpose, without the express written permission
of TEMENOS HEADQUARTERS SA.

© 2019 Temenos Headquarters SA - all rights reserved.

 Upgrading T24

Table of Contents
Introduction 4
Purpose of this Guide 4
Intended Audience 4
Upgrade to a New Release 5
Overview 5
T24 Upgrade 6
T24 Upgrade 19
Post Upgrade Actions 26
Temp.Release with Updates 31
Overview 31
Steps Required 31
Installing a new Product 35
Product Installation 36
Contact your account manager 36
SPF 36
COMPANY 36
T24.UPGRADE Service 37
Installing a new Product 38
Product Installation 39
Contact your account manager 39
SPF 39
COMPANY 39
T24.UPGRADE Service 40
Module Upgrade 41
Auto Upgrade 43
Overview 44
Changes to the Upgrade process 44
Before Upgrading 46
T24.PRE.RELEASE 46
Run Auto Upgrade Service 48
Agent Running - Sample screenshot 50
When and why should Automated Services be Used? 53

2
Upgrading T24

Online Upgrade 55
Overview 55
Pre-Requisite 55
Upgrade Steps 55
Multi-App Server State 72
Restructure Mechanism 74
Upgrade Monitor 95

3
 Upgrading T24

Introduction
Purpose of this Guide
This document describes the T24 Upgrade process. It explains
l How to Upgrade from one release to another
l How to install a temp.release with updates
l How to Install a Product
l How to do a Module upgrade
l How to do an Auto upgrade
l How to do an Online Upgrade

Intended Audience
This user guide is intended for the use of internal Temenos users and clients.

Introduction 4
Upgrading T24

Upgrade to a New Release

Overview
This document explains upgrade of T24 release on TAFC and TAFJ environment with
T24 System in offline mode.
This document explains the procedures for upgrading T24 on jBASE. It should be
noted that some pre-existing knowledge of UNIX and working knowledge of jBASE is
required.

Note: Access to the system through terminal emulator is required for

the execution of the upgrade.

Updates to the T24 system can be a full upgrade, installation of a new product(s) or
one or more interim updates. This section deals with the full release upgrade and
installation of products only. Refer to the Updates section for details of the selection
and installation of interim updates.
Refer to the Auto Upgrades section for information on using the Auto Upgrade fea-
ture

5 Upgrade to a New Release

 Upgrading T24

T24 Upgrade
Extracting temp.release
l The upgrade temp.release will be present in .tar.Z format (for example, tem-
p.release.tar.Z).
l Login as root. Copy upgrade .tar.Z file to required destination directory.
l Untar the '.tar.Z' file. A directory named temp.release gets created in the des-
tination directory.
For TAFC

$uncompress –c temp.release.tar.Z | gtar –xvf -

Extracting temp.release
For TAFJ

Upgrade to a New Release 6

Upgrading T24

Temp Release Pack with Restructure Files

T24 Temp Release package will have this additional file named
REL.<Release>.RESTRUCTURE with reference for restructure definitions list if
Temenos product teams has released it in the corresponding T24 monthly releases,
which will be released to T24 environment during T24.PRE.RELEASE.

7 Upgrade to a New Release

 Upgrading T24

Access rights
Change the access rights to the temp.release directory to allow all access.
chmod –R 777 temp.release

Setting TEMP.RELEASE record

Check that the environment variable JEDIFILENAME_SYSTEM is set.
For TAFC

Add the environment variable to '.profile' file.

export JEDIFILENAME_SYSTEM=$TAFC_HOME/src/SYSTEM.
Run jdiag command from jShell to view the environment variable.

jdiag output
For TAFJ

Open the Configuration properties file (.properties) in 'TAFJ_HOME/conf'. Add a

new property JEDIFILENAME_SYSTEM = SYSTEM.
If the SYSTEM directory is not present, then create the SYSTEM file with type UD
using CREATE.FILE command as below:
jsh -->CREATE.FILE DATA SYSTEM TYPE=UD
Create a record named TEMP.RELEASE inside the SYSTEM file as below, Open the
TEMP.RELEASE from jshell by typing: 
jsh -->JED SYSTEM TEMP.RELEASE

TEMP.RELEASE
The first line of TEMP.RELEASE record should be 'D' and the second line should be
the path for the temp.release directory. 
If the SYSTEM directory is not present, then create the SYSTEM file with type UD
For TAFC

Upgrade to a New Release 8

Upgrading T24

At the jShell prompt àCREATE.FILE DATA SYSTEM TYPE=UD

For TAFJ

JQL-SQL Editor in Eclipse àCREATE-FILE SYSTEM TYPE=UD

Create a record named TEMP.RELEASE inside the SYSTEM file as below
For TAFC

At the jShell prompt àJED SYSTEM TEMP.RELEASE

For TAFJ

JED wizard in Eclipse à

TEMP.RELEASE
TEMP.RELEASE record should have two entries. Line 1 - D and Line 2 - path of the
temp.release directory.

Pre upgrade checks

• Ensure that all other users are logged off the account being upgraded.
• Ensure that '.profile' has been changed according to the release which you are
going to upgrade.
For TAFC

l Ensure that all other users are logged off the account being upgraded.
l Ensure that .profile has been changed according to the release which you are
going to upgrade.
For TAFJ

l Ensure the existing precompiled jar files are present in a single folder. The
precompiled path is specified in .properties file of the TAFJ project
temn.tafj.directory.precompile = D:\Te-
menos\Development\T24\DEV\lib\Precompiled

9 Upgrade to a New Release

 Upgrading T24

T24 Upgrade object code update

From the jshell execute the program T24.BUILD.LIBRARIES from the 't24bin/eb'
upgrade directory found in the temp.release path (as entered earlier in the
TEMP.RELEASE record).
Syntax:
jsh --> <temp.release path> /t24bin/eb_upgrade/ T24.BUILD.LIBRARIES
Example:

T24.BUILD.LIBRARIES
After executing the program T24.BUILD.LIBRARIES logoff and login again. This is
very important as the executable directories have been replaced and any programs
stored in memory need to be released.
If the operating system is WINDOWS then the drive should also be specified while
executing T24.BUILD.LIBRARIES as below:
jsh ->C:\upgrade\temp.release\t24bin\eb_upgrade\T24.BUILD.LIBRARIES

Library Update
This step is done differently for TAFC and TAFJ environments
For TAFC

From the jshell execute the program T24.BUILD.LIBRARIES from the t24bin/eb_
upgrade directory found in the temp.release path (as entered earlier in the
TEMP.RELEASE record).
Syntax:

Upgrade to a New Release 10

Upgrading T24

jsh --> <temp.release path> /t24bin/eb_upgrade/ T24.BUILD.LIBRARIES

Example:

After executing the program T24.BUILD.LIBRARIES logoff and login again. This is
very important as the executable directories have been replaced and any programs
stored in memory need to be released.
If the operating system is WINDOWS then the drive should also be specified while
executing T24.BUILD.LIBRARIES as below:
jsh ->C:\upgrade\temp.release\t24bin\eb_upgrade\T24.BUILD.LIBRARIES
For TAFJ

To start the upgrade process, launch DBtools under TAFJ_HOME/bin

DBtools [options] TEMP-RELEASE <pathToTempRelease> <pathToPre-
compiledDestinationFolder> <-i pathToInsertDestinationFolder> <-bp pathToSr-
cDestinationFolder>
Where options can be
–s (script mode)
-log <log filename> <Log file gets generated under TAFJ_HOME/log )
-cf <Configuration filename>
For example,
DBtools –cf EB.properties –s –log tmprelease TEMP-RELEASE
D:\TAFJDevEnvironment\201215\temp.release
D:\Temenos\Development\T24\DEV\lib\Precompiled –bp

11 Upgrade to a New Release

 Upgrading T24

D:\Temenos\Development\T24\DEV\lib\BP

Note: Set JAVA_HOME, TAFJ_HOME and ECLIPSE_HOME before execut-

ing DBtools.

Check the ‘tmprelease.log’ after completing the ‘DBTools’ command.

Run T24.PRE.RELEASE
Prior to logging back into T24 there is a program to run which performs any pre-
release updates. This program T24.PRE.RELEASE may prompt for user input accord-
ing to any new features in the latest release which require actions to be performed
prior the start of any upgrade.
One of the prompts that will appear is to provide a valid user profile for new ser-
vices being installed.

A valid USER id will be requested

Upgrade to a New Release 12

Upgrading T24

Input a valid USER id in the TAFC/TAFJ console

A wrong USER id will be trapped

Output of T24.PRE.RELEASE in &SAVEDLISTS&

This user will be attached as the user for the upgrade service released as a part of
the T24.PRE.RELEASE. The service records released will be TSM and T24.UPGRADE.
Supplementary records for those services in PGM.FILE, BATCH and
TSA.WORKLOAD.PROFILE will also be released. These records will be released to the

13 Upgrade to a New Release

 Upgrading T24

live file and will be done so only if the record does not exist in the system already.
The service records will be released with the service control set as START so that
the services could be started.
Releasing Restructure definitions:
As part of this pre-release, the required restructure definitions of current upgrade
also released when temp- release package comes with Restructure definitions file.
It releases restructure table records in T24.TABLE.RESTRUCTURE in live with READY
status and it updates list of restructure table names in RESTRUCTURE.TABLES field
in SPF.
Released T24.TABLE.RESTRUCTURE record sample View:

SPF SYSTEM record updated with Restructure table names in RESTRUCTURE.TABLES

field.

Update VOC entries

After T24.PRE.RELEASE, run UpdateMD. UpdateMD will update all VOC entries.

Upgrade to a New Release 14

Upgrading T24

This step is not required for TAFJ Upgrade.

Start the T24 Upgrade Process

The T24.UPGRADE service should be executed at this stage. This release data
records as well as create files as appropriate.

T24.UPGRADE Service
A TSA.SERVICE record for the upgrade is provided as part of the T24.PRE.RELEASE
process; this is called T24.UPGRADE and works in conjunction with the TSM service
manager.
Running the upgrade as a service allows the usage of the multi-threading pro-
cessing during the upgrade; allows the upgrade to be performed via a browser ses-
sion and will form part of the ongoing improvements to the T24 release
mechanisms.
Ensure that the TSA.WORKLOAD.PROFILE records tsm and T24.UPGRADE are author-
ised and then the TSA.SERVICE records (in a single company setup the record will be
called T24.UPGRADE whilst in a multibook setup the record will be prefixed with the
company mnemonic; for example BNK/T24.UPGRADE)
Both the TSM and T24.UPGRADE services should be set to START in the respective
TSA.SERVICE records. 

T24.UPGRADE TSA.SERVICE record

15 Upgrade to a New Release

 Upgrading T24

TSM TSA.SERVICE record

The service manager is activated at the jBase command prompt using the com-
mand START.TSM

Starting the service manager

Once started the service manager will initiate the services marked to run (those
flagged as START) and instead of the information being displayed to the classic
screen display one or more como records will be used to record the output; these
can be viewed later. The progress of services can be monitored from within T24 by
using the TSA.STATUS ENQUIRY provided that it has already been authorised.

Upgrade to a New Release 16

Upgrading T24

Enquiry TSA.STATUS monitoring progress

COMO records created

17 Upgrade to a New Release

 Upgrading T24

One of the COMO records created

Whether you have run the upgrade as a service or manually the next step is to login
and run the conversions for the release you have upgraded to.

Note: This service is restricted to data records and files released as part
of a GA release and do not perform any operation on data records
released as part of ‘Updates’ (applicable for 'temp.release' with
updates). SPF will not be updated with the updates at this point.

Upgrade to a New Release 18

Upgrading T24

T24 Upgrade
Extracting temp.release
l The upgrade temp.release will be present in .tar.Z format (for example, tem-
p.release.tar.Z).
l Login as root. Copy upgrade .tar.Z file to required destination directory.
l Untar the '.tar.Z' file. A directory named temp.release gets created in the des-
tination directory.
For TAFC

$uncompress –c temp.release.tar.Z | gtar –xvf -

Extracting temp.release
For TAFJ

19 Upgrade to a New Release

 Upgrading T24

Temp Release Pack with Restructure Files

T24 Temp Release package will have this additional file named
REL.<Release>.RESTRUCTURE with reference for restructure definitions list if
Temenos product teams has released it in the corresponding T24 monthly releases,
which will be released to T24 environment during T24.PRE.RELEASE.

Upgrade to a New Release 20

Upgrading T24

Access rights
Change the access rights to the temp.release directory to allow all access.
chmod –R 777 temp.release

Setting TEMP.RELEASE record

Check that the environment variable JEDIFILENAME_SYSTEM is set.
For TAFC

Add the environment variable to '.profile' file.

export JEDIFILENAME_SYSTEM=$TAFC_HOME/src/SYSTEM.
Run jdiag command from jShell to view the environment variable.

jdiag output
For TAFJ

Open the Configuration properties file (.properties) in 'TAFJ_HOME/conf'. Add a

new property JEDIFILENAME_SYSTEM = SYSTEM.
If the SYSTEM directory is not present, then create the SYSTEM file with type UD
using CREATE.FILE command as below:
jsh -->CREATE.FILE DATA SYSTEM TYPE=UD
Create a record named TEMP.RELEASE inside the SYSTEM file as below, Open the
TEMP.RELEASE from jshell by typing: 
jsh -->JED SYSTEM TEMP.RELEASE

TEMP.RELEASE
The first line of TEMP.RELEASE record should be 'D' and the second line should be
the path for the temp.release directory. 
If the SYSTEM directory is not present, then create the SYSTEM file with type UD
For TAFC

21 Upgrade to a New Release

 Upgrading T24

At the jShell prompt àCREATE.FILE DATA SYSTEM TYPE=UD

For TAFJ

JQL-SQL Editor in Eclipse àCREATE-FILE SYSTEM TYPE=UD

Create a record named TEMP.RELEASE inside the SYSTEM file as below
For TAFC

At the jShell prompt àJED SYSTEM TEMP.RELEASE

For TAFJ

JED wizard in Eclipse à

TEMP.RELEASE
TEMP.RELEASE record should have two entries. Line 1 - D and Line 2 - path of the
temp.release directory.

Pre upgrade checks

• Ensure that all other users are logged off the account being upgraded.
• Ensure that '.profile' has been changed according to the release which you are
going to upgrade.
For TAFC

l Ensure that all other users are logged off the account being upgraded.
l Ensure that .profile has been changed according to the release which you are
going to upgrade.
For TAFJ

l Ensure the existing precompiled jar files are present in a single folder. The
precompiled path is specified in .properties file of the TAFJ project
temn.tafj.directory.precompile = D:\Te-
menos\Development\T24\DEV\lib\Precompiled

Upgrade to a New Release 22

Upgrading T24

T24 Upgrade object code update

From the jshell execute the program T24.BUILD.LIBRARIES from the 't24bin/eb'
upgrade directory found in the temp.release path (as entered earlier in the
TEMP.RELEASE record).
Syntax:
jsh --> <temp.release path> /t24bin/eb_upgrade/ T24.BUILD.LIBRARIES
Example:

T24.BUILD.LIBRARIES
After executing the program T24.BUILD.LIBRARIES logoff and login again. This is
very important as the executable directories have been replaced and any programs
stored in memory need to be released.
If the operating system is WINDOWS then the drive should also be specified while
executing T24.BUILD.LIBRARIES as below:
jsh ->C:\upgrade\temp.release\t24bin\eb_upgrade\T24.BUILD.LIBRARIES

Library Update
This step is done differently for TAFC and TAFJ environments
For TAFC

From the jshell execute the program T24.BUILD.LIBRARIES from the t24bin/eb_
upgrade directory found in the temp.release path (as entered earlier in the
TEMP.RELEASE record).
Syntax:

23 Upgrade to a New Release

 Upgrading T24

jsh --> <temp.release path> /t24bin/eb_upgrade/ T24.BUILD.LIBRARIES

Example:

After executing the program T24.BUILD.LIBRARIES logoff and login again. This is
very important as the executable directories have been replaced and any programs
stored in memory need to be released.
If the operating system is WINDOWS then the drive should also be specified while
executing T24.BUILD.LIBRARIES as below:
jsh ->C:\upgrade\temp.release\t24bin\eb_upgrade\T24.BUILD.LIBRARIES
For TAFJ

To start the upgrade process, launch DBtools under TAFJ_HOME/bin

DBtools [options] TEMP-RELEASE <pathToTempRelease> <pathToPre-
compiledDestinationFolder> <-i pathToInsertDestinationFolder> <-bp pathToSr-
cDestinationFolder>
Where options can be
–s (script mode)
-log <log filename> <Log file gets generated under TAFJ_HOME/log )
-cf <Configuration filename>
For example,
DBtools –cf EB.properties –s –log tmprelease TEMP-RELEASE
D:\TAFJDevEnvironment\201215\temp.release
D:\Temenos\Development\T24\DEV\lib\Precompiled –bp

Upgrade to a New Release 24

Upgrading T24

D:\Temenos\Development\T24\DEV\lib\BP

Note: Set JAVA_HOME, TAFJ_HOME and ECLIPSE_HOME before execut-

ing DBtools.

Check the ‘tmprelease.log’ after completing the ‘DBTools’ command.

25 Upgrade to a New Release

 Upgrading T24

Post Upgrade Actions

Conversions
When T24 is upgraded there may be conversions to be run if the layouts of files
have changed or if fields that were previously reserved are now to be used. One
record is released for each major release to CONVERSION.PGMS with an id of the
release number, for example, R08. Authorise all unauthorised CONVERSION.PGMS
records. Once the records are all authorised you can begin the conversion process. 

Start the RUN.CONVERSION service

If the TSA.SERVICE record RUN.CONVERSION and its associated
TSA.WORKLOAD.PROFILE record have not been authorised then do so now.
If the service manager is already running in the background then the
RUN.CONVERSION service should be started and the conversion processing will
begin. If the service manager has been stopped then both service will need to be
started and the service manager initialised at the jbase command prompt 

TSA.SERVICE – RUN.CONVERSION

Starting the service manager

Information on the conversion will be written to the &COMO& file and any errors
recorded on the application EB.CONVERSION.EXCEPTION as shown below. 

Upgrade to a New Release 26

Upgrading T24

Exception file - showing conversion errors

The benefit of the service based conversions is that the multi-threaded capabilities
of T24 can be used to reduce the conversion time where applicable.
Please note that the conversion service will also check all the CONVERSION.PGMS
records for any conversions which have yet to be run.

Restructure Capabilities
From R18, there is a facility to enable restructure capability for required product
applications as a replacement for conversion procedure in regular upgrade mech-
anism (offline mode). During T24.PRE.RELEASE, the restructure definition data
items from the temp release package will be released to T24 database and restruc-
ture enabled applications list is also updated in SPF. This is basis for restructure pro-
cess to begin by T24.RESTRUCTURE.SERVICE after T24.UPGRADE service.
To know about the restructure definitions in T24.TABLE.RESTRUCTURE and restruc-
ture process, refer 'Restructure Mechanism' topic in this T24 upgrade user guide.

Authorising Records
Data items are released as part of the T24 upgrade. Some records will be released
directly to the live files (for example, F.PGM.FILE and F.FILE.CONTROL). However,
most records will be released to the unauthorised file and must be authorised
before T24 can be used again.
Ensure that STANDARD.SELECTION records are authorised first.
To see all the files for which there are unauthorised records, run EXCEPTION or
EXCEPTION.PRINT. When records are released as part of the upgrade, as much
information is taken from the live record as possible. For example, when batch
records are released, the last run date, next run date, etc. for each of the batch jobs
is taken from the live record.

Changes in EXCEPTION for TAFJ

27 Upgrade to a New Release

 Upgrading T24

Since the Enquiry EXCEPTION makes use of IDESC USER.REC, make the
following changes for this enquiry to run in TAFJ without the use of
IDESC.
Steps
1. tJed F.ENQUIRY EXCEPTION
2. Replace 3rd field with the following values.
3. Instead of USER.REC EQ 1 replace with USERNO EQ !TNO
4. remove SORT.FLD from 4th field .

Also check your REPGEN files as they may need revalidating after an upgrade.
Care must be taken when authorising records that customer changes are not over-
written by TEMENOS released changes. You need to examine every record to
determine whether the changes should be accepted; whether the unauthorised
record should be deleted and changes applied to the live record; whether the unau-
thorised record should be changed then authorised or whether the unauthorised
record should be deleted. Authorise the records in the following applications first
because of later dependencies: 
l ENQUIRY (any % records)
l EB.PRODUCT
l EB.SYSTEM.ID
l SYSTEM.RECORD
l DE.MESSAGE
l TRANSACTION
l STMT.NARR.FORMAT
Records on VERSION should be authorised last, as they may need values from other
records which have to be authorised.

Upgrade to a New Release 28

Upgrading T24

Auto Authorisation by online service

T24.AUTHORISE service allows the auto authorisation of records released as part
the T24 Upgrade process. The procedure will authorise records in a set order to
cater for those that may reference other new or amended records released at the
same stage.
Where required some records may be still be left in a held status as some manual
intervention may be required.
This is an optional service, if used it will auto authorise the majority of the released
records reducing the user intervention and as such the exception list will be much
smaller. You may, for example, run this in your live area after a successful upgrade
update of your acceptance area where records have been reviewed manually.
If detailed review of each released record is required, then you should not run this
service.
To run the online service, authorise the corresponding BATCH, TSA.SERVICE,
PGM.FILE records of T24.AUTHORISE

TSA.SERVICE record - setup for Auto Authorisation

Also ensure that the OFS.SOURCE record, T24.GENERIC.UPLOAD is present and
authorised.

29 Upgrade to a New Release

 Upgrading T24

OFS.SOURCE record - setup for Auto Authorisation

Upgrade to a New Release 30

Upgrading T24

Temp.Release with Updates

Overview
The purpose of this section is to provide instructions on the additional steps
required when upgrading to the quarterly 'temp.release' of a GAed release
provided by Temenos.

What is the difference?

Upgrading to GA release takes an installation to the base of that particular GA
release. Upgrading to the quarterly release ensures that the upgrade not only
installs the GA release but also all the updates available till that point. Thus the
upgrade takes the Client to a new GA release plus all the available updates till that
point.
Advantages
l No need to manually download and install the updates available
l Automatic process along with the upgrade
l Upgrade project starts with the latest base
l All known fixes available before the testing

What are Updates?

'Updates' is the new release mechanism of maintaining fixes from T24 devel-
opment from R09 onwards. This mechanism is aimed at releasing fixes proactively
to clients at a component level. This new mechanism of Updates replaces the old
mechanism of Patches. This is easier to maintain and will help in encouraging the
clients to take the updates on weekly basis rather than wait for Service Packs.
Service Packs followed the upgrade process where the entire bin and lib were
replaced. The updates will be component specific and have less number of fixes
enabling the clients to take them regularly. Moving forward, the dependency con-
straints would be removed which was a drawback in the patch mechanism.

Temp.Release with updates (Package)

This temp.release package from the Distribution team comes pre-packaged with
set of latest Updates prepared for GA release (since the GA.). This saves enormous
time involved in steps followed to obtain the latest available Updates and install-
ation in bulk. Also, all these Updates which are pre-installed in the GA temp.release
are Regression tested and qualified.

Steps Required
There is no change to the existing 'T24 Upgrade' procedure. All the existing steps of
setting up of the temp.release, Upgrade, Run Conversions, authorizing the

31 Temp.Release with Updates

 Upgrading T24

exceptions are to be followed. A new service T24.UPDATES has to be run after the
T24.UPGRADE service and before running the RUN.CONVERSION service

Running T24.UPDATES Service

This step is required when the upgrade is performed with a temp.release that
includes updates. This concept of temp.release with updates is explained more in
the later part of this document. This step can be skipped if the upgrade is per-
formed with a standard temp.release pack without updates.
Please authorize the following records before running the T24.UPDATES service
record, if they are found in exception. These are required for the running of
T24.UPDATES and hence they are selectively picked up and authorized.
l TheTSA.SERVICE record, T24.UPDATES and its corresponding workload profile
inTSA.WORKLOAD.PROFILE
l The BATCH record, T24.UPDATES
l The STANDARD.SELECTION record, T24.UPDATE.RELEASE
The Service XXX/T24.UPDATES is run to release the data records of the T24 Updates
and complete the updates installation. . The co-responding Batch record
XXX/T24.UPDATES should have T24.UPDATES entered in the DATA field.

BATCH record has DATA field populated

Note: XXX is the Master Company mnemonic for a Multi Company envir-
onment. For a Single Company environment the TSA.SERVICE and BATCH
record would be available without the mnemonic.

SPF before installing updates

Temp.Release with Updates 32

Upgrading T24

Start the service XXX/T24.UPDATES by marking the SERVICE.CONTROL field of

T24.UPDATES Service record to START

Starting T24.UPDATES service

Once the service is complete, please check the field T24.UPDATES in SPF SYSTEM
record. Now the SPF would have been updated with names of all the installed
Updates.

SPF updated
The T24.UPDATES service has to be run before the conversion. This is to ensure that
while running conversion, the correct code and data records are picked up. For
example if one of the updates contained a fix for CONVERSION.DETAILS record, it
will be available un till the T24.UPDATES is run. Hence for running the conversion,
we need to ensure that T24.UPDATES service is run which will transfer all data
items pertaining to updates.
Once the T24 Update is picked up for releasing the Data Record(s) and after releas-
ing them successfully then the co-responding update is marked as Completed by set-
ting the value as 'C' to the DATA.RELEASE field in T24.UPDATE.RELEASE record as
shown.

33 Temp.Release with Updates

 Upgrading T24

Updated T24.UPDATE.RELEASE record

COMO record of this T24.UPDATES service

Note: The temp.release pack with updates cannot be applied on the

same GA release as of the updates. For example, a temp.release pack
with R11 updates cannot be used on a R11GA, it can be used on a
release prior to R11GA.

Temp.Release with Updates 34

Upgrading T24

Installing a new Product

35 Installing a new Product

 Upgrading T24

Product Installation
When you initially purchased T24, you decided which products you wanted on your
system. After using the system for some time, you may decide you would like to
install additional products because you want to automate further parts of the bank’s
processing or because your bank has gained new business.
To familiarise yourself with a new product, you can use the demonstration account
(mbdemo) which has all the products installed. For further information on any
product, contact your account manager.

Contact your account manager

Discuss the product(s) you would like to purchase with your Account Manager who
will be able to give you more information about its functionality and uses. Once you
have agreed to purchase the product, you will be given a product code. 

SPF
Add the new product to the PRODUCTS field on the SPF. In the following field,
PRODUCT.CODES, enter the product code you have been given. Authorise the
record.

Install a new Product ID and Product Code

COMPANY
Add the new product to the APPLICATIONS field on the COMPANY file. When the
upgrade service is running each COMPANY record is checked to see what products
are installed; updates are released for any existing products or when installing a
new product the required files are created and any records for that new product
are released. Most new products will have files created even if no records are
released so updating the COMPANY record(s) is a vital step.

Define product in COMPANY

Product Installation 36
Upgrading T24

Multi-company processing
If you are using multi-company processing and you wish to add a product to a com-
pany, which is already installed in other companies, add the product to the com-
pany record and run upgrade service as detailed below.

T24.UPGRADE Service
The TSA.SERVICE T24.UPGRADE is also used to add new products to T24. Before run-
ning the service the BATCH record associated with the service (for example,
BNK/T24.UPGRADE) needs to have the product code(s) added to the DATA field. It is
recommended that once the product(s) have been installed that the BATCH record
is amended again to clear the DATA field ready for the next upgrade.

DATA field on BATCH record updated with new product codes

Once the BATCH record is authorised the T24.UPGRADE service can be run.
Unless the path of temp.release is changed to run directory, T24 will consider the
process as upgrade. So when running the upgrade service system will throw a fatal
error, stating that product installation and upgrade cannot happen at same time.
Hence ensure that temp.release path is changed to run directory.

Temp.Release pointing to .run

The same post install actions need to be taken as in a full release upgrade. If data
items are released for standard applications (such as VERSION, ENQUIRY and so on)
and these have been enhanced then you may need to run individual
CONVERSION.DETAIL records to bring the data into the current format. An easy
indication of this is the audit fields and the location of the CO.CODE field and the
actual company values.

37 Product Installation
 Upgrading T24

Installing a new Product

Installing a new Product 38

Upgrading T24

Product Installation
When you initially purchased T24, you decided which products you wanted on your
system. After using the system for some time, you may decide you would like to
install additional products because you want to automate further parts of the bank’s
processing or because your bank has gained new business.
To familiarise yourself with a new product, you can use the demonstration account
(mbdemo) which has all the products installed. For further information on any
product, contact your account manager.

Contact your account manager

Discuss the product(s) you would like to purchase with your Account Manager who
will be able to give you more information about its functionality and uses. Once you
have agreed to purchase the product, you will be given a product code. 

SPF
Add the new product to the PRODUCTS field on the SPF. In the following field,
PRODUCT.CODES, enter the product code you have been given. Authorise the
record.

Install a new Product ID and Product Code

COMPANY
Add the new product to the APPLICATIONS field on the COMPANY file. When the
upgrade service is running each COMPANY record is checked to see what products
are installed; updates are released for any existing products or when installing a
new product the required files are created and any records for that new product
are released. Most new products will have files created even if no records are
released so updating the COMPANY record(s) is a vital step.

Define product in COMPANY

39 Product Installation
 Upgrading T24

Multi-company processing
If you are using multi-company processing and you wish to add a product to a com-
pany, which is already installed in other companies, add the product to the com-
pany record and run upgrade service as detailed below.

T24.UPGRADE Service
The TSA.SERVICE T24.UPGRADE is also used to add new products to T24. Before run-
ning the service the BATCH record associated with the service (for example,
BNK/T24.UPGRADE) needs to have the product code(s) added to the DATA field. It is
recommended that once the product(s) have been installed that the BATCH record
is amended again to clear the DATA field ready for the next upgrade.

DATA field on BATCH record updated with new product codes

Once the BATCH record is authorised the T24.UPGRADE service can be run.
Unless the path of temp.release is changed to run directory, T24 will consider the
process as upgrade. So when running the upgrade service system will throw a fatal
error, stating that product installation and upgrade cannot happen at same time.
Hence ensure that temp.release path is changed to run directory.

Temp.Release pointing to .run

The same post install actions need to be taken as in a full release upgrade. If data
items are released for standard applications (such as VERSION, ENQUIRY and so on)
and these have been enhanced then you may need to run individual
CONVERSION.DETAIL records to bring the data into the current format. An easy
indication of this is the audit fields and the location of the CO.CODE field and the
actual company values.

Product Installation 40
Upgrading T24

Module Upgrade
The Module specific upgrade, upgrades an individual module or product from a
major release to another release. Thus, the selected module is at a different
release and the other modules are in the main release.
Follow the below steps to perform a Module Upgrade:
1. Set the SPF (license code for the new product) and EB.PRODUCT, to enable
Module Upgrade. EB.PRODUCT is released by Temenos for the product for
which the Module Upgrade is to be performed.
For example, FA module is used. Core products must not be upgraded
through Module Upgrade.

EB.PRODUCT for FA
2. Set the Temp.Release and run the T24 BUILD LIBRARIES for the FA product.

Temp.Release pointing to .run

3. On completion of the T24 BUILD LIBRARIES, the corresponding product is
updated in the "Data" field of T24.UPGRADE Batch record.

BATCH record
4. Run the T24 Upgrade service, Current and Previous Release fields are
updated in the EB.PRODUCT record for the corresponding product.

41 Module Upgrade
 Upgrading T24

EB.PRODUCT record
5. The "Module Upgrade" field in the SPF record is also updated.

SPF record with "Current Release"

SPF record

Note: Since this a Module specific upgrade, the current release is not
changed in the SPF record.

Module Upgrade 42
Upgrading T24

Auto Upgrade

43 Auto Upgrade
 Upgrading T24

Overview
This is an option to expedite the upgrade process by using an alternate TSA.SERVICE
record from those described in the Upgrade to a New Release user guide. It is
optional and must be activated by setting the AUTO.UPGRADE field in SPF, as shown
in the screen below.

SPF – AUTO.UPGRADE field

Changes to the Upgrade process

If the AUTO.UPGRADE field in SPF is activated, the following changes are effected:
l The T24.PRE.RELEASE routine does not prompts for a USER ID, instead it uses
the pre-existing USER ID set in the TSM record (in TSA.SERVICE).
l New TSA.SERVICE records have the same USER added to the record, so that it
can be Auto Authorised. They are not left in IHLD status for a user to com-
plete and authorise manually.
l The RUN.CONVERSION.PGMS records are released as LIVE records.
l Any CONVERSION.ROUTINE records left unauthorised which are being
replaced are deleted and the new released version is placed in the LIVE file to
avoid conflicts.
l A copy of the records list of items being released is kept intact, so it is pos-
sible to view the list of records selected by the upgrade process even after
the upgrade is completed. The system file F.RELEASED.RECORDS.LIST
provides a key list for any user defined enquiry or investigation reports.
l The multi-job services (such as T24.FULL.UPGRADE) call the standard pro-
cessing stages in sequence, instead of running each separately. The first job
runs the upgrade, the second runs the conversions and the third runs the auto
authorise stage.
l The Auto Authorise only attempts to authorise the records which are in the
release control list. This is different for each user as it depends on the release
being upgraded and is based on the products installed. The records left in

Auto Upgrade 44
Upgrading T24

IHLD status cannot be authorised and the user has to authorise them manu-
ally.
l Logging of the processing and individual stages continue to be written to
&COMO& and to screen, but for auto processing they are also written to the
T24 logging files which can be used by external monitoring software such as
Splunk. This provides the ability for the start and finish stages to be monitored
externally .

45 Auto Upgrade
 Upgrading T24

Before Upgrading
Before any upgrade is started it is important to read through both the Release
Notes and Technical Highlights for the release, as there may be procedures to be
carried out before the upgrade is started.
The Release Highlight, details the changes made in the release should also be read
as it provides information on the scope of the changes to the system in areas which
may be of particular interest to you.

T24.PRE.RELEASE
Run the program T24.PRE.RELEASE which performs any pre-release updates. This
program may be executed at the TAFC shell by typing T24.PRE.RELEASE or at the
TAFJ Command shell by typing tRun T24.PRE.RELEASE.
When Auto Upgrade is selected in SPF,T24.PRE.RELEASE logs into T24 automatically
using the user attached to the upgrade service released as a part of the
T24.PRE.RELEASE. T24.PRE.RELEASE then proceeds to upgrade a set of data records
as shown below

Output of T24.PRE.RELEASE in &SAVEDLISTS&

Auto Upgrade 46
Upgrading T24

The service records released will be TSM and T24.UPGRADE. Supplementary

records for those services in PGM.FILE, BATCH and TSA.WORKLOAD.PROFILE will
also be released. These records will be released to the live file and will be done so
only if the record does not exist in the system already. The service records will be
released with the service control set as START so that the services could be started.

47 Auto Upgrade
 Upgrading T24

Run Auto Upgrade Service

Run one of the TSA.SERVICEs listed below for automated upgrading.

AUTO process TSA.SERVICE records

The BATCH records called are the multi-job ones are listed in the screen below.

AUTO process BATCH records

The batch records contain combination of jobs for Upgrade, Pre-Conversion , Con-
version and Authorisation thereby alleviating the need to run separate services for
each

Two job stages for Model packages

Auto Upgrade 48
Upgrading T24

Two job stages for T24 Updates

Four job stages for T24 Upgrades

49 Auto Upgrade
 Upgrading T24

Agent Running - Sample screenshot

COMO tSA_6_20160412_16-51-29 established Tue Apr 12 16:51:30 IST 2016

<como>

<agent>6</agent>

<processid>171176290</processid>

<portno>4</portno>

Agent 6 started 12 APR 16 16-51-29

Agent's Process id 171176290

<servername>LF3PG152</servername>

Running on server LF3PG152 PortNumber 4

Next Service Current Service

_0__6_12 APR 2016_16:51:30:768_SELECT F.COMPANY WITH

CONSOLIDATION.MARK EQ "N" Selected=8 time=0secs

<service name = BNK/T24.FULL.UPGRADE>

<process name = BNK/T24.FULL.UPGRADE>

<job name = T24.UPGRADE>

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:070_Standard

multi-thread job

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:070_Calling

load routine

JEDIFILENAME_SYSTEM is set to: SYSTEM

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:100_SELECT

F.COMPANY Selected=10 time=0secs

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:100_Starting

job

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:110_Alloc-

ating List File for BNK/T24.FULL.UPGRADE-T24.UPGRADE-1

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:120_Updating

the Locking with BNK/T24.FULL.UPGRADE-T24.UPGRADE-1 and F.JOB.LIST.2

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:130_

Calling..T24.UPGRADE.SELECT

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:130_Control

list..

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:140_Using

list file F.JOB.LIST.2

Auto Upgrade 50
Upgrading T24

_BNK/T24.FULL.UPGRADE_T24.UPGRADE_6_12 APR 2016_16:51:31:140_Control

list processed

</job>

<job name = PRE.RUN.CONVERSION>

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:160_

Standard multi-thread job

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:170_

Calling load routine

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:190_

SELECT F.CONVERSION.PGMS Selected=24 time=0secs

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:210_

Starting job

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:220_

Allocating List File for BNK/T24.FULL.UPGRADE-PRE.RUN.CONVERSION-2

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:220_

Updating the Locking with BNK/T24.FULL.UPGRADE-PRE.RUN.CONVERSION-2
and F.JOB.LIST.2

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:230_

Calling..PRE.RUN.CONVERSION.SELECT

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:230_

List starting from 0 keys processed so far 0

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:240_

Building from list passed

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:31:280_

List starting from 68 keys processed so far 68

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:36:925_

Checking the routines of CONV.EB.UNAUTH.TXN.POSITION in R14

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:36:935_

Checking the routines of CONV.REPO.R14 in R14

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:36:935_

Checking the routines of CONV.DX.ORDER.201307 in R14

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:36:945_

Checking the routines of CONV.DX.TRADE.201307 in R14

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:36:945_

Checking the routines of CONV.FACILITY in R14

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:375_

Checking the routines of CONV.AA.ARR.CHARGE.201405 in R15

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:375_

Checking the routines of CONV.AA.PRD.CAT.CHARGE.201405 in R15

51 Auto Upgrade
 Upgrading T24

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:385_

Checking the routines of CONV.AA.PRD.DES.CHARGE.201405 in R15

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:385_

Checking the routines of CONV.AA.PRD.PRF.CHARGE.201405 in R15

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:395_

Checking the routines of CONV.AA.SIM.CHARGE.201405 in R15

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:37:405_

Checking the routines of CONV.AA.ARR.BALANCE.MAINTENANCE.201403 in R15

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:38:235_

Checking the routines of CONV.USCORE.PARAMETER.201505 in R16

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:38:245_

Checking the routines of CONV.AA.ARR.ACCOUNTING.201505 in R16

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:38:245_

Checking the routines of CONV.AA.PRD.CAT.ACCOUNTING.201505 in R16

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:38:255_

Checking the routines of CONV.AA.PRD.DES.ACCOUNTING.201505 in R16

_BNK/T24.FULL.UPGRADE_PRE.RUN.CONVERSION_6_12 APR 2016_16:51:38:265_

Checking the routines of CONV.AA.PRD.PRF.ACCOUNTING.201505 in R16

</job>

<job name = RUN.CONVERSION>

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:41:615_Stand-

ard multi-thread job

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:41:615_

Calling load routine

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:005_Start-

ing job

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:005_Alloc-

ating List File for BNK/T24.FULL.UPGRADE-RUN.CONVERSION-3

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:005_Updat-

ing the Locking with BNK/T24.FULL.UPGRADE-RUN.CONVERSION-3 and
F.JOB.LIST.2

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:015_

Calling..RUN.CONVERSION.SELECT

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:015_SELECT

F.COMPANY Selected=10 time=0secs

_BNK/T24.FULL.UPGRADE_RUN.CONVERSION_6_12 APR 2016_16:51:42:095_List

starting from 0 keys processed so far 0

....

</job>

Auto Upgrade 52
Upgrading T24

<job name = T24.AUTHORISE>

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:145_Stand-

ard multi-thread job

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:145_Calling

load routine

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:155_SELECT

F.MNEMONIC.COMPANY Selected=10 time=0secs

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:165_Start-

ing job

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:175_Alloc-

ating List File for BNK/T24.FULL.UPGRADE-T24.AUTHORISE-4

_BNK/T24.FULL.UPGRADE_T24.AUTHORISE_6_12 APR 2016_16:51:42:175_Updat-

ing the Locking with BNK/T24.FULL.UPGRADE-T24.AUTHORISE-4 and
F.JOB.LIST.2

</job>

When and why should Automated Services be Used?

Test and Live update
When Upgrading a T24 System the impact and integrity of the Upgrade is an essen-
tial feature which the clients must ensure completes successfully. By running each
Upgrade process individually and manually authoring the released data, the user
can verify the data being released and the effect of any conversions checked for
completeness. In many cases the Upgrade is first made on a copy of the System and
a ‘test’ Upgrade completed - with notes on how the release may impact the System
taken. Later the same full Upgrade process is done on the live System, which needs
the system to be offline for the shortest duration possible.
By using the Auto Upgrade option, the second stage can be completed much faster,
thus reducing the offline durations.

Multi-tenancy
Where a T24 System Operator controls and maintains multiple T24 clients (Multi-
Tenancy) the need for automated processing increases as the offline window
becomes more critical where several T24 systems are being impacted. With the use
of external monitoring and configuration tooling the need to remotely upgrade is
more important. Though the same test or live Upgrade procedures are performed
as for a single T24 instance.

Non-Live systems
Where a System upgrade is non-critical, such as a Demo System. The Auto Upgrade
process can be used as the primary Upgrade method and a test Upgrade may not
be desirable.

53 Auto Upgrade
 Upgrading T24

At the user discretion

If the T24 Client is satisfied with the process and aware of the implications, Auto
Authorisation can be used as the primary Upgrade method. While it uses the same
internal processes to run the Upgrades and Conversions, the addition of the Auto
Authorisation stage may or may not match the control procedures of the user. The
user can activate or deactivate the Auto processing using the value set in the SPF
application.

Auto Upgrade 54
Upgrading T24

Online Upgrade
Overview
This document explains upgrade of T24 System on TAFJ environment. T24 is sup-
ported by ancillary technology products and they together provide an enterprise
banking solution. These products are released on a monthly basis for implementing
clients and an annual release being made available as the go-to-market release.
The clients of T24 continuously upgrade during their initial implementation to make
use of latest software and on a periodical basis once they are in production.
The online upgrade feature facilitates negligible down time during T24 system
upgrade and all ancillary products supporting T24 can continue to function during
online upgrade stage.  Application server(s) will be isolated from production servers
and configured to use only for online upgrade process without interrupting pro-
duction system.

Pre-Requisite
l Minimum T24 Release is R18 and Above
l Target Release is 201810 and Above
l Available only for TAFJ
l Multi-Server Module Mandatory
l Need to upgrade individual App Server(s) one by one.
Isolate one application server as online upgrade server and initiate Upgrade steps.

Upgrade Steps
o TAFJ Upgrade
o T24 Libraries and Binaries Upgrade
o Run T24.INITIATE.UPGRADE
o Configuration in TSM record
o Bring Down Channels and services
o Primary Data Release
o Verification Interval and Bring System Online
o Secondary Data Release

TAFJ Upgrade
This is normal TAFJ upgrade procedure. The TAFJ pack will be in .tar.gz format to be
extracted and before upgrade, set JAVA_HOME. Then execute “Patch_

55 Online Upgrade
 Upgrading T24

TAFJ<Release>.bat” file to upgrade existing TAFJ. The tVersion can be used to con-
firm upgraded TAFJ release. Refer TAFJ document for more details.
This TAFJ upgrade can happen in corresponding application servers and according
to the system stage.

T24 Libraries and Binaries Upgrade

Extract Temp Release
The upgrade temp.release will be in .tar.gz format. Extracted file will be .tar and
then further extraction creates directory of same name, which contains full temp
release pack.

Online Upgrade 56
Upgrading T24

Set TEMP.RELEASE record

Open the Configuration properties file (.properties) in 'TAFJ_HOME/conf'. Add a
new property JEDIFILENAME_SYSTEM = SYSTEM.
If the SYSTEM directory is not present, then create the SYSTEM file with type UD.
JQL-SQL Editor in Eclipse “CREATE-FILE SYSTEM TYPE=UD”
Create a record named TEMP.RELEASE inside the SYSTEM file as below
DBTools JQL Prompt:

TEMP.RELEASE record should have two entries. Line1 - D and Line 2 - path of the
temp.release directory.

Pre-Upgrade checks
Ensure the existing precompiled jar files are present in a single folder. The pre-
compiled path is specified in .properties file of the TAFJ project
temn.tafj.directory.precompile= C:\UTP\R18DEV\Temenos\t24home\default\JARS

Upgrade T24 Binaries and Libraries

To start the T24 Library and Binary upgrade process, launch DBtools under TAFJ_
HOME/bin
Syntax:

Where options can be

–s (script mode)
-log <log filename> <Log file gets generated under TAFJ_HOME/log )
-cf <Configuration filename>
For example,
DBtools –u t24user –p password –cf tafj.properties –s –log tmprelease TEMP-
RELEASE
C:\T24Upgrade\201812.TAFJ201812.1.temp.release\temp.release

57 Online Upgrade
 Upgrading T24

C:\UTP\R18DEV\Temenos\t24home\default\JARS –bp
C:\UTP\R18DEV\Temenos\t24home\default\BP

Check the ‘tmprelease.log’ after completing the ‘DBTools’ command.

The entire F.RELEASE.DATA and F.PGM.DATA.CONTROL from temp release has

been updated into T24 environment as a usual steps in existing upgrade mech-
anism.

Run T24.INITIATE.UPGRADE
It enables online upgrade mode by updating ONLINE.UPGRADE field to YES in SPF
SYSTEM record, which indicates that the system is in online upgrade stage and this
field gets suitable status value in different stages of online upgrade process. The log
file named T24.INITIATE.UPGRADE.log updated under TAFJ_HOME\log_T24\como
can be monitored to know the status from TAFJEE window.

Online Upgrade 58
Upgrading T24

In case of T24 Updates to be installed as part of this online upgrade:

The updater.bat to be executed after T24.INITIATE.UPGRADE step, it will perform
these steps as usual,
l The T24 Jars of the Updates will be unzipped into the updates folder.
l Updates Data Items reference in &SAVEDLISTS& with id format REL.<re-
leaseno>.<updates> files.
l The T24.UPDATE.RELEASE record from the T24 Updates pack will get copied
into the application T24.UPDATE.RELEASE
Note: This updater.bat file refers the online upgrade mode (ONLINE.UPGRADE-
E=YES) then proceeds to release T24 updates pack of upgrading release i.e higher
than current release (i.e R18 in this example).

Configuration in TSM record

Configure the server name(s) in TSA.SERVICE>TSM record as explained below to
allow TSM to launch online upgrade related services in that T24 server.
1. Define ATTRIBUTE.TYPE = ONLINE.UPGRADE.SERVER and corresponding
server name in ATTRIBUTE.VALUE.
o TSM understands these are the only servers can be used for online
upgrade service process and not for any other T24 services.
o Other normal T24 services runs in other (production) server(s) in Multi-
app server setup.
2. Define ATTRIBUTE.TYPE = ALLOW.ALL.SERVICES.STATUS and
ATTRIBUTE.VALUE = READY
o This is optional. And can be set only in case of verification interval is
required in this online upgrade process before system turns from

59 Online Upgrade
 Upgrading T24

offline to online stage, as there are negligible down time allowed after
completion of restructure service or can say before releasing critical
data items into T24 system as Restructure process is optional. The off-
line stage process such as
n Moving restructured data from temporary table(s) into actual
table(s) if restructure process is applicable in this upgrade.
n Releasing primary data items
n Upgrading production server in parallel.
o System can become online only after releasing primary data items and
after certain verification activity is over if this attribute is enabled.
o At that stage, it is required to manually change SPF ONLINE.UPGRADE
field value to READY status, which will guarantee that the system can
become online and services can run in all the servers, which are con-
figured in SERVER.NAME field of TSM record.
o Without this setup, system automatically becomes online after primary
data released as system launches all services in all the servers where
T24.UPGRADE service also one of them to release secondary (non-crit-
ical) data items parallel when online channels are up and running.
It is essential to decide before configuring TSM record for online upgrade
related setups.

Bring down channels And Services

Identify the channels of production system and bring it down which will ensures
new messages are not flowing through channels and all T24 services can also be
stopped gracefully.

Online Upgrade 60
Upgrading T24

Shutdown TSM in phased way across the servers so that the last of transactions are
processed and job list records are empty. This by in turn stops all the services run-
ning in production server. It should not done via SERVICE.CONTROL=STOP in TSM
record of TSA.SERVICE because TSM should be active in online upgrade server. So
the server status in TSM record to be marked INACTIVE for production servers.
Now system turned to offline mode. Can initiate next step to perform necessary off-
line mode activities such as
l Run T24.UPGRADE.PRIMARY service to release primary data records.  (Online
Upgrade server)
l To upgrade production server
For more details, refer corresponding topic section given in page below.

Primary Data Release

In online upgrade mechanism, the data records are released in phased manner.
The critical data items are released as part of this primary data release. T24 Online
Upgrade process understands the list of primary applications and their data needs
to be updated in T24 system before bringing system online. Only those primary
application data alone will be released during this T24.UPGRADE.PRIMARY service.
For example, when temp release has any application layout change as T24 Library
and binaries are already upgraded, and its corresponding dictionary and other
details should be available in system as primary or critical data. Few applications
are identified as primary applications and its data records will be released in this
order,
1. PGM.FILE,
2. FILE.CONTROL,
3. AA.CLASS.TYPE,
4. STANDARD.SELECTION,
5. BATCH.NEW.COMPANY,
6. BATCH,
7. TSA.WORKLOAD.PROFILE,
8. TSA.SERVICE,
9. BP (if any routine in this directory),
10. EB.API,
11. EB.COMPONENT,
12. EB.PRODUCT.
Before running T24.UPGRADE.PRIMARY service, follow these configurations in case
of any T24 products or T24 Updates to be installed as part of this upgrade.
Steps to install T24 products during this primary upgrade service:

61 Online Upgrade
 Upgrading T24

l Setup TSA.SERVICE record T24.UPGRADE.PRIMARY with ATTRIBUTE.TYPE-

E=MODULES and ATTRIBUTE.VALUE=<corresponding T24 Product being
installed>. To include more than one T24 products, this associated multi value
can be expanded.
l Include these T24 products in SPF & COMPANY records as a usual step.
l Upon running the service T24.UPGRADE.PRIMARY, it will release all primary
data items for these T24 products also.

Steps to install T24 Updates during this primary upgrade service:

l Setup TSA.SERVICE record T24.UPGRADE.PRIMARY with ATTRIBUTE.TYPE-
E=UPDATES and ATTRIBUTE.VALUE=YES. This will allow all required T24
updates primary data items being released as part of this primary upgrade.
l T24.UPDATE.RELEASE > DATA.RELEASED field remain ‘N’ as updates install-
ation is not yet over. The secondary data items of this T24 updates being
released as part of T24.UPGRADE service.
Run T24.UPGRADE.PRIMARY
l It Releases all primary data records of this upgrade into T24 System.
l It updates SPF>SYSTEM record with ONLINE.UPGRADE-
E=PRIMARY.DATA.RELEASED and CURRENT.RELEASE=Upgraded Release num-
ber i.e 201812 in this upgrade example.
l T24.AUTHORISE job in same batch process, which authorizes all the primary
data released as part of this upgrade. Then updates SPF>SYSTEM record with
ONLINE.UPGRADE field status to PRIMARY.UPGRADE.COMPLETED and
CACHE.RESET.PERIOD = current UTC time in HH:MM 24hr time format and

Online Upgrade 62
Upgrading T24

then moves this value to LAST.CACHE.RESET.PERIOD. So that when sessions

are re-connected in upgraded server will reset cache only once per session
(not every day) and take latest released primary data for its business. To
know more about cache reset functionality, refer ‘Cache Reset Mechanism’
topic under Application Framework user guide.

T24.UPGRADE job releases all primary data records.

T24.AUTHORISE job authorizes all released primary data records:

63 Online Upgrade
 Upgrading T24

SPF SYSTEM record updated with CURRENT.RELEASE = 201812 and

ONLINE.UPGRADE field value PRIMARY.UPGRADE.COMPLETED. The cache reset
period value updated and then moved to LAST.CACHE.RESET.PERIOD field by
T24.AUTHORISE service because once system become online the re-connected ses-
sions can reset cache only once per session and need not repeat cache reset every
day. The value in LAST.CACHE.RESET.PERIOD helps to reset cache per session only
one time after system becomes online, to refresh primary data.

Online Upgrade 64
Upgrading T24

After completion of this step, TSM running in online upgrade server is waiting to
receive signal whether system became online. In multi-app server setup the servers

65 Online Upgrade
 Upgrading T24

has been arranged as online upgrade server(s) and production server(s), not all ser-
vices can run in all servers during this online upgrade process. But now primary
upgrade is completed and system can become online after manual verification is
done (if required). This will allow all services to run in all active servers in T24 sys-
tem, one of them is T24.UPGRADE service which will continue upgrading T24 sys-
tem by releasing secondary data items (remaining all data items from temp
release).
Parallel to this service, these steps can also happen in production server
n TAFJ Upgrade
n T24 Libraries and Binaries upgrade

Verification Interval and Bring System Online

In case of any manual verification required before bringing system online, this veri-
fication interval can be utilized. This is not a time limit specified somewhere, this is
up to the upgrade admin can decide what level of actions to be carried out during
this interval.
To bring system online, change SPF ONLINE.UPGRADE field to READY status. It was
updated with PRIMARY.UPGRADE.COMPLETED status by T24.PRIMARY.UPGRADE
service, only at this stage this value can be changed to READY, not always.

This ready signal is observed by TSM and it launches all the T24 services auto-
matically as system in online stage. Now in phased manner, up online channels also.
All services can run in all the servers without reverting any change in TSM record of
TSA.SERVICE which has online upgrade server details configured. Because of
ONLINE.UPGRADE status in SPF changed from PRIMARY.UPGRADE.COMPLETED to

Online Upgrade 66
Upgrading T24

READY and will be changing to further status during T24.UPGRADE service, this
won’t create any impact to TSM process for launching all services in all the servers.

Online transactions started flowing into T24 system.

Secondary Data Release

The T24.UPGRADE service will release all the remaining (non-critical) data items
into upgrading environment as a regular process during upgrade except primary
data list. This service can run in all the servers as system is in online stage now.

67 Online Upgrade
 Upgrading T24

Before running T24.UPGRADE service, follow these configurations in case of any

T24 products and T24 Updates installation to continue as part of this upgrade ser-
vice to release its remaining data items. If this installation was enabled in
T24.UPGRADE.PRIMARY then remaining data items to be released as part of this
secondary upgrade service.
Steps to install T24 products as part of this secondary upgrade service:
l Setup TSA.SERVICE record T24.UPGRADE with ATTRIBUTE.TYPE=MODULES
and ATTRIBUTE.VALUE=<corresponding T24 Product being installed>. To
include more than one T24 products, this associated multi value can be expan-
ded.
l Upon running the service T24.UPGRADE, it will release secondary data items
of these T24 products also.

Steps to install T24 updates as part of this secondary upgrade service:

l Setup TSA.SERVICE>T24.UPGRADE record with ATTRIBUTE.TYPE=UPDATES
and ATTRIBUTE.VALUE=YES. This will allow all required T24 updates sec-
ondary data items being released as part of this T24.UPGRADE service.
l Then T24.UPDATE.RELEASE>DATA.RELEASED field will be marked to ‘C’ as
updates installation completed.
l The SPF> T24.UPDATES field will be updated with list of T24 updates installed
as part of this upgrade process.
Run T24.UPGRADE service:
It releases all the remaining (secondary) data items for this upgrade. And then it
Updates ONLINE.UPGRADE = ALL.DATA.RELEASED in SPF SYSTEM record.

Online Upgrade 68
Upgrading T24

Run T24.AUTHORISE service:

l Authorizes all data released during T24.UPGRADE service.
l Sets CACHE.RESET.PERIOD with current UTC time in HH:MM 24hr time
format.
Then it will move this value to LAST.CACHE.RESET.PERIOD so that already running
sessions will reset cache once per session (not every day) and refresh with latest
data released during this upgrade.
l Clears SPF ONLINE.UPGRADE field as online upgrade stage is completing now
with this last step.

69 Online Upgrade
 Upgrading T24

The already running sessions does Cache Reset on its next request and refreshed
with released data items in upgrade without disturbing production system.

Online Upgrade 70
Upgrading T24

T24 Log shows Cache reset log message:

To know more about cache reset feature, refer ‘Cache Reset Mechanism’ topic
under Application Framework user guide.
Now Upgrade has been completed and sessions also done cache reset to refresh
with latest data released during this upgrade process.

71 Online Upgrade
 Upgrading T24

Multi-App Server State

The usual pre-steps such as setting up TEMP.RELEASE path, environment variables
all similar but in case temp release pack comes with new set of REL files when
restructure capabilities enabled for certain T24 tables in required monthly builds.
Initiating upgrade stage will enable online upgrade mode in T24 System and
releases restructure definitions (if any) of corresponding monthly builds for this
upgrade, then restructure process applies on those application’s existing data in
database and online transaction data which reference comes through feeder queue.
Finally, Restructured data stored in temporary table space when T24 system is in
online upgrade stage.
This diagram explains how online upgrade happens when restructure definitions
are part of temp release pack.

Negligible downtime is required for Renaming restructured table into actual table
name and releasing primary data records.

And upgrading production server can happen in parallel.

Online Upgrade 72
Upgrading T24

After this, channels and services can be up and running. Possible to bring more
application servers online then start injecting additional data. System enables cache
reset for already connected sessions to refresh additionally injected data without
affecting its production or business.

These are the steps can be followed for upgrade in Multi-App server.

System Online:
Steps in online upgrade server;
o TAFJ Upgrade
o T24 Libraries and Binaries Upgrade
o Run T24.INITIATE.UPGRADE

73 Online Upgrade
 Upgrading T24

Production Server;
o Online Transactions updates Feeder Queue
Steps in Online upgrade Server;
o Configure Online Upgrade Server(s) in TSM
o Configure Verification Interval option in TSM
o Run T24.RESTRUCTURE.SERVICE

System Offline:
Steps in Production Server;
o Bring down Channels and Services
n This ensures no message inflow
n No Feeder queue update
o TAFJ Upgrade
o T24 Libraries and Binaries Upgrade
Steps in Online upgrade server;
o Rename Restructure Table name into actual table name
o Primary Data Release
o Verification Interval and Bring system online

System Online:
Steps in All servers (Upgrade completion stage);
o Secondary Data Release
o Authorization of Released Data

Restructure Mechanism
This is replacement of previous conversion process from R18.
This mechanism required to restructure existing data items according to the restruc-
ture definitions released by product teams. Mostly T24 comes with product solu-
tions than restructure definitions, so this is not widely used. If Temp release pack
comes with restructure definition then this service will take care of processing it.
There is no more RUN.CONVERSION process in T24 from R18 release.
In Regular Upgrade workflow (Offline Upgrade):
This is major step in the T24 regular upgrade mechanism, and this is one of the
main reason for down time because it ensures that the database gets adjusted to
suit the new upgraded release of T24 products software and still T24 is backward
compatible, also typical conversions were always for field layout adjustments and
remaining conversions helped in converting existing data records to suit the new

Online Upgrade 74
Upgrading T24

software. In this workflow, the Restructure process can happen after T24.UPGRADE
service as a replacement of RUN.CONVERSION service, because
CONVERSION.DETAILS are stopped from R18. The clients who is upgrading from
very lower release to R19 can still run both RUN.CONVERSION and Restructure ser-
vice after T24.UPGRADE service. Adding new field to an existing application not
require restructure definitions. Regarding, How to add an new field to an existing
application, refer the ‘Neighbour Feature’ User guide under Application Framework
and Developer’s guide to know programming standard , do’s and Don’ts about this
neighbor feature.
In Online Upgrade workflow:
In Online Upgrade workflow, Restructure process is the alternate provision to avoid
system down time for such conversions. It happens after T24.INITIATE.UPGRADE is
over and before T24 upgrade services starts i.e system is online stage so restructure
happens on temporary table space, not on actual tables. Regarding, How to add an
new field to an existing application, refer the ‘Neighbour Feature’ User guide under
Application Framework and Developer’s guide to know programming standard ,
do’s and Don’ts about this neighbor feature.
What is Restructure Mechanism?
l A limited framework available to convert records specific to actions and cri-
teria defined.
l A Method of bringing data from old release format to upgraded release
format
l Only data values are changed.
l Position remains same.
l Might also involve changing key of the record
l Can result in splitting of the record in same table
l Can also result in removing few records.
These are the actions can be applied based on criteria defined.
l Also can change configuration file into financial file.
Advantages:
l Ensures do not end up processing millions of live and history records
l Does restructuring of data items in a temporary table space without dis-
turbing live production system.
l Helps to facilitates Shorter upgrade period.
Limitations:
l Applicable for the data in live file by default
l Applicable for history file data ($HIS) if INCLUDE.HISTORY enabled in cor-
responding restructure definition record in T24.TABLE.RESTRUCTURE.

75 Online Upgrade
 Upgrading T24

l Unauthorized file ($NAU) is not focused as part of restructure process, expect-

ation is every unauthorized data should be handled before starts upgrade pro-
cess or user need to authorizes them after the upgrade process is over, then
application routine should have the intelligence to accept with new values or
reject it.
l $DEL file data restructure is not in focus as it is not part of business and also
the deleted image can be retained as it is.

Restructure Operations
These are 5 different restructure operations are supported.

Restructure Purpose Scenario

Operations
Clearing or A field value may needs to be cleared, A particular field in a
changing an additional value needs to be pop- table needs to be
value of a ulated, or existing value to be amended updated with TODAY in
Field for that field. This value can be either cal- higher release.
culated one or a constant. This can hap-
pen criteria basis.
Modify the The key of an existing data records in a Products wants to
Reference table can be changed. This is mostly change the ID of an
done to avoid performance issues. This existing entries of a
needs to be done through a user exit. table to have session
number at the end to
avoid locking con-
tention.
Splitting the A set of fields can be cleared and moved Product wants to
record to another record in same table with dif- extract certain multi
ferent ID. This needs to be done through value sets from a
a user exit. record in a table to new
record with different ID.
Obsolete of Remove the records from the table that Temenos wants to
data matches criteria. remove set of BATCH
records records which are no
(Removal) longer required in
higher release
Changing a A table sometimes changes level. This An INT type table can
File Level means physically we create multiple be re-classified as FIN
tables and move the records to new set to support multi com-
of tables. pany requirements.

T24.TABLE.RESTRUCTURE:

Online Upgrade 76
Upgrading T24

This is the new replacement to the CONVERSION.DETAILS table. The

T24.TABLE.RESTRUCTURE data records are called as restructure definitions and it is
used by restructure services to perform restructure operations on existing data
records of applications, which are enabled for this restructure capabilities. And new
online transaction records created in production system will be updated to feeder
queue and picked up by restructure feeder service to process according to this
restructure definition. The T24.RESTRUCTURE.SERVICE launches
T24.RESTRUCUTRE.FEEDER as AUTO service if online upgrade mode enabled.
Restructure definitions released during T24.INITIATE.UPGRADE if temp release has
REL.[Release].RESTRUCTURE file.
ID Format:   [Table Name]-[Release Number]
Where,
Table name – should have entry in PGM.FILE
Release number should be of 20’4N’ or R’2N’ pattern.
Allowed Restructure Operations are,
1. FIELD.AMENDMENT
2. MODIFY.KEY
3. SPLIT.RECORD
4. OBSOLETE.DATA.RECORDS
5. MODIFY.FILE.LEVEL
Only one action can be allowed per restructure definition record.
1. FIELD.AMENDMENT:
This action denotes product wants to change field value in certain data
records of a table to either constant or through a user exit to frame value or
clear value.
2. MODIFY.KEY:
This action denotes that product wants to modify the ID of certain data
records in a table.
ID can be a constant or framed through a user exit defined in
TARGET.RECORD.KEY field of
T24.TABLE.RESTRUCUTRE.
3. SPLIT.RECORD:
This action denotes product wants to split the existing record(s) into two
records with different ID.
New record and its ID can be framed through a user exit defined in
TARGET.RECORD.KEY field of T24.TABLE.RESTRUCTURE.
4. OBSOLETE.DATA.RECORDS:

77 Online Upgrade
 Upgrading T24

This action denotes that product wants to make certain data items of a table
as obsolete from specific T24 monthly release.
5. MODIFY.FILE.LEVEL:
This action allows re-classifying a file from INT level to FIN level. All the data
items from
F.[Table name] will be moved to master company file during restructure pro-
cess.

Changing Value of a Field:

This is most widely used option where an existing field value can be changed. This is
used to update values to fix bugs some times and it uses criteria to identify the
record(s) and then updates the value.
l Option to be chosen is FIELD.AMENDMENT
l FIELD.NAME is mandatory and can be of any type.
l FIELD.NAME should be valid field name in that table STANDARD.SELECTION
record.
l Local reference field also allowed with exact name.
l FIELD.VALUE can be null or any constant or valid system variables or a
routine which should have entry in EB.API and routine name should be RSTR.
[Table name].[any name]. Where, Table name should be similar to the first
component in ID part.
Routine arguments are,
Argument1 [IN] – Current record
Argument2 [IN] – Current record id
Argument3 [OUT] – Expected field value.
l If FIELD.VALUE left blank will nullify the field value in that record.
l CRITERIA can be optional. No criteria given then restructure service will apply
this restructure definition for all data items of that table.

Online Upgrade 78
Upgrading T24

Modifying the Reference:

There are few situations where an existing record ID needs to be changed. This is
mostly required to solve performance issues with scalability of the current record
ID. In such cases, a restructure can happen on existing record keys.
l New ID will be decided based on the TARGET.RECORD.KEY field which can be
either constant or hook routine of name RSTR.[Table name].[any name] ,
where Table name is similar to the first component of ID part and routine
should have entry in EB.API.
l ID will be retried from this routine during restructure service process.
Routine arguments are,
Argument 1 [IN] – Application name.
Argument 2 [IN] – Current Data record
Argument 3 [IN/OUT] – current record id being changed to target ID and
returned to restructure service for further process. This target id can also be
framed from few field values of current data record comes in second argu-
ment.
l ID of a table data items can be modified using this restructure definition.

79 Online Upgrade
 Upgrading T24

l CRITERIA can be defined if required to apply this only to certain list of data
items.

Splitting the Record:

This option can be chosen when a given record is to be split into two different
record in same table. This option is rarely used but can be an option where the cur-
rent record cannot be handled in the new release. There is no such option in
CONVERSION.DETAILS functionality.
l Option to be chosen is SPLIT.RECORD
l TARGET.RECORD.KEY is mandatory with hook routine of naming convention
RSTR.[Table Name].[any name]
l New record ID will be decided based on this hook routine and it should have
entry in EB.API.
l This routine should take care of returning target record and its ID.
Routine arguments are,
Argument1 [IN] – application name
Argument2 [IN/OUT] – current data record being restructured, split field val-
ues may be cleared from current record.
Argument 3 [IN] – ID of current record
Argument 4 [OUT] – target record after split
Argument 5 [OUT] – target record id , i.e new record id

Online Upgrade 80
Upgrading T24

Removing Data Records:

This option is mostly used when the records are invalid at the new release level. A
set of records can be removed based on criteria defined. Multiple criteria can be
specified in sub value field CRITERIA.
l Option to be chosen is OBSOLETE.DATA.RECORDS
l Deletion of data items can be defined here with either CRITERIA or list of IDs
in FIELD.VALUE.
l Either CRITERIA or FIELD.VALUE required. Not both.

Modifying File Level:

In few occasions, an existing level of table is changed. This is done to enhance
multi-company support and in such cases, an existing table needs to be changed to
financial level physical table. Restructure allows providing such facility currently
through this MODIFY.FILE.LEVEL option.
l Only INT file can be re-classified to FIN level
l @ID given with other type of file will raise error.
l FIELD.VALUE is defaulted to FIN if left blank.

Pre-Requisite
1. T24 Release package should have this additional file and reference for
restructure definitions list.

81 Online Upgrade
 Upgrading T24

2. Run TEMP-RELEASE TAFJ Utility

As part of upgrade procedure, it will move all temp release items into
F.RELEASE.DATA as an existing functionality.
3. T24.INITIATE.UPGRADE:
Upon running T24.INITIATE.UPGRADE, it will release restructure definitions
records from Temp release into T24.TABLE.RESTRUCTURE as a pre-release of
data items for restructure service process. It releases current upgrade
related restructure table definitions in live with READY status. Also, it updates
list of restructure table names in RESTRUCTURE.TABLES field in SPF (apart
from updating ONLINE.UPGRADE =YES ) as restructure process is based on
the list of table names in this field and restructure definitions exist in
T24.TABLE.RESTRUCTURE with READY status.

Online Upgrade 82
Upgrading T24

In case of there is no restructure definitions in temp release pack then the

field RESTRUCTURE.TABLES will not have any value then there is no need to
run restructure service also.
Released T24.TABLE.RESTRUCTURE record List:

Table Restructure Definitions View:

83 Online Upgrade
 Upgrading T24

Restructure Service Process

In Regular Upgrade Workflow:
For regular upgrade, mechanism the workflow is different as restructure definitions
will be released during T24.PRE.RELEASE and restructure service to be run after
T24.UPGRADE service as replacement of RUN.CONVERSION service.

Online Upgrade 84
Upgrading T24

l According to RESTRUCTURE.TABLES list from SPF, this service starts restruc-

ture process for the restructure definitions which are in READY status in
T24.TABLE.RESTRUCTURE.
l The organized restructure definitions are used to perform  restructure action
which is being applied one by one on each selected record as release wise
then write only once per record.
l Also for audit purpose, it appends restructure definition ID to the INPUTTER
field value in Audit section of Restructured data.
l Restructured data stored in actual table as system is offline stage.
l After every table’s physical file data restructure process is over, it updates
COMPLETED status in corresponding restructure definition data records. This
status update is once per table name but for all of it’s restructure definitions
which was part of this process.
l Release wise restructure is achieved with reasonable I/O.
l No performance Impact due to this process.
In Online Upgrade Workflow:
I. T24.RESTRUCTURE.SERVICE
This service needs to be run after T24.INITIATE.UPGRADE step and before T24
Upgrade services; i.e production is still running as system is in online stage.
1. According to RESTRUCTURE.TABLES list from SPF, this service plan
restructure process for the restructure definitions, which are in READY
status.
2. And creates temporary table space for restructure enabled table
names.
Temporary table naming convention:
F.[Mne].[Table name].[Upgrading Release]
Where, Upgrading release identified from temp release REL.[Release]
files.
3. It initiates T24.RESTRUCTURE.FEEDER service with AUTO in
SERVICE.CONTROL field. This is feeder queue
(F.T24.TABLE.RESTRUCTURE.LIST) based restructure service happens
parallel to legacy restructure (T24.RESTRUCTURE.SERVICE), both refers
same restructure definitions from T24.TABLE.RESTRUCTURE but
T24.RESTRUCTURE.FEEDER service converts based on transaction ref-
erence from feeder queue F.T24.TABLE.RESTRUCTURE.LIST only.
4. The organized restructure definitions used to perform  restructure
action which is being applied one by one on each selected record as
release wise then write only once per record.

85 Online Upgrade
 Upgrading T24

5. Restructured data stored in temporary table space and not on actual

table as system is in online stage and it should not disturb production
system.
6. Also for audit purpose, it appends restructure definition ID to the
INPUTTER field value in Audit section of Restructured data.
7. The data items that are identified to be obsolete are not written to tem-
porary table name, as this data item is no longer required for T24
product to function.
8. After every table’s physical file data restructure process is over, it
updates COMPLETED status in corresponding restructure definition
data records. This status update is once per table name but for all of
it’s restructure definitions which was part of this process.
9. Release wise restructure is achieved with reasonable I/O.
10. No performance Impact due to this process.
II. Online Transactions in Production Server updates Feeder Queue
Once system enabled for ONLINE.UPGRADE mode in SPF and
RESTRUCTURE.TABLES also updated, the online transactions processed in pro-
duction server will update feeder queue F.T24.TABLE.RESTRUCTURE.LIST. The
successful transactions of applications listed in RESTRUCTURE.TABLES field of
SPF only reaches feeder queue.
Processed a Funds Transfer in production server, which updates transaction
reference, and other details in this feeder queue for restructure feeder ser-
vice to pick up and process as per FUNDS.TRANSFER’s restructure definitions.

III. T24.RESTRUCTURE.FEEDER Service:

1. This is an AUTO service being initiated by T24.RESTRUCTURE.SERVICE,
which runs only during online upgrade process.
2. .LOAD routine,
l Prepares list of tables and its restructure definitions, which are
part of this current upgrade.
l That is, the restructure definitions which are of greater release
than SPF>CURRENT.RELEAESE and less than or equal to

Online Upgrade 86
Upgrading T24

Upgrading release are considered for restructuring. Upgrading

release identified from temp release REL.[Release] files.
l This service not depends on READY status of restructure defin-
itions in T24.TABLE.RESTRUCTURE because once legacy restruc-
ture is over, the T24.RESTRUCTURE.SERVICE marks
RESTRUCTURE.STATUS=COMPLETED. But
T24.RESTRUCTURE.FEEDER service should continue running until
upgrade user manually stops this service by setting
SERVICE.CONTROL = STOP in its TSA.SERVICE record.
3. It picks up entries from F.T24.TABLE.RESTRUCTURE.LIST feeder queue.
4. This feeder queue getting entry for every successful online transactions
of applications, which are enabled for, restructure process i.e after
T24.INITIATE.UPGRADE. Now this feeder based restructure service picks
up all ids and applies restructure definitions accordingly.
5. Restructured data stored in temporary table space and not on actual
table as system is in online stage and it should not disturb production
system.
6. Also for audit purpose, it appends restructure definition ID to the
INPUTTER field value in Audit section of Restructured data.
7. The data items that are identified to be obsolete are not written to tem-
porary table name, as this data item is no longer required for T24
product to function.
8. Release wise restructure is achieved with reasonable I/O.
9. No performance Impact due to this process.
Run T24.RESTRUCTURE.SERVICE
Run T24.TABLE.RESTRUCTURE service in online upgrade server. It restructures all
required data records according to the restructure definitions. Also, it initiates
T24.RESTRUCUTRE.FEEDER service in parallel which does restructure based on
feeder queue entries of online transactions processed in production system.

87 Online Upgrade
 Upgrading T24

After Restructure process, the restructured data stored in temporary table space
are shown here. And non-restructured data also moved to that temporary table as it
is, because this temporary table will be renamed to actual table. So there should
not be any data lose except obsolete data.

One of sample restructured data:

FED.FUNDS field (position 62) updated to YES in FBNK.FUNDS.TRANSFER.201812
temporary table name. This is data record view directly from Database through
TAFJ JQL-SQL-OFS window because restructured table name not yet renamed to
actual table name for access from T24.

Online Upgrade 88
Upgrading T24

Audit section INPUTTER field appended with restructure definition ID.

For Live file like AA.ARRANGEMENT there is no audit section, so there is no foot-
print of restructure definition IDs in those table-restructured records.
After T24.RESTRUCTURE.SERVICE, the T24.TABLE.RESTRUCTURE records status
marked to COMPLETED.

89 Online Upgrade
 Upgrading T24

Run T24.RESTRUCTURE.FEEDER Service:

The T24.RESTRUCTURE.FEEDER Service picked up feeder queue entries and does
restructure according to the restructure definitions, which are part of this upgrade.
I.e The Restructure definitions ID release number falls between
SPF>CURRENT.RELEASE and upgrading release 201812 has been picked up by
Feeder queue based restructure service for processing. The result is given in screen
below.
After T24.RESTRUCTURE.FEEDER service, the queue became empty.

And above Funds transfer data record matches with criteria defined in
FUNDS.TRANSFER-201809 restructure definition and FED.FUNDS updated to YES, the
other restructure definition  FUNDS.TRANSFER-201810 criteria not matches for this
data record hence it’s not applied. 

Online Upgrade 90
Upgrading T24

Now Restructure process over, next bring down channels and services as negligible
down time is required to do some necessary actions and switch production system
to upgraded server.
Renaming of Temporary table name into actual table name is required as next step
so that restructured data will be available for use or access in actual table as shown

91 Online Upgrade
 Upgrading T24

in topic ‘Rename Restructure Table name into actual table name’ explained in fur-
ther steps.
Rename Restructure Table name into actual table name
The temporary table space contains restructured data, this table name needs to be
renamed to actual table for use or access. A simple ALTER command will help to
achieve this.
ALTER TABLE <Temporary table name> RENAME TO <actual table name>
Where, temporary or actual table name should be Database name of those tables.

For example, Drop actual table then run this command.

ALTER TABLE FBNK_FUNDS_TRANSFER003 RENAME TO FBNK_FUNDS_TRANSFER;
Restructured data View from T24:
Sample screen shots given below on restructured data before and after image
according to restructure definitions.
For example, the restructure definitions that are considered for this restructure pro-
cess is:

For each restructure definitions part of this upgrade, what are the list of data items
from corresponding table being restructured according to the criteria defined in
that definition, that has been explained here with example.
For example, FUNDS.TRANSFER-201809: 
These are the records which was containing FED.FUNDS = NO before restructure
process.      

Online Upgrade 92
Upgrading T24

This shows restructured data, i.e FED.FUNDS updated to YES in all the records that
was having NO before.

Audit section INPUTTER field updated with restructure definition ID.

93 Online Upgrade
 Upgrading T24

Online Upgrade 94
Upgrading T24

Upgrade Monitor
Before start with T24 online upgrade, scanning of given temp release may help to
understand what are the critical and non-critical data items being released as part
of new software release. Also, throughout the upgrade process, the status of online
upgrade can also be monitored. These are the enquiries helps to achieve the same
and it has links todrilldown enquiries to view further more details.
1. UPGRADE.SCAN.TEMP.RELEASE
2. UPGRADE.DISPLAY.STATUS

UPGRADE.SCAN.TEMP.RELEASE
This enquiry shows current and upgrading release details. For example, Upgrading
R18 T24 Environment into 201902 T24 Release. Also, it shows list of critical, non-crit-
ical data items being released during this upgrade. Critical data items are nothing
but the primary data items being released during T24.UPGRADE.PRIMARY stage.
Non-critical data items are nothing but the secondary (remaining) data items being
released during T24.UPGRADE stage.  The sample temp release has Restructure
definitions for this upgrade so restructure tables count also displayed, cor-
responding drilldown link will help to know more about data items details.

List of Critical Data items View from the drilldown that shows critical Records
count:

95 Online Upgrade
 Upgrading T24

List of Non-Critical Data items View from the drilldown that shows Non Critical
Records Count:

Online Upgrade 96
Upgrading T24

List of Restructure Definitions View from the drilldown that shows Restructure
Records count:

UPGRADE.DISPLAY.STATUS
This enquiry helps to monitor entire upgrade process in each stages wise. Before
starting upgrade, all the status will be Not Initiated and it will different status
according to each stage, for example from the stage of T24.INITIATE.UPGRADE,
which starts online upgrade mode in T24 System, then Upgrade status we can see
as ‘Initiated’

97 Online Upgrade
 Upgrading T24

At this stage, the ‘Not Initiated’ drilldown links will show its actual data items being
part of this stage activity. For example, Restructure Status will show List of restruc-
ture definitions in T24.TABLE.RESTRUCTURE table will be shown and it is yet to be
picked up by T24.RESTRUCUTRE.SERVICE. Same way, the Primary Data Release
status will show those critical data items being released as part of primary upgrade
service T24.UPGRADE.PRIMARY. Same way Non-critical data items list can be
shown from Secondary data release status.
After T24.RESTRUCTURE.SERVICE initiated, the Restructure Status updated to ‘In
Progress’.

Online Upgrade 98
Upgrading T24

When restructure status is completed, and clicking this ‘completed’ drilldown can
view status of each restructure definitions and total table records are restructured
according to those definitions, restructure file name on which this converted data
has been stored. The Start time , end time, throughput, time to complete will have
values when the restructure is in progress.
Upon clicking Feeder status, can view list of records restructured based on feeder
queue list and its start time, throughput, processed records count, time to com-
plete, table list and the channel through which these table records are inputted in
production server before reaching feeder queue. This feeder queue is nothing but
the queue used to capture restructure enabled table records, which are processed
in production server in parallel, also need restructuring.

This T24.RESTRUCTURE.FEEDER is AUTO service, and should be manually stopped

by the upgrade user.
And then the service status shown as STOP in enquiry output also.

99 Online Upgrade
 Upgrading T24

When T24.UPGRADE.PRIMARY service has been initiated to release all primary

data items, the Primary data release status has been changed to ‘In Progress’ in this
enquiry as shown below. By this time, the T24 System is in offline mode.

After all critical data items has been released, the primary data release status will
show as completed.
Upgrade status will show as ‘Primary upgrade completed’ before starting of Sec-
ondary data release service.
Now Upgrade status show as ‘Secondary data release’ which indicates
T24.UPGRADE secondary service initiated.

Online Upgrade 100

Upgrading T24

Further drilldown from Primary data release status will show start and end time of
T24.UPGRADE.PRIMARY service.

After releasing non-critical data items and T24.UPGRADE service is completed, then
the secondary data release status shows as completed. Overall, Upgrade status still
shows Secondary Records Release because T24.AUTHORISE yet to authorize all
those released data items.

Further drilldown will show start time of this service.

After completion of T24.AUTHORISE service the end time can be reflected here.

101 Online Upgrade

 Upgrading T24

So overall status is now completed as Upgrade has been completed.

Online Upgrade 102