T24 User Guide - Page 27

Loading ...

T24 Application Development

The application program requires no special code to achieve this functionality. See the Security

Management System Administration Guide for more details.

Validation

Input validation can be specified with the field definitions and hence the infrastructure will check the data

entered. The validation available is comprehensive, offering simple checks such as numeric/non-numeric

input, to complicated date and amount edit checks. Input can also be verified against an existing table as

well as being passed to an application specific routine.

To allow maximum flexibility, the infrastructure can pass control back to the application for further

validation at any stage. The template also contains sections for further validation on completion of input

(cross-validation), authorisation, deletion etc.

Main File Maintenance

The infrastructure in addition to controlling the transaction input also controls the update of the main

transaction file. In this way it can maintain both authorised and unauthorised versions of a record and

keep a log of the last user to input/change the data (this it stores in the data record itself).

History Maintenance

As an extension of the main file update procedure, the infrastructure will optionally maintain a history of all

changes made to the application records. The user will then have the ability to 'walk through' the history

file examining every change as it occurred and even restore the last record from history in the case of

accidental reversal.

Transaction Journaling and System Recovery

Recovery and transaction management is provided by the T24 infrastructure. Special coding is

not required.

The recovery system is based on jBASE transaction management. The physical updates to the database

files do not take place until the end of the transaction, i.e. after the commit transaction is performed.

It is possible to use the JOURNAL file to store information pertaining to all the writes that occur during

transactions input. By default this information is not captured and has to be setup by using the SPF

application and setting the field INFO.JOURNAL to Y.

To roll back logically within a transaction, due to a program bug or operator override, the procedure has to

abort the current transaction and return to the start of the transaction (id input or whatever). This is

possible because no updates have actually taken place.

Another advantage of this mechanism is any application errors that cause a program to abort and would

normally involve a system restore/roll forward, can be ignored in terms of data integrity.

Refer to “Backup, Restore and Recovery System Administration” guide.

Audit Trail

All main file updates are 'stamped' by the infrastructure with the name of the inputter and authoriser, date-

time, terminal number, company code etc. to provide a comprehensive audit trail. If history is maintained

then the audit trail will be carried in the history records as well, providing a log of every update performed.

TEMENOS T24 User Guide Page 27 of 34

Loading ...