Gorus

This project was subcontracted by a German software development company based in Cologne. Being almost a monopolist in this area in the province the company has supplied the city with gas and water data management software since 1982.

This software used by the municipal department is a package of products for very specific management, accounting, calculation and maintenance of gas and water consumption for private persons and companies.

Project 1. Porting to Oracle and Informix

Our cooperation started in 2001. At that time the system was written in COBOL and a library based on our own implementation of CISAM algorithms was used as data storage. The customers (mostly governmental bodies) started to transfer their other systems to Oracle and Informix and they wished to port the system from CISAM to these more up-to-date DBMS, as well as to have interfaces to exchange data with their systems. Also, internally, the company hoped to improve performance of their products, assuming that moving them to relational database will significantly affect speed of the system. This task was assigned to us.

The total amount of table (.DAT and .IDX) files in the system exceeded 450. First of all, we created a model corresponding to the structure of the information contained in the data files in Platinum ErWin. We tried to minimize the differences between the existing data storage system and Oracle, Informix already at data presentation level, to reduce further problems with distinction in SQL. Afterwards we developed a library of functions providing common interface to work with three possible alternatives: Oracle, Informix and CISAM-based data storage. The library consisted of two layers: the first one was implementation of common API calling functions and the other was a database-specific layer, which was developed in Embedded SQL (for DBMS) and using the company's own API for its storage system.

Using this API which was common for all databases at that time and easily extensible to another, we made other COBOL sources independent of the database level. The next step was to re-write over 400 masks (screens) to have them working with the new API library. That was done successfully within next 8 months. Almost all of this time four to five developers were working on this task intensively using such Unix utilities as awk, sed and automatized many aspects of the development process. Nevertheless, all screens had to be processed manually by the developers.

After the development was completed, testing has shown that the usage of DBMS (Oracle and Informix) made the performance considerably worse. Upon the agreement with the customer we started to optimize queries and administer all the involved software to achieve better results. We optimized and adapted to our needs the operation system configuration (Solaris, SCO), database parameters (cache and read ahead directives, statistics, indexes, queries), and application logic. But it did not show any noticeable results: only some of the slowest queries became faster. The real reason was that DBMS possess a lot of redundant functionality which cannot compete with direct index file access.

The customer accepted the reason. Hardware industry did huge steps towards improving resources capabilities and speed, and the problem was resolved. Usage of DBMS provides better transaction mechanisms backup, maintenance and other advantages.

This development allowed our German customer to sell this system to new clients, thus enlarging their market. The design that we suggested for porting and its implementation was extremely useful and caused the same customer to order with us the development of a module (see second layer for database access API library) for DB2 in 2000, which was successfully performed by two of our developers within just two months.

Project 2. Porting to Visual Basic

In the 2002 owing to constant growth of hardware resources, German clients of our customer started to upgrade their computers, installing more and more PC workstations running Windows. The software that the company provided was written in COBOL and had a terminal-based user interface – this was not comfortable for users and the municipal government ordered a new version having Windows interface.

Porting of that huge amount of COBOL code required a lot of resources, so the company decided to start with small subsystems, increasing this amount step by step. We were subcontracted to port one of applications, a user's terminal consisting of about 50 screens. The objective of our task was to keep in Windows-based application the possibility to promptly and comfortably enter data by person working with the software.

At that time, we decided to not to look for any specific framework, that could allow us to automatize the porting process. We are convinced that dealing with two absolutely different technologies it is impossible to just automatically process the old code and get exactly the same software but made on the basis of the other technology. Also our customer was convinced of it, because his goal was not just to port but also to improve the present product. In most screens we were required to change the screen layout, because in fact Windows UI allows providing the user with more advanced interface than text-mode application does. Therefore this project wasn't just porting, but a lot of new development: without changing the business logic we made user interface more comfortable.

The development environment consisted of Microsoft Visual Basic 5.0, for data access (to Oracle and Informix) we took Intersolve ODBC components and Microsoft DAO 3.0 Object Library (company's proprietary CISAM-based solution was not targeted at a new version of product). The interface required a few advanced components such as grid and navigation tree, therefore we used Sheridan (now company's name is Infragistics) OCX's (Microsoft standard components did not correspond to customer requirements).

For installation program we used InstallShield, because standard Microsoft installation tool distributed with Visual Basic did not provide of the complete set of the required functionality.

To minimize the loading time of meta data from the server, we used a local Access database, so that some frequently used tables (language resources, descriptions, etc.) were loaded only in case if the server database contained the data more recent than those in the local database. When application is launched, it requires from the server the time of the last update for these data (which is watched by triggers set on insert and update), and if the server data are more recent, application automatically loads it from the server. In this way, many parts of the client application are updatable, and it does not influence the network traffic and as a result - the performance speed for a user.

The project was successfully completed by the end of 1999 and took over 20 man-months (2 to 3 developers were working during 9 months).

Project 3. Providing Web-interface for reporting functions

In February 2003 we were subcontracted to develop a set of Web-based applications providing possibility to view reports generated on the basis of data stored in the GORUS database. At the moment this application is using Oracle only and runs mostly on Unix platforms (Solaris, SCO, Linux) and some mainframes (OS/390).

In order to provide effective implementation and high-quality functionality, we decided to use JSP (Tomcat), Oracle JDBC drivers (type 4) and a set of our applets (Awt.X Treetable, Graph). Also for reporting functions we generate miscellaneous charts and diagrams as GIF images using functionality provided by standard (from JDK 2) Java classes libraries.

The project required over 15 man-months.