Methodology

UNICON'S METHODOLOGY IS TRUE CONVERSION:

In contrast to the alternative solutions available discussed below, Unicon provides a true conversion to native Open Systems environments. A true conversion fully converts all aspects of the Legacy System, including all program logic, screens, and data files to a standard Open Systems environment. The converted system is constructed and fully supported by the features and functions of the new Open System platform. There are no proprietary inclusions and therefore no ongoing support concerns.

Unicon's methodology is based upon converting the Legacy System to true Open Systems compliance. The converted system is then capable of fully utilizing all the new features and functions that are present today or become available in future releases including; Client / Server Networking, GUI, RDBMS, ODBC, Internet, Intranet, etc.

We have expended great efforts in our research and development (R&D) department to develop the techniques and procedures that enable us to provide true conversions for all our conversion projects. Our automated conversion tools enable us to perform these tasks with repeatable success and low cost.

AUTOMATED COMPONENT CONVERSION

The basis of our conversion process is called AUTOMATED COMPONENT CONVERSION. These in house developed converters enable us to convert the application from using the components from the legacy platform to using the new chosen components for the new open systems platform. These converted applications can now run in true native mode on the new open systems platform.

ALTERNATIVE SOLUTIONS � NOT RECOMMENDED

When considering rehosting applications from Legacy Systems to Open Systems a number of options present themselves. It is very easy to fall into the trap of performing the conversion by including proprietary technology, particularly in regard to emulators, screen drivers and file handlers.

In our view, even the most efficient emulation software, screen driver or file handler that could possibly be produced cannot create a fully effective solution. Not only does their inclusion inhibit the system from being migrated to a true Open System environment it actually burdens the system with unnecessary layers of complexity, support and overhead costs.

Unicon's success has been firmly based upon the methodology of converting to native Open Systems environments without the need for these items. The drawbacks of alternative solutions are highlighted below...

CONCERNS REGARDING EMULATION

The option to emulate the legacy platform on the new UNIX or NT system is often considered to be a viable proposition. Emulation is  performed by running a software layer that sits on top of the normal operating system of the Open System and makes it look and operate like the Legacy System. The application code and data files can then be copied directly from the Legacy System onto the Open System where it can be run without any change and will operate exactly as it did on the Legacy System.

But this option has several obvious drawbacks.

1. The addition of the emulation software layer burdens the Open System with unnecessary overhead and the performance of the system invariably suffers.

2. The application is forever locked in to the limitations inherent in the old Legacy System.

3. The emulation software inhibits the use of many of the features of the Open System and the full potential of the new system is never realized.

4. The new system is forever dependant upon support from the vendor of the emulation software layer. For example the installation of new operating system releases on the host Open System can often be difficult and expensive at times because a new version of the emulation software is required that will work with this new release.

CONCERNS REGARDING PROPRIETARY SCREEN DRIVERS:

The coding and processing of screens unquestionably provides the most programming differences between the Legacy COBOL and the Open Systems COBOL. To the uninitiated a first glance can also give the strong impression that the operating features and functions of the screens are also very different. This assumption has led many conversion endeavors to conclude that the only way to provide the same functionality in the screens on the Open System that was present in the Legacy System, is to employ proprietary screen drivers to perform the screen handling on the Open System. These screen drivers take many forms but they have the following obvious drawbacks in common:

1. They add an unnecessary layer of complexity on the converted system.

2. Proprietary screen drivers remove the use of the standard screen handler on the Open System which therefore inhibits the use of the new features and functions in these new systems, both for current and future releases.

3. The new system is forever dependant upon support from the vendor of the proprietary screen driver. For example, the installation of new operating system releases on the host Open System can often be difficult and expensive at times because a new version of the screen driver is required that is compatible with this new release.

CONCERNS REGARDING PROPRIETARY DATA FILE HANDLERS:

The coding and processing of data files also accounts for many of the differences between the Legacy System and the Open System programs. The assumption is made that the best way to resolve these differences is to provide a proprietary file handling system that will undertake all file processing in the converted system and to which all legacy files will be converted. But these proprietary file handling systems have several obvious drawbacks;

1. They add an unnecessary layer of complexity on the converted system.

2. Using proprietary data file handlers removes the use of the standard  file I-O facilities in the Open System which therefore inhibits the use of the new features and functions that are available in these new systems, both for current and future releases.

3. The new system is forever dependant upon support from the vendor of the proprietary file handler. For example the installation of new operating system releases of the host Open System can often be difficult and expensive at times because a new version of the file handler is required that will work with this new release.