Cobol Research (was: Reverse Engineering a COBOL program)


gwlemyre@xxxxxxxxxxxxx wrote:
Get in touch with Niels Veerman at http://www.cs.vu.nl/~nveerman/

Review one of his articles, Revitalizing Modifiability of Legacy
Assets, at
http://portal.acm.org/citation.cfm?id=1044313&dl=ACM&coll=ACM
or http://portal.acm.org/citation.cfm?id=873598&dl=GUIDE&coll=GUIDE



Thanks for the advertisement Grant.
I would like to take this opportunity to draw this community's attention to our work.
Our research group at the Vrije Universiteit Amsterdam, which is a member of the Cobol Committee (ISO/IEC JTC1/SC22/WG4), is doing active research on Cobol. Our Cobol portal can be found here: http://www.cs.vu.nl/Cobol/
The research includes grammar engineering and automatic code transformations (analyses and reliable code modifications).
By adressing industrial applications, we work on techniques to preserve and support the evolution of existing legacy assets.

Some of our contributions are:
- A browsable VS Cobol II grammar:
http://www.cs.vu.nl/grammarware/browsable/vs-cobol-ii/

- A set of code restructuring transformations that extends and enriches the life of Cobol applications, and prepares them for future evolution (e.g. reuse, migration, integration, web-enabling):
http://www.cs.vu.nl/~nveerman/research/revitalizing/revitalizing.pdf


Our effort would not be possible without the active participation of the Cobol developers community, for instance, the people that read and post in this newsgroup.

To give an example, Grant, who posted the above message, was working on an evolved legacy application, which was initiated in the early 80s. Some parts of the system had to be reused, but the application's logic was severely intertwined, which made it difficult to identify and separate functionality.
We supported his work by restructuring the application into loosely coupled blocks of code, and he provided valuable feedback, which we used to improve our approach. A description of the case can be found here: (see figures 18/19 for visualisations of the particular application)
http://www.cs.vu.nl/~nveerman/research/minefield/minefield.pdf


We hope that we can all continue to benefit from the efforts that are done on both 'sides'. We see researchers that investigate more modern languages, like Java/C#, but applications written in these languages also suffer from the increasing complexity of evolving software, so these languages are no replacement for Cobol just for the reason that they would be 'easier to maintain'. The following presentation, held by a former member of the Cobol Committee, discusses Cobol as a research theme:
http://www.cs.vu.nl/Cobol/stop-bashing-cobol.pdf


The key is to keep Cobol applications in proper shape and up-to-date with new standards and insights, in a way that they can interoperate with other systems and allow to be adapted to the ever changing world in which they participate.
This way, Cobol assets are far from withdrawal and continue to provide crucial value to enterprises.


For comments, ideas and questions, do not hesitate to contact me by email.

With best regards,

Niels
nveerman@xxxxxxxx
.

Relevant Pages

  • Re: 3270 emulator?
    ... sometimes bad business decisions are made and there are ... consist of components developed in different languages (even OO COBOL), ... a major credit card transaction processor started moving off ... made into the new systems being developed, not into the legacy. ...
    (comp.lang.cobol)
  • Re: MicroFocus and Visual Cobol
    ... Why would you want to pay to have managed code from COBOL source? ... be a large amount of legacy code that people would want to run on ... Data Access Layers out from it. ... Management) that actually ensure performance and reliability, ...
    (comp.lang.cobol)
  • Re: MicroFocus and Visual Cobol
    ... Why would you want to pay to have managed code from COBOL source? ... large amount of legacy code that people would want to run on the Framework. ... .Net platform and languages grows, it will become increasingly apparent that ...
    (comp.lang.cobol)
  • Re: conversion from Microfocus NetExpress COBOL to Fujitsu netCOBOL.net
    ... investment in a Language that you are trying to move away from. ... better than ANY version of .Net COBOL. ... Legacy code ... applications. ...
    (comp.lang.cobol)
  • Re: MicroFocus and Visual Cobol
    ... Why would you want to pay to have managed code from COBOL source? ... run your COBOL code as unmanaged and get managed code from a free compiler ... large amount of legacy code that people would want to run on the Framework. ... ..Net platform and languages grows, it will become increasingly apparent that ...
    (comp.lang.cobol)