Migrating to a GUI without losing business logic written in COBOL

Question

We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.

Answer 1

Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.

These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.

There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.

Answer 2

If it was me I would look into something like this:

NetCobol for Windows

It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.

It took us about 15 years to get off of our mainframe, because we didn't do something like this.

Answer 3

Editors: the tag "busines-logic" is misspelled. (I don't know how to edit that, or else don't have enough reputation yet.)

Answer 4

Thanks Nathan for the spelling correction. I must confess I'm a developer not an editor.

Answer 5

Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.

If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.

For program A, you then generate a client proxy and A can now call B via a web service.

Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.

Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.

And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.

Answer 6

You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.

Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.

Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.

As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.