migrating Cobol application to GUI based

[Bjay]

Hi we have In house developed application written in Compaq COBOL V2.6-1138 (alpha vms 7.2-1), now there is a requirenment to have a GUI of this application.

Could you tell me what are the options like
migrating the application to JAVA etc...

Thanks

[Hoff]

This is a reposting. ITRC blew up. Again.

There is some "due diligence" here around the specific application and technical requirements involved, the budget and the technical familiarity and the staffing limitations, and the questions around the COBOL source code itself. Some of these cases can be fairly simple. Some can entail the complete overhaul of the existing environment.

In the usual and general case, the approach is to segment the COBOL code into the business logic, and connect that to a user interface mechanism for whatever the UI de jour is. COBOL is going to outlive us all, though whatever UIs we're using probably won't be.

As for the brute-force approach, COBOL does web stuff just fine; any language that can generate ASCII or UTF-8 can be hooked to the web. And COBOL can be connected to a network just fine, too.

http://h71000.www7.hp.com/wizard/wiz_9495.html

If you want more than what a simple CGI application provides (and you can do a fair amount with even that), then you can use one of the packages around including libwww or fastCGI at http://www.johndapps.com/ , or one of the web services kits that are around, or other such tools.

Acucorp has some commercial options here. Run some web searches, and look around.

Another approach can involve providing a network-level interface into the code, and writing your web browser UIs in Cappuccino or such.

Or you rewrite it all (incrementally or en-mass) and migrate from COBOL to the COBOL of the Internet age, err, to Java.

You're far from the first person to look for this sort of stuff, and there are a number of folks that will be looking to sell you a solution (or the occasional boondoggle) here. A few web searches should turn up options.

[Willem Grooters]

What kind of GUI: on graphical terminals (using XWindows/Motif), or web-based?

Be prepared to split your programs to isolate screen-IO from the rest. In that way, changing interface is relativelyeasy and has less interference with business logic. Bear in mind that a GUI> mitf or web-based, is fundamentally different from the standard screen_io and you will have to adapt to these differences.

I would not recommend chnaging to Java, for several reasons. It highly depends on your system (with 7.2-1, you'll have to use a very old Java version - if available at all; if your program uses native VMS files, you'll have to change storage as well, or add yet another product (like attunity) to access your data.

If you can update your VMS system to 8.3, a suite like WSIT (WebServices Integration Toolkit) might be of help, but the disadvantages of java still apply.

[Hein van den Heuvel]

There is a much similar discussion in :

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1372380

Is the data for this application in RMS indexed files? You might want to consider an initial implementation with the GUI component accessing the RMS data through an ODBC interface. Several alternatives exist for that: Freeware, Attunity, CONNx, Easysoft,...

That may get yo to the GUI goal quickly and over time you can move to a complete non-vms implementation still using the ODBC interface in the GUI, but now talking to SQLserver, Sybase, MySQL, Oracle or whatever.

Now doing ODBC access may get 'chatty', a record at a time.
Often wrapping up services, is preferred: "process this order", "find eligeble vendor". A couple of key values in, a lot of action at the backend.

Good luck!
Hein.
HvdH Performance Consulting.

[Richard Ladendecker]

Consider moving to Microsoft's VB.NET. The .Net platform supports SQL Server, and VB would be an easy migration as the format and syntax between Cobol and Basic make the migration easy.

I have developed a parser that allows VMS COBOL to be moved to VB.NET (ASP & ASPX). CONNX would allow for rapid migration of your data to SQL server with minimal work on your part. It supports direct importing of CDD, Copybooks (libs) and manual creation from RMS files. (We used to sell the product and I have numerous examples).

I also have a development tools that read COBOL screens and allow for building ASPX web pages directly. It includes modules to read your copybooks and automatically create stored procedures to (insert, get, update and delete) all your tables via VB modules. The project was part of a migration for a large COBOL MRP environment to VB (v6.0) but evolved into a WEB based version. It may help you out considerably.

Copybooks, and declaratives are migrated allowing for simple coding changes to get to a "GUI" web environment.

Rick...

[Andy Bustamante]

>>> what are the options

What are the requirements? Can you update to a recent version of OpenVMS. Your operating system is out of support, adding functionality to that release is going to take additional effort (time and support costs).

There are 3 easily deployed web servers, WASD, OSU and the HP Secure web server. You can easily provide reporting with any of these and minor code updates.

>>>now there is a requirenment to have a GUI of this application

What is driving this and what are all the requirements around it?

See http://h71000.www7.hp.com/commercial/bridgeworks/bridgeworks_index.html for another option. I've only seen this in demos and the product hasn't had much PR recently, but this may provide you with an alternative.

Again, move to a supported release. In the OpenVMS world, application that followed standards generally "just work" after operating system upgrades. If this application is part of your business, can you afford to be running it without support?

Andy Bustamante