Академический Документы
Профессиональный Документы
Культура Документы
Release R15
Temenos Application Framework C Version (TAFC)
Release Notes
No part of this document may be reproduced or transmitted in any form or by any means,
Electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings
NV.
Temenos Page 1 of 23
Copyright 2002-2011 TEMENOS Holdings NV. All rights reserved
Release Notes
Table of Contents
Temenos Page 2 of 23
Release Notes
R15_DCDCOMMON_RTC1359448................................................................................16
R15_DCDCOMMON_RTC1390618................................................................................18
R15_JQL_RTC1351720.................................................................................................. 19
R15_JQL_RTC1420384.................................................................................................. 20
R15_RUNTIME_RTC1368646......................................................................................... 21
Temenos Page 3 of 23
Release Notes
Release Highlights
This section provides an overview of any new TAFC components or features and advice
regarding any components which have been replaced, deprecated or modified.
Runtime Enhancements
Component Updates
From R09, a new update process was introduced that give client the ability to find and apply
‘upgrades’ on a component basis. This means it is now possible for changes to be isolated
and delivered with fewer fixes and for specific components. A service pack installation will
still be available and is required to get a full upgrade to all parts of TAFC.
From R12, TAFC has been enhanced to provide Initialisation Check functionality. This
component allows TIC (TAFC Initialisation Check) programs to periodically check Spoolers,
jDLS, TJ, user limits (ulimit), and disk space. This component can run as a UNIX daemon or
Windows Service and has the ability to disable the T24 application server if the system enters
a critical state. I.e. Out of disk space would be a critical state.
Please reference the TAFC Initialisation Check User Guide for more details.
SQL Engine
The jBASE SQL Engine (jSQL) has been enhanced to provide case insensitive queries, basic
column constraints, default values, aliases for column headings and multiple PICK
association compatibility enhancements. Additionally, the SQL catalog has a new option to
allow a different DICT to be used when adding tables.
1
From R09 jBASE has been renamed to TAFC. This name has been introduced to
ease client understanding and avoid questions such as “I run an Oracle database, why do I
need a jBASE database”. The Temenos Application Framework C Version or TAFC is the
new name for the runtime part of the jBASE product; the database portion will continue to be
called jBASE.
Temenos Page 4 of 23
Release Notes
jQL Explain Plan
From R12, the jBASE Query Language (jQL) supports a new ‘EXPLAIN’ statement. This
statement displays information about how the jQL query will be processed. The EXPLAIN
command output a list of the files, indexes, and sorts that will result from the supplied query,
along with access timings in a report format. Using this information the query can be
understood, tuned or written more efficiently.
Please reference to jBASE Explain Command User Guide for more details.
From R12, TAFC can publish the internal counters (JIMI counters) to Windows Performance
Counters API. The counters can be retrieved by any standard Windows monitoring tool like
PerfMon or Microsoft SCOM.
Please reference to TAFC Performance Counters User Guide for more details.
From R12, TAFC has a generic API for logging. The logs collect information from TAFC core,
jAgent and jBC.
From R13, several improvements have been done to TAFC logger API as follows
Improved jAgent/ jCF logs with proper severity levels and redundant messages removed.
Additional features
T24 username and OS user name added to log to enrich log content.
Temenos Page 5 of 23
Release Notes
Include logging for scenario where a session is blocked on READU for a lock already taken.
Also included is logging for scenario involving READU and LOCKED clause.
If the value of the TAFC_CONTEXT variable begins with “@” the rest of the value is treated
as a file path. If there is no "@" it is treated as just a name of the context.
Include logging for DEBUGCONTINUE (Enter debugger after displaying message, but the
user is allowed to use the 'c' to continue command) and DEBUGQUIT (Enter debugger after
displaying message, but the user cannot continue - the user must 'q' or 'a' from debugger).
Please reference to TAFC Logger API User Guide for more details.
Cache Duplication
From R12, the TAFC transaction cache has been modified to handle (discard) duplicate
entries within a transaction. Prior to this enhancement it was possible to have duplicate
entries with in a transaction boundary. Elimination of duplicate entries has reduced the IO on
the database reducing the network traffic to the database.
Read Cache
Prior to R12 ‘READ entries’ within a transaction was never cached. For every ‘READ’ from
within the transaction the record data was fetched from the database. This situation is
avoided in R14, since ‘READ’ are cached within the transaction. Once ‘READ’ entries are
cached, the records can be fetched from the transaction cache without hitting the database
thus reducing the network traffic.
By default, READs are not cache but this can be turned on using an environment variable.
Refer to User guide for details.
Partial Update
In R12, Partial Update was introduced for RDBMS supported databases (i.e. ORACLE, DB2,
and MSSQL). This work in conjunction with the REAL column implementation of the DCD
drivers (refer to ‘Database Enhancements’ section of this document for more information).
Prior to this all the ‘WRITE’ entries will flush the whole record back to the table even when
only few attributes have changed. This results in huge amount of redundant data being
flushed to the database table. This situation can be avoided when those attributes/fields that
are most frequently used are available as real columns. Then DCD driver could update the
real column data only and not the whole record.
Temenos Page 6 of 23
Release Notes
With this feature it is possible to write only those attributes/ fields of a file that has undergone
change within a transaction boundary. Note that Partial Update is applicable only within
transaction boundary. During the transaction commit phase the ‘Current record’ and the
‘Before image of the record’ from the database table are compared and those attributes/
fields that have changed are only written to the database resulting in huge IO improvement.
Super transaction
Super Transactions are used to modify the default behaviour of TRANSTART, TRANSEND
and TRANSABORT operator in jBC when jBC code is called via jAgent. When a transaction
is started via jAgent (connection.begin()) any occurrence of TRANSTART, TRANSEND and
TRANSABORT will be ignored within any jBC code called,
As these functions are ignored in jBC all updates now will be handled in a single transaction,
because there will only ever be a single transaction this will give some improvement in
performance, as all current TRANSTART, TRANSEND and TRANSABORT will be ignored,
the transaction operations are now handled by jAgent.
A new flag has been added to dp (dp->tdp->super_transaction), this is set when a transaction
is started in jAgent. The following functions use in jBC, TRANSTART, TRANSEND and
TRANSABORT will check for this flag, if it has been set they simply return and use the
current transaction. If rolback() or commit() is called from jAgent, the flag is reset and the jBC
routines then behave as normal and process the current transaction. By default this new
behaviour is enabled in jAgent, to disable the new behaviour you can set
“TAFC_DISABLE_SUPER_TRANSACTION” before starting jAgent.
Although Super Transactions bring many advantages there are some drawbacks to consider.
Because transaction key words will be ignored if issued via jAgent running the same routine
from a jSH could potentially produce different results.
If built in 'multi-threaded' mode (refer to User Guide) it is possible to create more than one
TAFCSession from each OS process.
Splunk Support
Temenos Page 7 of 23
Release Notes
When a T24 transaction is committed several records in several different tables can be
updated within the scope of the transaction. The data updated is entirely dependent on the
T24 application and the type of transaction. To track these changes TAFC brings a new hook
called Data Filter.
The user can configure any table with valid VOC entry and its data to be tracked. This
information should be stored in DF_FILTER record of F.SCHEMA table. If any transactions
change the data of these tables the changed data is stored in F.DATA.EVENTS table for
further references.
The data filter capability is provided for WRITE and also extended to DELETE operations.
Database Enhancements
Note: these enhancements apply to all three Direct Connect drivers except where specified.
See DCD installation Guide for more details on how to use these features.
Real Columns
‘Real Columns’ are different from the ‘Promoted Columns’ that were provided in R11.
Promoted Columns are virtual columns generated from the XML column and hence there is a
duplication of data. Promoted Columns could be indexed and used for queries whereas the
data is still retained in the XML column for read and write, update and retrieval.
Real Columns are physical columns built on the table, their data is extracted from XML and
stored in the column so there is no duplication of data, the real columns can be indexed and
used for both queries and data value update and retrieval.
The implementation of Real Columns on ORACLE, DB2 and SQL Server database provides
the capability to make Partial Updates on the data values to improve the performance and
reduce the amount of data both sent over the network and placed in the transaction log. The
Partial Update capability must be explicitly enabled and is handled automatically during the
commit of the framework transaction cache.
The Real Columns when present are automatically detected and used by queries and also
provide the capability for the introduction of partial reads. Partial Reads need to be invoked
explicitly within the application where determined to be useful.
The principle is that certain fields in the XML document (corresponding to single value
Attributes in T24) can be extracted into a separate relational column. There is no duplication
between XML and real columns, so the data it can be read or written independently. Full
reads and writes functions are unaffected and transparently maintained by DCD.
The driver will translate the JQL query accordingly. i.e., the driver will create a SQL column
expression instead of an XPATH query, which would have been used before to select the
field from within the XML document column. Currently this is implemented as a ‘manual’
modification to the database, and should be undertaken in liaison with TEMENOS Customer
Services.
Temenos Page 8 of 23
Release Notes
NOTE: This feature is only valid for XML type columns. Any attempt to use with BLOB type
table configuration will result in an error exception being thrown.
Temenos Page 9 of 23
Release Notes
DCD has supported ORACLE failover since R10. In traditional way DCD throws an error back
to T24 whenever a failover occurred, the error handling was then left with T24.
However in certain instances T24 fails to handle this error correctly and hence was possible
that the process could continue after failover completed. If the failover happened on a query,
outside a transaction then this presents no real problem however if the failover occurred
during a transaction and the error is not handled then it is a problem. ORACLE rolls back the
current transaction whenever a failover occurs, DCD reports the error to T24 statement
(usually on a read or write statement), if T24 misses the error and continues processing then
it is possible for a partial transaction to occur, whereby the latter half of the transaction was
committed to the database but the former part would be missing, resulting in an inconsistent
transaction state.
In R12, this modification will stop the above scenario from happening by dropping the process
out whenever a failover notification is captured, and thereby force T24 to retry (Online) or
restart (COB) the transaction. This will guarantee the transactions consistent between
database and application during failover.
In previous releases (R10 and R11) ORACLE temporary LOB is used for data reads, i.e. data
is retrieved from table into a temporary LOB, and then DCD reads data from LOB. The
advantage of this mechanism is that there is no data size limitation, even large data can be
handled in LOB, but the disadvantage is it is expensive in both storage space and
performance.
In R12 this issue has been addressed by introducing piece-wise data retrieval. The idea is to
use fixed size buffer to retrieve a fixed size piece directly from table, if the data is larger than
what would fit in the fixed buffer, then the retrieval will be repeated until all the data is
fetched. The benefit is that the temporary LOB space is no longer required, and data
movement from table to LOB is saved. The disadvantage is that for very large records
additional retrievals are required. Statistically most data records will be retrieved in one round
which would mean around 2.5 times quicker than LOB read.
ORACLE Binary XML was introduced in 11gR1, and XQuery 1.0 standard was applied in
DCD from R10 onwards. However due to problems encountered by TEMENOS with the
operation of using ORACLE Binary XML and XML Index this functionality had been withheld
from production.
The ORACLE and TEMENOS partnership has now resolved those problems and the Binary
XML, XML Index and XQuery are now functional in R12 release. As such function based
index are now not the only choice to improve query performance and XML indices can now
be used to translate the jQL to XPath queries.
XML Indices can be used with both CLOB column storage as well as Binary XML column
types.
DB2 support
Temenos Page 10 of 23
Release Notes
A new T24 database driver for SQL Server and SQL Azure has been introduced for
deployment with TAFC.NET from R13.
The driver leverages Microsoft Entity Framework 5.0 and Microsoft .NET framework 4.0 to
provide database connection pooling enabling T24 to partake in the same transaction scope
as a WCF .NET transaction as provided by TAFC.NET capability.
The driver fully supports the existing T24 XML and BLOB table formats without modification
as the entity models are dynamically constructed as required, enabling tables to be added or
deleted rather than prebuilt at design time.
The driver utilises the Microsoft code first approach with subsequent development leading to
data and model first extensions.
T24 data is separated into volatile and non-volatile and are being stored in different
databases. Hence Direct Connect Drivers are enhanced to connect to multiple databases.
config-XMLxxx utility is also enhanced to configure multiple databases. It allows creating
tables in different databases, creating READ-ONLY tables, and configures ASSOCIATE
property to the “live” table of the database.
Please refer the User Guide for the DCD Multi database support for additional details.
Data Encryption
The T24 application being a banking application needs the ability for data to be protected
from unauthorised access. The new enhancement encrypts the data in the table specified by
the user. The base key is added to the jedi_config. ENCRYPT key qualifier is provided for
the CREATE-FILE utility to use user-defined encryption key. Encryption can be done for both
BLOB and XML tables. The JQL to SQL translation is suppressed to all the encrypted tables.
The data in these tables would be encrypted while storing in database and decrypted while
reading. These tables cannot be renamed or copied.
Temenos Page 11 of 23
Release Notes
Windows SDK support
An alternative to using the Visual Studio 2010 Professional compiler is to use the Microsoft
Windows SDK v7.2.
Microsoft Windows SDK for Windows 7 and .NET Framework 4
"The Visual C++ compilers shipped in the Windows SDK v7.2 are the same compilers that
ship in Visual Studio 2010 RTM"
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-
529fa782d63b&displaylang=en
Temenos Page 12 of 23
Release Notes
Internationalization library
ICU 4.0 is required for Locale, Timezone and Multi Byte character set support. This version
of ICU allows a client to download updated locale and timezone information from the ICU
home page. http://site.icu-project.org/
XML library
Xerces 3.0.1 and Xalan 1.11.0 are required for XML transformation within TAFC.
Java Runtime Environment (JRE) 1.6.0 is required for CALLJ functionality within TAFC.
Temenos Page 13 of 23
Release Notes
If you have an earlier version of jBASE or TAFC installed you should stop all jBASE/TAFC
processes, services, and save any system configuration files before proceeding with the
installation of TAFC.
NOTE: Your profile will have another environment variable, JBCGLOBALDIR, this should be
as follows:
export JBCGLOBALDIR=$TAFC_HOME
NOTE: For installation or upgrade of Direct Connect Drivers (DCD) see separate Installation
Guide document.
Temenos Page 14 of 23
Release Notes
Upgrade Summary
You are now ready to follow any pre-release procedures described below:
Respond to the Model Bank question appropriately.
Provide a USER id as requested.
Once this is complete you are ready to sign on to T24 to initiate the upgrade service.
Start the TSA.SERVICE record BNK/T24.UPGRADE.
Authorise any CONVERSION.PGMS records.
Initiate the service RUN.CONVERSION (TSM must also be run)
Recompile any local code (New inserts provided by the release and
or TAFC upgrades require this)
Once this is finished the record review and authorisation process can
commence.
Temenos Page 15 of 23
Release Notes
R15_DCDCOMMON_RTC1359448
R15_DCDCOMMON_RTC1390618
R15_JQL_RTC1351720
R15_JQL_RTC1420384
R15_RUNTIME_RTC1368646
Temenos Page 16 of 23
Release Notes
R15_DCDCOMMON_RTC1359448
This patch fixes the issue with transaction boundary when the
JEDI_XMLDRIVER_FILE_CONTROL variable is set
To Test:
1) Create a file with the following DICT
G:>CT Transtst]D SHORT.NAME
SHORT.NAME
001 D
002 2
003
004 SHORT.NAME
005 35L
006 M
030 JBASE_EDICT_START
031 108
034 SHORT_NAME
035 SHORT.NAME
036
039 1073741824
047 JBASE_EDICT_END
Temenos Page 17 of 23
Release Notes
PROGRAM case.b
dd = GETCWD(cwd)
filename = cwd:"\TEST.XML"
EXECUTE "SELECT TransTst WITH @ID EQ '10000083' AND SECTOR.NAME EQ
“TEST”
TRANSTART THEN
CRT 'TRANSACTION STARTED'
END
OPEN filename TO FD1 SETTING err ELSE
CRT "":err
END
WRITE "TESTASDF" TO FD1,"ONE"
TRANSABORT THEN
CRT 'TRANSACTION ABORTED'
END
TRANSTART THEN
CRT 'TRANSACTION STARTED'
END
OPEN filename TO FD2 ELSE NULL
WRITE "TESTASDf" TO FD2, "TWO"
TRANSEND THEN
CRT "TRANSACTION END"
END
Before Fix:
G:>echo %JEDI_XMLDRIVER_FILE_CONTROL%
1
Temenos Page 18 of 23
Release Notes
SELECT: SQL:2:Full: SELECT COUNT(t.RECID) FROM TEST_XML t
2 Records counted
jsh -->CT TEST.XML
ONE
001 TESTASDF
TWO
001 TESTASDf
After Fix:
jsh -->case
SELECT: SQL:1:Part: SELECT t.RECID,t.XMLRECORD FROM TransTst t WHERE
dbo.numcast(RECID)=10000083
No Records selected
TRANSACTION STARTED
TRANSACTION ABORTED
TRANSACTION STARTED
TRANSACTION END
R15_DCDCOMMON_RTC1390618
This patch fixes the issue while comparing two I-type fields.
To Test:
1) Create a file with two I-type fields
2) Execute the command SELECT <filename> WITH <I-type field1> EQ <I-typefield2>
3)
Before fix:
jsh -->SELECT SQLTEST WITH ITYPE1 EQ ITYPE2
SELECT: SQL:2:Full: SELECT t.RECID FROM SQLTEST t WHERE
XMLRECORD.exist(N'/row[c20[@m=2]/text()="c20[@m=3]/text()"]') = 1
After Fix:
Temenos Page 19 of 23
Release Notes
jsh -->SELECT SQLTEST WITH ITYPE1 EQ ITYPE2
SELECT: SQL:2:Full: SELECT t.RECID FROM SQLTEST t WHERE
XMLRECORD.exist(N'/row[c20[@m=2]/text() =c20[@m=3]/text()]') = 1
Note:
Do not compare two fields of different types
The fields that are compared must be of same justification (either right or left)
R15_JQL_RTC1351720
To Test:
1) Create a J4 file.
2) Create 2 right justified attributes.
3) Insert few records
4) Set JBASE_I18N to enable internationalization.
Before Fix:
jsh ~-->SELECT SAVETEST1 WITH NAME EQ MATT BY DATE BY AMOUNT
4 Records selected
>LIST SAVETEST1 NAME DATE AMOUNT
PAGE 1 11:48:07 09 JUN 2015
@ID....... NAME........... DATE....... AMOUNT....
REC4 MATT 20091223 25
REC3 MATT 20091223 1000
REC1 MATT 20091223 -1000
REC2 MATT 20091224 -2.58
4 Records Listed
After Fix:
jsh ~-->SELECT SAVETEST1 WITH NAME EQ MATT BY DATE BY AMOUNT
4 Records selected
>LIST SAVETEST1 NAME DATE AMOUNT
PAGE 1 11:49:40 09 JUN 2015
@ID....... NAME........... DATE....... AMOUNT....
REC1 MATT 20091223 -1000
REC4 MATT 20091223 25
REC3 MATT 20091223 1000
Temenos Page 20 of 23
Release Notes
REC2 MATT 20091224 -2.58
4 Records Listed
R15_JQL_RTC1420384
This patch fixes the issue of SELECT with LIKE pattern on field that use G Conversion.
Before the fix Select didn't retrieve correct results with LIKE pattern for fields that use G
conversion.
To Test:
1. Create a J4 File.
2. Add dictionary items as below
jsh -->CT TEST_G_CONV]D
@ID
001 D
002 0
003
004 ID
005 75L
006 S
TRANSACTION.REF
001 D
002 0
003 G4*1
004 TRANSACTION.REF
005 16L
006 S
3. Add some records.
jsh testuser ~/TestFiles -->LIST TEST_G_CONV
PAGE 1
ID.........................................................................
1*GB0010001*20110413*RE*ACREVAL*1001.1499.EU*R*158260775448846.22
1*GB0010001*20110413*RE*ACREVAL*1001.1499.EU*R*158260775448846.23
111111111111111111111111111111111111111
4. Execute the Select command with LIKE pattern on the field that use G
Conversion.
SELECT TEST_G_CONV WITH TRANSACTION.REF LIKE "ACREVAL..."
Before Fix:
Temenos Page 21 of 23
Release Notes
jsh-->SELECT TEST_G_CONV WITH TRANSACTION.REF LIKE "ACREVAL..."
No Records selected
After fix:
R15_RUNTIME_RTC1368646
This patch fixes the issue of data getting corrupted in the last character getting replaced
when JBASE_I18N is set.
To Test:
1) export JBASE_I18N=1
2) Execute the following program
CRT 'Original Text'
YDIR = '1001':@FM:'100182082/'
CRT YDIR
CRT 'Text to be removed'
XDIR = YDIR<2>[1]
CRT XDIR
CRT 'After removing the text'
YDIR<2>[1] = ''
CRT YDIR
Before Fix:
Original Text
1001?100182082/
Text to be removed
/
After removing the text
1001?100182082/ .sd
After Fix:
Original Text
Temenos Page 22 of 23
Release Notes
1001?100182082/
Text to be removed
/
After removing the text
1001?100182082
Temenos Page 23 of 23