Home > Archive > Cobol > May 2006 > Cobol Research (was: Reverse Engineering a COBOL program)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cobol Research (was: Reverse Engineering a COBOL program)
|
|
|
|
gwlemyre@earthlink.net 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?...dl=ACM&coll=ACM
> or http://portal.acm.org/citation.cfm?...UIDE&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/resea...evitalizing.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/resea...d/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@cs.vu.nl
|
|
|
|
|