You are on page 1of 4


This document details the methods and utilities developed for converting an existing Universe
application to jBASE.
Migration consists of two stages

Data transfer
This is the method of initially transferring data from Universe to jBASE and subsequently
refreshing the data. It is a binary transfer and no account is taken of the data content. Speed is
an essential factor in data transfer as a large amount of data may be required in a relatively
short period of time, e.g. a weekend.
Data refresh may be done many times during the migration period and is under the customers
control. The last data refresh is where the jBASE version of the application is accepted and
therefore considered live, hence go-live.

Porting is the changing of code and data required to allow for differences between Universe
and jBASE. Porting is ideally done once after the initial data transfer and all subsequent
transfers leave the ported program files and dictionaries alone.
Exceptions occur where there is development on the live system during the migration period.
The changed programs can be re-ported, but this should be discouraged as it complicates the
comparison between the new and old systems. Signoff occurs where the customer considers
the two systems to be functionally equivalent.

Migration Tools User Guide

Temenos is a financial software house, which has a worldwide userbase of banks and financial houses
running an application called Globus, currently running on Universe. Temenos owns jBASE and aims
to transfer all the Globus installations to the latest release, T24, running on the jBASE database.
There was no obvious method of transferring data and programs from Universe to jBASE and hence
the requirement for a migration suite.

Migration Tools User Guide

Data Transfer
Data transfer is effected by allowing jBASE to see the Universe database on disk, by copying the
entire Universe data structure, a read only NFS mount or, in exceptional circumstances, using the
existing hardware for both new and old systems. The Universe DBMS is not required on the jBASE
platform. Where copying data or reusing kit at least 2.5 times the currently used disk space will be
The data transfer is configured by the executable JUCONF and initiated by JUBUILD. JUBUILD calls
jufimp, an executable that creates and populates jBASE files from Universe hashed files, writing to
jBASE through the Jedi file interface.

JUCONF is simply a way to maintain juport.ini, the configuration file for JUBUILD, and alternatively the
file can be maintained through a text editor. In these examples, from Windows and UNIX platforms
respectively, the flat file has the following fields:
Windows 2000:
# FileType may be 0=J4 or 1=Oracle XML


A comment is marked by #.

The absolute filepath of the jufimp executable.


The maximum concurrent background jufimp processes permitted

where the file size exceeds PhantFileSize.


The size of a Universe file beyond which causes jufimp to be

launched as a background process.


The absolute filepath of the top directory of the Universe application



The absolute filepath of the parent directory to hold jBASE file



The destination file type. See table, below.


Whether to abandon the data load if a sequential file create fails.

This should only be 0 for internal testing; if a failure occurs on a live

Migration Tools User Guide

site then the entire data load is considered invalid.

File types


Oracle tables

DB2 tables


JP (large files)

* Types 4 & 5 are reserved for internal use.

Initial Load v. Data Refresh

T24 is supplied cut for jBASE so it will not be necessary to bring the entire application across to
jBASE but wont do any harm as the newer Globus code will replace the older code, and there is no
time constraint on the initial load. The initial load will bring across everything from the Universe
database including programs, dictionaries, VOCs and data. After this point extreme care must be
taken to ensure that updates in local code on the live system to programs, dictionaries and VOCs are
propagated to the jBASE system, with appropriate porting, until go-live.
The initial load source and destination directories will differ from those of the data refresh as all only is required. A separate load may be required for local data. Thus if the initial load source &
destination are:

Then the new version of Globus is overlaid and the data refresh source & destination will be: