|
Here we explain how you can save a lot of time and money
by employing off-the-shelf CobolTransformer technology
in your Cobol reengineering projects.
Transformation Rules
When starting a Cobol reengineering/modernization/conversion project
(Year 2000 project, for instance), an organization has to solve
many technical and managerial problems.
Among technical problems, the hard one is to determine
a formal set of program transformation rules.
Rules such as:
For every data item description in which
USAGE is COMP-5 or BINARY and
PICTURE is X(n)
change PICTURE to 9(2*n)
These rules may be simple or they may be complicated,
you can establish the rules by yourself,
or you can hire Siber Systems or any other company
to help you determine what the program transformation rules are.
But once you have determined the transformation rules, you need
to decide how to execute them and thus make conversion happen.
Do you want to hire 100 Cobol programmers and make them
apply the rules manually?
Manual Conversion -- Just Say No
Many reengineering specialists today believe that
performing the conversion/transformation job manually is not the way to go:
-
Manual labor is prone to errors, even
when executing a formalized set of well-defined rules.
-
Automation of repetitive tasks is a way of
increasing productivity and decreasing costs.
-
Automatic conversion can be repeated as often as you want.
That is, if the original set of rules was incomplete,
you can adjust the rules and fire up the conversion tool one more time.
Firing up 100 Cobol programmers one more time is a much costlier procedure.
-
Modern and ancient Cobol programs are huge -- millions lines of code.
Oftentimes you just will not have enough time and money to
transform these programs manually.
Automated Conversion: Infrastructure
So it is likely that you decide to do an automated conversion.
Now you need somebody to write a conversion program --
a program that simply applies your conversion rules to the Cobol code.
As many IT managers who attempted automatic conversion learned,
there is a minimal set of components that one needs to write
a conversion program:
-
Conversion program needs to "understand" Cobol code.
Compiler writers call this process parsing.
Parsing Cobol is hard, but it is a fairly standard procedure
that is well defined through Cobol standards.
-
Usually Cobol program is parsed into an Expression Tree
which is a standard Internal Representation for programs.
So you would need a library of functions that
lets you browse and transform these expression trees.
-
After the program was parsed and transformation rules applied to the
Program Tree, the program usually has to be written out
as a human-readable and human-maintainable Cobol code.
Therefore, you need a good human-readable Cobol Code Generator too.
Conversion Infrastructure: Where to Get
Now the question is: where do I get a required infrastructure?
You may decide to develop this conversion infrastructure in-house.
But do you have time and money to do this?
Writing a decent Cobol lexer, parser, tree manipulator and
code generator will take anywhere from 3 to 5 man-years.
And this is time spent by expensive programmers that are
highly skilled in compiler technology.
Therefore if you decide to develop this infrastructure in-house,
your price tag will be at least $200,000.
Apparently, it is much cheaper to use off-the-shelf solution,
and Siber Systems CobolTransformer is the solution that you need.
CobolTransformer has it all:
-
Cobol Parser that parses 12 most popular Cobol dialects:
-
ANSI-74 Cobol
-
ANSI-85 Cobol
-
IBM OSVS Cobol
-
IBM Cobol/II
-
IBM Cobol SAA
-
Unix Cobol X/Open
-
MicroFocus Cobol
-
Microsoft Cobol
-
Ryan McFarland RM/COBOL
-
Ryan McFarland RM/COBOL-85
-
DOSVS Cobol
-
Wang (licensed separately).
Parser highlights:
-
Parsers for embedded languages:
DMS-80/1100 DML, EXEC SQL, EXEC CICS.
-
The parser is tested on millions of lines of Cobol code.
Extensive regression testing daily.
-
Comments preserved on a tree.
-
Full implementation of COPY REPLACING and REPLACE statements.
-
-INC statement implemented.
-
Option of inlining or not inlining Copy libraries.
-
User-defined error diagnostics routines.
-
An option of picking up smaller subtrees from the parser
instead of waiting for one big tree for the whole program.
-
Tree-based Internal Representation for Cobol programs
and C++ library to manipulate this representation.
Library highlights:
-
Constructors and Destructor.
-
Tree browsing: children, parent; set, add, delete, insert, find a child.
-
Print indented view of a tree for debugging.
-
Tree flattening (marshaling) and unflattening:
output tree to a file, or send it across the network.
-
Comments attached to tree nodes.
-
User-defined objects attached to the tree nodes.
-
Symbol Table for every Program.
List of all Definitions for a given Name.
-
Links from Use to Definition and from Definition to all Uses
for every Named Object.
-
Generate Fully Qualified Name for a given Definition,
or Shortest Unique Qualified Name for a given Definition.
-
Rename Named Object Definition and all its Uses.
-
PrettyPrinter that transforms our tree-based Internal Representation
back into beautifully indented human-readable Cobol program.
PrettyPrinter highlights:
-
Table-driven code generator.
-
No need to supply a whole generation table if you need
to customize code generation -- supply just a few entries that you want to change.
-
Every tree node knows its position in the generated text.
-
Customizable indentation step and indentation cut-off position.
-
Tabulation positions -- just like in your word processor.
-
Specify format of a tagging string put into columns 73 to 80 of the output line.
Proceed To
|
Summary 