BATCH PROCESSING, END OF DAY & CRASH

RECOVERY
Introduction:

GLOBUS is run in two distinct modes, ON-LINE and BATCH. In general terms the ON-LINE
mode is for entering contracts and maintaining static information and the BATCH mode is for
processing events, calculating interest, and rolling the bank date forward and etc., i.e. the
former responds to user input the latter is triggered by date.

The batch consists of five stages:

Stage Description of Activities

1- APPLICATION Individual application processes (Forex, Funds Transfer etc.)
2- SYSTEM WIDE System wide processes (Interest & Charges, Revaluation etc.)
3- REPORTING Main system reports (trial balance, general ledgers, transaction
journal etc.)
4- START of DAY Change date (Standing orders, split month end events, cash flow
maintenance etc.)
5- ON-LINE Any non-critical reports and processes which can be run after the
system has returned to on-line mode.

BATCH:
BATCH 1) Pre EOD – Process involving Backup, Marks the process for actual EOD
2) EOD – Interest calculation - Reporting - Start of day – Standing orders,
date change etc – Ready
3) After EOD – Backup

This application defines the jobs which are to be run in batches at EOD.

Each stage consists of a number of processes, which correspond directly to records on the
BATCH file, and each process consists of a number of jobs which are routines defined on
PGM.FILE as type ‘B’.

The batch system will run all stages in sequence. The ON-LINE stage of the batch is run
immediately after the system has returned to on-line mode. Whilst this stage is running the
system will be available for user entry.

Temenos - India 134

BATCH PROCESS..... AC.CLOSED.ACCT.CONV
--------------------------------------------------------------------------
1 BATCH.STAGE....... A000 APPLICATION
2 DEFAULT.PRINTER...
3 PROCESS.STATUS.... 0 READY
4 BATCH.ENVIRONMENT. F FOREGROUND
5 DEPARTMENT.CODE...
6.1 JOB.NAME....... CONV.CLOSED.ACCT.ACCR
7.1.1 VERIFICATION
8.1 FREQUENCY...... A AD-HOC
9.1 NEXT.RUN.DATE..
10.1 PRINTER.NAME...
11.1.1 DATA........
12.1 JOB.STATUS..... 0 READY
13.1 LAST.RUN.DATE..
14.1 JOB.MESSAGE....
15.1 USER...........
16 RECORD.STATUS.....

ID gives the Process name.

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

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

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

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

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

FIELD 2 = DEFAULT.PRINTER
Specifies the default printer and form name to which all output is to be directed for the process.

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

Temenos - India 135

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

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

This is a NOINPUT field.

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

FIELD 6 = JOB.NAME
Job name contains the subroutine name which is to be run. The job name entered must be
an entry on the main program file PGM.FILE. The PGM.FILE record should define the actual
information commands or application routines to be executed as part of the job.

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

PROGRAM CONV.CLOSED.ACCT.ACCR
---------------------------------------------------------------------------
1 TYPE.............. B
2.1 GB SCREEN.TITLE
3 ADDITIONAL.INFO...
4.1 BATCH.JOB...... @CONV.CLOSED.ACCT.ACCR.10.4
5 PRODUCT...........
6 SUB.PRODUCT.......

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

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

FIELD 8 = FREQUENCY

Frequency maybe D - Every working day.

Dnn - Every nn working day.
W - Weekly every Friday.
M - Last working day of every month.
Mnn - Every nn or previous working day of each month.
A - Ad hoc.
Y - Last working day of the year.
Ynn - Last working day of the nn'th month.

Temenos - India 136

FIELD 9 = NEXT.RUN.DATE
Specifies bank date on which the job is to be next run.

When the end of day is initiated by the batch control system, it only runs those jobs whose
next run date is the same as the current bank date. Hence this field allows the user to control
when the job is next run.

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

For the process D as stage, the value will be the next working Bank date.

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

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

ENQ enquiry.name Specifies an enquiry report

report.name Specifies a report

FIELD 12 = JOB.STATUS
Indicates the current status of the job. This is a NOINPUT field.

Some common status values are:

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

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

FIELD 14 = JOB.MESSAGE
Stores the job error message number.

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

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

Temenos - India 137

BATCH.CONTROL:

This gives the status of process/job and option for running the batch processes.

To invoke the GLOBUS batch processor, run the application BATCH.CONTROL. Prior to
starting the batch run always obtain a batch report which will detail all jobs that are
scheduled to run.

If there are any unresolved errors on the EB.EOD.ERROR file (which were produced as a
result of a previous batch run) a warning will be given prior to the BATCH.CONTROL
application being invoked. If any of these unresolved errors are critical errors then it will not
be possible to invoke the BATCH.CONTROL

The BATCH.CONTROL application may be run from either Classic GLOBUS or from the
GUI (version 3 onwards)

APPLICATION
----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------

AC.CLOSED.ACCT.CONV ON LINE
CRF.SELF.BAL.UPD ON LINE
GIS.SHUTDOWN ON LINE
TT.END.OF.DAY ON LINE
DG.EOD.PRE.PROCESS ON LINE AND SO ON

SYSTEM WIDE

----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------

BUILD.BAL.MVMT READY
SC.SYS.END.OF.DAY READY

REPORTING

----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------

CD.BATCH.REP READY
SC.BATCH.REP READY

START OF DAY

----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------

DATE.CHANGE READY
SYS.FILE.TIDY.UP READY
--------------------------------------------------------------

Temenos - India 138

 1) PROCESS DETAILS 5) RESTART PROCESS 9) START ON LINE
2) INITIATE PROCESS 6) RE-RUN JOB 10) BATCH REPORT
3) DISPLAY PROCESS OUTPUT 7) SPOOL OUTPUT 11) AUTO BATCH
4) HALT PROCESS 8) INITIATE EOD 12) STOP AUTO BATCH
---------------------------------------------------------------------------
1 Process Details Displays details from the BATCH file
2 Initiate Process Runs a process
3 Display Output Displays output Como of process
4 Halt Process Halts process after current job
5 Restart Process Restarts process after halt
6 Rerun Job(s) Reruns jobs after error
7 Spool Process Output Spool Output Como of process
8 Initiate End of Day Moves system into batch mode
9 Start On-Line Moves system into on-line mode
10 Batch Report Produces a report of all jobs to run
11 Auto Batch Runs All processes automatically
12 Stop Auto Batch Stops auto batch after specific process

OTHER PARAMETER FILES:

Before initiating EOD the SPF file shows mode as O(NLINE).(Field No. 3)

Other Options that the field can contain are B(atch) and R(ecovery). Also contains
information about backup and restore (Field No 24 & 25), number of batches (when
run in desktop) ( Field No 32).
...... SYSTEM
--------------------------------------------------------------
1 RUN.DATE.......... 05 AUG 2000
2 SITE.NAME......... DEMO
3 OP.MODE........... O
4.1 OP.CONSOLE.....

19 DATA.ACC.NAME..... ../demo.data
20 RUN.ACC.NAME...... ../demo.run
21 DICT.ACC.NAME..... ../demo.dict
22 AUTO.MANUAL.BATCH.
23 OPERATING.SYSTEM.. UNIX
24.1.1 UNIX.BACKUP. ./backup.hd &H&
25.1.1 UNIX.RESTORE ./restore.hd &H&
26.1 PRODUCT.ACCOUNT
27 HELD.RPT.RETENTION 5
28 CACHE.SIZE........ 1000
29 MASTER.ACCOUNT....
30 PREVIOUS.RELEASE.. G10.1.03
31.1 PATCHES.INSTLD.
32 BATCH.SESSIONS.... 10
33.1 COMP.MNE.CCY...

During the batch processing- SPF op.mode becomes B(atch) and the only function allowed
are S(ee), L(ist) & P(rint) operations irrespective of the user. (Except PGM.FILE which allows
input). During Recovery no access is permitted. Cannot even login. (Reason being that user
profile also is being recovered & any updation or changes can take place).

Temenos - India 139

The DATES file contains information about the previous working day/ current working day &
next working day based on the holiday list.

DATES INPUT

COMPANY.CODE...... GB-001-0001 Globus Demo Account

---------------------------------------------------------------------
1 TODAY............. 25 FEB 2000
2 VERSION........... 1
3 LAST.WORKING.DAY.. 24 FEB 2000
4 NEXT.WORKING.DAY.. 28 FEB 2000
5 LOCAL.PAYMENT.DAY. 25 FEB 2000
6 LOCAL.DISPO.DAY... 25 FEB 2000
7 BACK.VALUE.MINIMUM 21 DEC 1999
8 BACK.VALUE.MAXIMUM 17 AUG 1999

End Of Day Processing:

Before commencement of EOD ensure that

 Activity – To see the users logged onto the system. Users should log out.
 Get the Exception list through EXCEPTION.PRINT – to know the unauthorised
records as at the EOD to enable the user to authorise the same – as the records will
be changed to IHLD status after the EOD has been completed.(Reason - Limits &
working balances are updated online in INAU status. However for interest calculation
these have to be reversed and hence record taken to IHLD status if in INAU)
 Also at the universe prompt LIST.READU EVERY gives the list of users & also to see
if there are any locks.

Now to commence EOD start batch.control – Initially the application process are ONLINE,
system wide, Reports & Start of day are on Ready status

Run the option 8 in Batch.control (BC)

 Checks the list active user.

 Closing down of active phantoms.
 Requests for Backup and performs the same as mentioned in SPF file.(Field No 24 &
25)
 Immediately the online process changes the status to EOD signaled.

In the case of any error abort the EOD by setting START ON LINE.

If there is insufficient space for backup/incorrect command for backup, error message will be
flashed.

To start the batch take option 8 - Initiate End of Day. This will check that all users have
signed off, logout the JOURNAL.SAVE and Delivery phantoms and then automatically
backup the database (cycle 2 Start of Batch backup SPF Application). You cannot enter
batch mode until all users have signed off.

Temenos - India 140

After the backup has been completed, the Delivery phantoms which were stopped prior to
the backup will be restarted.

COMO BAT.SYSTEM.BACKUP established 12:26:13 14 MAY 1998

EBS SYSTEM BACKUP 14/05/98 12:26:12

-------------------------------------------------------
Backup from [../demo.data] to tape

Continue <Y/N> Y
Closing Phantoms
……………
Backup successful <Y/N> Y

After ‘Initiate End of Day’ the status of all processes will be set to ‘EOD SIGNALLED’.

----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------

BNK/AC.CLOSED.ACCT| EOD SIGNALED
BNK/CRF.SELF.BAL.U| EOD SIGNALED
BNK/ONLINE EOD SIGNALED
LON/AC.CLOSED.ACCT| EOD SIGNALED
LON/ONLINE EOD SIGNALED

Select option 11 - Auto Batch.

Batch This will run all processes stage sequence. If you have
elected to hold batch output, set the SPF field HOLD.BATCH.OUTPUT to Y, then the
system will ask if you wish to print the output at the end of the batch and which printer you
wish to use.

The batch processes will now activate and if no errors are encountered the next intervention
will be to start the ON-LINE process.

14 MAY 1998 11:59:55 USER (17 FEB) ELIE [19,p8] PAGE 1

ACTION
SPOOL OUTPUT IMMEDIATELY AFTER AUTO BATCH COMPLETE <Y/N>

If Y he will print to the printer and load the HOLD.CONTROL Application, if N only the
HOLD.CONTROL Application will be affected. The reports held in this can be selectively
printed depending on the requirements.

Resets the status to completed successively if completed successively

----PROCESS-------------PROCESS STATUS-----------JOB STATUS -MESSAGE-------
BNK/AC.CLOSED.ACCT| COMPLETE SUCCESSEFULY
BNK/CRF.SELF.BAL.U| COMPLETE SUCCESSEFULY
BNK/ONLINE COMPLETE SUCCESSEFULY
LON/AC.CLOSED.ACCT| COMPLETE SUCCESSEFULY

Running this option in GUI mode enables multi-threading depending upon the sessions
mentioned in SPF file. (Field No. 32)

Temenos - India 141

In the case of a crash during this process, status will be “SYSTEM ERROR”.

 Option3 of the BC gives the display process and the messages are stored in &COMO&.
 In the case of reporting skip the report and continue with EOD.
 Else restore the backup before EOD, rectify the error and commence EOD.
 In the case of PGM.FILE having the option to rerun in Additional information then
can be continued to run without restoring backup.
 Rerun is not possible in desktop.
 Batch with A,S,R will run on the current date whereas D will be on the next working day.

Finally Option 9 will initiate Start online.

Once the batch is complete select option 9 - Start On-Line.

On-Line This will perform the following:

 Reset the next run dates for all batch jobs.

 Perform a backup of the database (cycle 1 Start of Day backup SPF Application)
 Clear the transaction journal
 Set the system mode to ‘O’ on-line.( SPF field OPERATION.MODE.)
 Allow you to re-start the JOURNAL.SAVE phantom
 Run the ONLINE batch stage

A backup is again taken.

All processes are set to ONLINE
EBS SYSTEM BACKUP 14/05/98 13:06:36
-------------------------------------------------------------------
Backup from [../demo.data] to tape
Continue <Y/N> Y
…..
Backup successful <Y/N> Y
Restarting Phantoms

COMO completed. 13:10:59 14 MAY 1998

SELECT F.EB.EOD.ERROR WITH ERROR.DATE EQ "19950405"

0 record(s) selected to SELECT list #0.

COMO BAT.START.OF.DAY established 13:11:00 14 MAY 1998
START OF DAY
---------------------------------------------------------------------------
System on-line..... initialisation

System mode will be set to on-line and journal file will be cleared

JOURNAL file cleared

System returned to on-line mode.

Initiate JOURNAL.SAVE (journal to tape phantom) <Y/N> N

Initiate remote journalling phantom (Y/N) : N

ENQ REPORT.LIST – selects the reports for printing.

Temenos - India 142

RESTORING DATA:
The database should be restored when the batch has to be re-run or when the on-line
transactions have to be recovered.

The database is restored using the command in the field UNIX.RESTORE on the SPF file.
In order to restore, all users must be ‘logged out’ including the delivery phantoms and the
journal tape backup, if active.

You CANNOT run SYSTEM.RESTORE from within GLOBUS as it deletes the database
prior to restoring, hence, any open files will become corrupted.

To ensure all files are closed, ensure ALL users and phantoms are logged out,
including the user who will be performing the SYSTEM.RESTORE. Then, login using a
uniVerse signon which takes the user to the uniVerse prompt and does not go into
GLOBUS.

When all users have been logged out, run SYSTEM.RESTORE in the bnk.run directory at
the uniVerse prompt.

The following prompts will be displayed:

>SYSTEM.RESTORE
list of current UNIX users
Ensure all users are logged off
Continue <Y/N> ?Y
Ensure all phantoms are closed down
Continue <Y/N> ?Y
Specify Restore Cycle <1-Start of day, 2-Start of Batch> ?1
Continue <Y/N> ?Y
output from backup command
Restore successful <Y/N> Y

If the restore is unsuccessful, for any reason, SYSTEM.RESTORE must be re-run.

The type of restore you have performed (start of batch / start of day) will control the next
actions you will need to take.

Start of Batch restore :

If the system is restored with the start of batch tape, then the system operation mode will be
set to B (batch mode). You may need to set the operation mode back to O (On-line) via the
BATCH.CONTROL menu (option 9) to rectify any error situation, and create a new backup
prior to initiating the end of day once more.

If the error was due to an operating system fault rather than one within GLOBUS, and it has
been rectified, the batch can be restarted from the BATCH.CONTROL menu (option 11).

Temenos - India 143

Start of Day restore:
If the system is restored using the start of day backup, then the system operation mode will
be set to R (recovery mode).
This restore is usually required where an error occurred during the on-line processing and
the system is to be reset to the position just prior to the error occurring.

This type of restore is also known as recovery, and is explained in more detail together with
the concept and usage of journalling.

Transaction journalling:
The GLOBUS system has a safeguard called ‘transaction journalling’ built into each on-line
application. Its operation is based on storing the after image of all the records updated by a
transaction.

It achieves this by ‘capturing’ the updated records at the time the ‘write’ instruction is issued,
deferring the physical write and storing the data in an internal cache. At the end of the
transaction the cache is written to the file, F.JOURNAL, as a completed log of all the updates
and only then are the individual file writes performed.

Consequently in the event of a hardware or software system failure, which requires the
database to be restored to the start of the on-line day, the journal file enables you to ‘roll
forward’ the day’s transactions without re-keying all the data again.

Journal file layout:

The journal file, F.JOURNAL, contains the following information :

Field Name Description
0 @ID Numeric 1 – 99999 - The journal number.
1 FWT - Files updated (Names and Keys).
2 FWC - After images of records updated.
3 TRANSACTION.REF - Transaction reference number e.g. FX9420300012
4 APPLICATION - Application name e.g. FOREX.
5 FUNCTION - Input, Authorise etc
6 TIME - Time journal record was written.
7 DEPT - Department code of user
8 OVERRIDES - Reserved for future use
9 USER - User who entered transaction
10 SIZE - Size of journal record in bytes.
11 COMPANY - Company the transaction took place in.

Temenos - India 144

Journal tape backup:
An optional facility is provided to constantly copy the new journal records to tape during the
on-line day. Hence, in the event of a complete machine failure, you can restore the Start of
Day backup tape and the journal tape to another machine, roll the journal forward to
‘recapture’ the transactions and then continue data entry.

The journal tape backup is initiated, as a background task, with an option in the Start On-
Line procedure in BATCH.CONTROL and terminated automatically in the Initiate End of Day
procedure. It can, however, be started and stopped at any time by running the application
JOURNAL.PHANT.CTRL.

Note: Whenever it is initiated it will always start at the first journal record i.e. the tape
will always contain the complete journal file.

Remote Journalling:
Remote Journalling consists of two phantom processes. One runs on the host machine,
polling for journal entries and transfers them in sequence to the remote machine. The other
runs on the remote machine, polling for transferred journal entries to apply to the local
database.

Further facilities exist to allow easy start-up and shutdown of these processes along with a
parameter table to define their operation. There is also a monitor, which can be run on either
machine that displays status information concerning the process currently running.

When a record within a GLOBUS table is modified by an input, authorisation, reversal history
restore or verify function the changes involved in the transaction are grouped together and
written as a single record in the journal file F.JOURNAL. This record is created as the last
stage of a transaction. Thus if the machine goes down at anytime during transaction input
database integrity is maintained since none of the file updates have been applied. The
recovery procedures make use of the journal file to roll the database forward from the start of
day to the last recorded transaction. This is possible because the journal file contains all the
data changes to all files involved in each transaction. Remote Journalling involves
transferring these journal entries, as they are created on the host machine, across to the
remote machine. They must then be applied to the remote database in exactly the same
order as they were on the host machine. Therefore sequence numbers are used to ensure
the correct order of transfer and reception from the host to the remote machine. When
setting up the remote machine it is important to take a full system backup of the host
machine. This will ensure the database integrity. Furthermore if upgrades, patches or the
creation of new files (e.g. REPGENS, DE.FORM.TYPE, DE.CARRIER or MI) take place on
the host system then a fullback must again be taken and restored onto the remote machine.
To restore the start of day backup to the remote machine DO NOT use the GLOBUS
SYTEM.RESTORE command. The restoration can be done on UNIX using a copy command
or on NT using your preferred method for copy overwriting. Upon the successful restoration
of the start of day backup the remote system can be set on line through BATCH.CONTROL
using the start on line process. It is recommended the Host system be set online before the
Remote system.

Temenos - India 145

RECOVERY:

If the system has been restored to the start of day then the on-line transactions must be
rolled forward. In addition to restoring the database you can also restore the journal file if the
‘crash’ has resulted in the journal file being inaccessible.

Journal restore from tape:

To restore the journal file from tape run JOURNAL.RESTORE from the uniVerse prompt in
the bnk.run directory. This will check that the date of the tape journal matches the date of the
database, clear the existing journal and restore the contents of the tape. An integrity check
will be performed on the tape records to ensure that only complete records are restored (the
process will stop if an incomplete record is found).

Transaction roll forward:

At this point it is advisable to get a report of the journal file (using uniVerse) to examine the
transactions which will be recovered. To roll the transactions forward you must run
SYSTEM.RECOVERY at the uniVerse prompt in the bnk.run directory.

This will check that the database date and the date of the journal match (i.e. it ensures that
you are recovering the correct set of transactions) and that the SPF operation mode is set to
‘R’ (indicating that the database has been restored to the start of day). You cannot proceed
without this verification. SYSTEM.RECOVERY will then count the total number of
transactions and prompt you for the number you wish to recover back to.

You can enter the total to recover all transactions or a specific number to roll forward up to
an individual transaction. Alternatively, you may enter 0, which will to recover no transactions
if it is more practical to simply re-key the days work manually.

>SYSTEM.RECOVERY
** SYSTEM FORWARD RECOVERY **
The database and if necessary the journal file should have been restored at
this stage.
Press <CR> to continue or "Q" to quit ?
JOURNAL DATE 19940525
SPF (DATABASE) DATE 19940525
Selecting the journal file ..... please wait
NUMBER OF TRANSACTIONS 199
Enter the number of transaction to recover? 197

If any errors are encountered (corrupt or unreadable journal record) then you will be
prompted to abort the recovery or finish at the current complete transaction (all remaining
transactions will not be recovered). If you abort you must restore the database and roll
forward again.

Temenos - India 146

System failure - On-line mode:
After amend any kind of transactions, the steps are like this:

Step1 Update the File F.LOCKING (LOCKING Application)

Step2 Update Database
Step3 Update F.JOURNAL in /bedev/bedev.jnl/F.JOURNAL
Step4 After Step3 the system will remove the journal record from F.LOCKING

A system failure can be classed as a GLOBUS software failure, a hardware failure, an

operating system error, network failure etc. That is, anything that prevents a GLOBUS
transaction from completing. If it has then the database must be restored to the start of day
and the transactions rolled forward or re-keyed.

In any GLOBUS transaction the database is only updated at the end of the transaction,
hence the database will only become corrupt if the software or hardware failure occurs
during this stage.

The message UPDATING FILES signals the end of the transaction followed by
TRANSACTION COMPLETE.

The following sequence of a transaction takes place.

1) The next journal id is allocated from the F.LOCKING key=JOURNAL

2) Transaction pending record written to F.LOCKING. The key is Jnnn.YYYYMMDD where
nnn=journal id followed by the bank date and the record contains all the information
stored in the journal record but without the after images.
3) The journal record, itself, is written.
4) The individual files writes are performed.
5) The pending record is deleted from the F.LOCKING file.

F.LOCKING contains the ID of the tables updated by a transaction and finally of the actual
transaction and lastly the ID of the F.JOURNAL

This mechanism has important implications for system recovery. If an on-line transaction
fails prior to UPDATING FILES the database is unaffected, hence the error can simply be
logged and the transaction re-input (preferably after the error has been corrected). It does
not affect any other on-line transaction.

To determine if a user has failed during UPDATING FILES check the LOCKING file for any
transaction pending records (@ID LK J...). The last instruction is to delete the transaction
pending record hence any that remain on the LOCKING file are caused by transactions
which aborted during UPDATING FILES. If this is the case the database MUST BE
RESTORED immediately to the start of day and the transactions rolled forward using
SYSTEM.RECOVERY as mentioned earlier.

Temenos - India 147

Non-GLOBUS failure:

After a hardware failure, network failure or operating system failure in on-line mode you must
ensure that there were no transactions in the UPDATING FILES stage. To do this simply
check that there are no Jnnn records in the LOCKING file.

If there are any incomplete transactions then the database must be restored and the
transactions recovered.

Temenos - India 148