Migrating VAX COBOL to Windows/Linux

[h11tsr]

We have an COBOL legacy application which uses front ends created in Fortran/Pascal and VAX macros (32 bit).

We are currently faced with the prospect of replacing or rewriting. Replacement will be a long drawn out project - the analysis phase is already delayed.

Has anyone migrated an application like this to Windows or Linux? Problems, hurdles encountered, etc ?

I have heard of a number of tools which supposedly convert COBOL programs, but do not know how good they are. I have not come across and tools that would convert the front end screens.

 

[ShadowFox333]

Hi h11tsr,
How many Cobol programs are involved. Couple of years ago
I convert a couple of hundred Vax-Vms cobol programs to Rm-Cobol for a Company but the front end screens were just a lost of displayed text files, and I was told to use specific file names for the file assignments like
assign to '\\somecomputer\c\folder\folder\filename'
Let me know if I can help.
Bob

 

[k5tm]

I am still a little vague on the architecture of the application.

front ends created in Fortran/Pascal and VAX macros

then

I have not come across an[y] tools that would convert the front end screens

Are the COBOL programs called as subprograms from the front end programs? Or vice versa? Will the conversion tools be looking at FORTRAN/PASCAL or COBOL? If the presentation is this well isolated, perhaps you should be considering a forward-looking replacement, such as a web browser.



If you have a COBOL program that does not concern itself with presentation, then you are a long way down the path toward converting the COBOL portion. (Most proprietary extensions are used in the presentation logic of COBOL programs.)

I imagine that your VAX COBOL programs are still replete with system calls, etc., which will need to be converted either to standard COBOL or into equivalent Windows/Linux system calls. The best way to deal with this is to provide a 'system layer wrapper' into which you isolate the OS-specific calls so that your mainline COBOL is not polluted with OS-specific calls.

We are currently faced with the prospect of replacing or rewriting. Replacement will be a long drawn out project...

If the COBOL portion of the application is as significant as you imply, it still represents significant value that can be reclaimed.

Tom Morrison

http://www.liant.com

 

[Truusvlugindewind]

Impact analisys can be very straightforewarth. Just tell your compiler to reject everything which is not ANSI85. Then recompile some big & complex programs and you'll get an impression of what is waiting...

Prepare yourself for:
- screen I/O
- calls to system functions/API's
- file assignment (hardcoded PATH? do you use versions?)

 

[AJC246]

Apologies, I work with h11tsr and may be able to clarify a bit.

The presentation programs are written in Fortran/Pascal/32 bit macros and communicate with terminals using 'mailboxes'. On the Vax everything is a file so the 'mailbox' is created, opened, read from, written to, etc. IO routines, forms package are the above mentioned Fortran/Pascal, etc and the application programs are written in Cobol. There are a lot of OS specific RTL and System Service calls in the application programs. So the issues are:

1) Converting existing forms bearing in mind that the
code for forms development package may not be
available and would use OS specific routines to
communicate with the screen (the mailboxes).

2) Replacing the 'mailbox' system service calls.

3) Converting the application programs, replacing any
system service calls. (This will be easier as most
of the system service calls access system
information like environment variables, etc.)

 

[fredericofonseca]

You really need to give more information.

As Tom mentioned, whether the COBOL programs are called from the Screen interface or whether they call it themselves will have major impact on the conversion.

Not sure if possible, but if you could give us a small example of a program and corresponding screen(s) and how it is invoked may help us to see other implications.

And what Truusvlugindewind said should also be attempted, as it will highlight many errors that you may not even be considering at the moment.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

IO routines, forms package are the above mentioned Fortran/Pascal, etc and the application programs are written in Cobol.

then

Converting existing forms bearing in mind that the code for forms development package may not be available and would use OS specific routines to communicate with the screen (the mailboxes).

A lot is being left to the imagination here.

You really need to give more information.

AJC246 and h11tsr ---

I understand that you might be at a very early stage in your conversion, and are just looking for ideas. Already I can infer that, from the architectural standpoint, your screen handling and your COBOL backend are fairly loosely coupled. Is my inference correct? If this is indeed true, then your COBOL legacy code is probably quite valuable, despite the VAX-specific calls (which can be replaced on a functional basis).

You might want to consider replacing your screens with HTML forms, and using a browser-based strategy. Your interfaces with your COBOL application could be converted from 'mailboxes' to XML documents. (Again, this is based upon a correct inference about the COBOL being loosely coupled.) This would give you the benefit of using open standards that have wide industry support, moving your legacy away from the proprietary chains from which you are seeking to move. It is quite possible to convert your COBOL applications into SOAP-based modules (SOAP is a specific form of XML document which supports loosely coupled remote procedure calls), making them totally independent of the presentation logic of a client.

However, you folks need to open the kimono a bit if you want anything more than vague hints. There are some real pros on this forum that can offer real help, but, like most things, you will only get out of this forum in proportion to your input...

Tom Morrison

http://www.liant.com