cobol reengineering - IT

advertisement
COBOL REENGINEERING
THE SOLUTION PORTFOLIO GRANUM®
At a glance
The majority of programs running on large servers and mainframes are still written in Cobol. Through decades
of maintenance and changes the code quality decreased and became sometimes unreadable.
1)
With the solution suite GRANUM IT Modernisation offers a range of possibilities to optimize the Cobol code:
reengineering, refactoring, restructuring, formatting and remediation are only some of the most important
buzz words. The value of existing application systems is significantly augmented. Furthermore the programs
can be automatically segregated and used in in service-bus architectures.
 Code quality must be improved and made suitable to easier maintenance and extension.
T HE C HALLENGE
Cobol started in the early 1960s and was constantly
expanded and adapted ever since. Cobol programs
– often influenced by hardware requirements of the
„early years” – became more and more unreadable.
They often do not fit into modern strategic IT landscapes any more.
 In many programs you will find remains of old
code generators and pre-compilers. These reminiscences must be removed.
Young computer staff is reluctant to learn Cobol; it
deems them to be a negative issue in their
CV. Consequently companies are having
difficulties to find adequate personnel to do maintenance
and changes to those Cobol
programs. The way those
programs look today is not
very helpful, too. What can
you do?
 The code needs remediation: it is not homogeneous and badly structured. Scope terminators, the EVALUATE and other modern language elements were unknown
or just ignored in the old
days.
 Re-writing the programs
is far too expensive.
 A fully automated transformation into modern
languages is a fantastic alternative. But will the result really
fit into an OO-world?
 The existing programs often contain ten thousands of lines each. In this form you can’t even
think of putting them into a service-oriented architecture (SOA).
1)
 All modernisation activities must be affordable
and low-risk!
It is irrelevant, if you just
want to get on top of Cobol
maintenance
problems,
whether you plan a migration to OO-languages or if
you want to embed the application into a SOA: the programs need massive clean-up,
new structuring, improved formatting and
the removal of static dead code as well as
modularization.
THAT IS WHY GRANUM WAS DEVELOPED.
GRANUM, lat. for grain
2014-05-23
© Schierholz IT Modernisation GmbH
GRANUM_EN.docx
COBOL RE-ENGINEERING
 remove periods without semantic meaning
GRANUM Components
 introduce scope terminators
Like all other products of IT Modernisation,
GRANUM is implemented as a collection of Rules
and Rule Sets. These rules are written in IT-M’s
proprietary language SPL (Sourcecode Processing
Language) which is part of the RULAMAN®framework.
 replace unprintable (hidden) characters by literals und VALUE clauses
 introduce figurative constants in lieu of literals
or VALUE definitions
 transform intrinsic functions of different manufacturers
RE – R EENGINEERING
RF – R EFACTORING
Her are the
GRANUM.RE:
most
important
functions
of
 REMEDIATION. GRANUM.RE transforms language constructs, which are no longer supported or which will produce error messages in new
Cobol compilers into legal Cobol statements.
 REENGINEERING. GRANUM.RE re-structures the
code, removes branch instructions, introduces
scope terminators (END-clauses) and uses a set
of smart algorithms to produce a program,
which is well readable and which may as well be
positioned for a transformation into an objectoriented language like Java or C#.
 DIALECT ADAPTATION. There are more than
300 different, mostly incompatible Cobol dialects: versions and variations are shaped by operating system and hardware architecture or
just – by the marketing department.
In the course of migration from Cobol-68 to Cobol74 many statements or clauses were changed or
replaced by new constructs. The old formats are
mutually still supported by many compilers although they are not described in the language reference
manual
any
more.
GRANUM.RE can convert any Cobol dialect into any
other or move it to a “standard” Cobol.
Find here some more functions, some of them selectable as options:
 resolve so-called ”spaghetti-code”
 remove many or all of the GO TO instructions
 structuring into sections and paragraphs
 detect and dislocate subroutines
 transform IF-sequences and IF-cascades into
EVALUATE Structures
GRANUM.RF segregates large Cobol programs into
individually shaped small modules. To achieve this,
the developer places appropriate marks at paragraph or section boundaries.
GRANUM.RF will then perform the following:
 The marked parts are carved out of the primary
program and transformed into complete and fully functional Cobol modules („here: secondary
programs“).
 Data fields of the primary program being referenced by the secondary program are passed via
new definitions in the LINKAGE SECTION.
 The values of these fields are collected in the
primary program prior to calling the secondary
program.
 On return from the secondary program the
fields of the primary program are loaded with
the new values.
 The coding to connect primary and secondary
program is contained natively in the programs:
there are no runtime routines!
 Branch instructions which point from the secondary into the primary program are supported
by code which generated into both programs.
NB:
Too many of such branch instructions can
make the program logic difficult to comprehend. Consider using GRANUM.RE prior to GRANUM.RF to reduce or eliminate
branch instructions.
 The secondary program is “lean” i.e., it takes
over only those definitions which are really necessary. If e.g. data structures are needed because of REDEFINES, all unreferenced fields are
collated into single FILLER fields.
 remove static dead procedural code
 eliminate unused fields
2014-05-23
© Schierholz IT Modernisation GmbH
GRANUM_EN.docx
COBOL RE-ENGINEERING
The developer will have to supply the following:
1. Start and end of the future secondary program
2. The desired name (PROGRAM-ID) of the secondary program
3. Optionally a description of the new program
as Cobol comment
4. Name of the developer
The new primary and secondary programs are immediately functioning. As a whole together with the
primary program they will perform the functionality
of the former monolithic program.
When applying the appropriate granularity such
modules are perfectly suited to be used as services
in an ESB (Enterprise Service Bus).
 Define decision tables in some short hand notation
 Produce code using macros
Those products are often still in production because
you cannot transform the related code sequences
error-free and without risk into native Cobol.
Another issue is the maintenance of programs
which were generated by 4GL-compilers like CSP or
PACBASE. The programs had to be maintained on
the basis of the generated code because the original 4GL language compiler was no longer available.
All of these subjects are addressed by special
GRANUM remediation tools included in the
GRANUM-Suite.
In actual customer situations we developed the
following special GRANIUM products:
FO – F ORMATTING
 Elimination of SWT01 (program generator)
In the old days programming standards were sometimes not known or they existed only rudimentary.
When such standards were introduced at a later
stage there was no time to overhaul the existing
code.
 Elimination of VORELLE (decision table)
Furthermore every programmer had his own ideas
of indentation and formal structuring.
We are constantly increasing the number of tools.
With GRANUM.FO you can define Cobol standards
easily and re-format existing programs fully automated. Of course this will not influence program
function in any way.
The programs gain a lot of readability and maintainability.
 Extract Cobol data structures from programs
and transform them to data base definitions
Ask us: based on the existing GRANUM components, RULAMAN.SPL allows creating new
Remediation Tools with relatively small effort.
M ORE GRANUM APPLICATIONS
We want to emphasize two other interesting possibilities:
GRANUM R EMEDIATION T OOLS
In the past decades many products were used within Cobol to
 Increase developer productivity
 Produce uniform code structures
 Solve standard problems of processing such as
group control, intermediate sums, sorting,
printout of listings etc.
 Produce documentation directly from the
source code (passive documentation systems)
 Document maintenance activities
 Place change management information right in
the source code
2014-05-23
 Remediation of PACBASE Cobol
1. Consider assembler programs which were transformed by the IT-M product A2C and successfully tested. Especially large programs can be processed further by GRANUM to increase their
value. After refactoring with GRANUM/RF logic
modules within the former assembler program
may now be segregated into separate service
routines (this is the so-called SOA-fication).
2. Preceding a fully automated or semi-manual
conversion from Cobol to Java or C# the code
must be transformed along certain rules. Otherwise the migration to Java or C# will produce
code which you would never want to go in production. When developing GRANUM we have
taken such possibilities into account.
© Schierholz IT Modernisation GmbH
GRANUM_EN.docx
COBOL RE-ENGINEERING
The advantages of modernisation with GRANUM®
Related to the above challenges, resulting from the huge number of Cobol programs and – more important –
from the value of the business logic contained therein, GRANUM offers a number of elegant answers.
 Remediated Cobol code, which is well readable and clearly structured, which has no leftovers form old
technologies or habits of the past century will also be understood by young computer staff. They will have
less problems maintaining and extending it.
 This may help solving the personnel problem for application development of classic IT shops.
 The automated transformation from Cobol to an OO-language is possible, if the code was positioned accordingly. Programs which were processed in this way are much easier to be maintained and run without
pain within a clean OO-environment.

Note:
We suggest a pragmatic approach when talking about the migration from Cobol to OO: you should first verify which
programs are suitable for such a migration at all: it does not make sense to transform millions of code lines from Cobol to Java
or C# without further examination. Some programs make more sense in Cobol; others are well suited for the migration.
 Existing Cobol monoliths are chopped automatically into small modules. These modules can then be used as
external subprograms or as services within a service-oriented architecture.
 Code which was remediated and improved in many ways is easier to maintain; debugging and even program changes or extensions will be “cheaper” to obtain.
 The dependency from antique third-party products like pre-compilers, code generators, macro systems,
decision table generators etc. is fully removed. As some of these products are still subject to licensing contracts there is an interesting potential for saving.
 Even more important is to get rid of the risk which arises from products which went out of service long time
ago or where the originating company disappeared from the market.
 The risk of transformation is minimal, because human errors and fatigue are non-existing.
 A code freeze is not necessary, because the RULAMAN technology can convert millions of lines within
hours.
 The cost of transformation with GRANUM is only a fraction of a manual or semi-automated process.
You want to exploit the possibilities of GRANUM®?
We are offering GRANUM as a service with fixed price. This means we will process your COBOL code in total or
in packages.
We will agree on the precise parameters of the transformation with you in advance.
Please contact us regarding your reengineering requirements and needs.
Schierholz IT Modernisation GmbH
Übersee-Haus
Baumwall 5
20459 Hamburg
+49 40 8398 4130
www.it-modernisation.com
2014-05-23
© Schierholz IT Modernisation GmbH
GRANUM_EN.docx
Download