Starting With the PACBASE Generated Code
The COBOL code generated by PACBASE is totally unstructured, up to a point where it is clearly unreasonable to maintain as it is. However, it does accurately represent the expected behavior of the system, as it actually runs in production.
Raincode’s PACBASE migration facility takes this source code, and improves its technical properties through a number of behavior-preserving transformations, until the code becomes similar to what a human programmer would have written in the first place, and can thus maintain efficiently.
Raincode’s PACBASE migration solution is based on 130 atomic transformations. Each one of these transformations address a single issue
These transformations are kept as simple as possible, so that they remain easy to test, easy to debug and easy to explain.
The power of the migration engine comes from the combination of these 130 elementary transformations. They are applied repeatedly, each pass possibly enabling other transformations, until no more transformations can be applied.
The transformations performed by Raincode’s PACBASE migration facility aim at improving technical quality, as defined by the following 3 axes:
The chart below shows the reduction in the number of GO TO and PERFORM THRU statements:
GO TO statements
PERFORM THRU statements
The amount of code is also impacted by the transformation, with a reduction ranging from 10 to 55% depending on the case at hand (the lower the better).
Lines of Code
Other figures are produced, showing the overall improvement in quality (the lower the better):
In addition to these qualitative improvements, the runtime performance of the migrated application will improve as part of this migration process, up to as much as 15% of the CPU utilization.
Streamlining the Testing Process
Testing the application program by program, is dramatically inefficient, up to a point where it can put the economic justification of the whole project in jeopardy.
By taking advantage of the automated nature of this transformation technology, one can improve the accuracy of testing while reducing its cost by orders of magnitude.
As a result of the migration process, a prioritized list of programs is produced. This list is divided into slices of increasing size, and sorted by order of decreasing complexity; understanding of course that complexity here refers to the transformational complexity as opposed to functional complexity, which may very well not be correlated.
- The first, top most slice, covers most of the complexity of the restructuring facility. By testing these as extensively as possible, one leverages on the fact that the transformations tested here are used throughout the portfolio, which is under consideration. Since this first slice is limited in size (typically 10 to 20 programs), it can be tested very thoroughly, using any testing technique available today (white box, peer review, etc.).
- After this initial slice has been tested successfully, the next slice, significantly bigger (50 to 100 programs), can be tested in a simpler setting than than was the case for the first slice (peer review may be dropped, for instance).
- The third slice (500 to 1000 programs) can then be tested with shallow testing only, as the most complicated transformations and combinations have already been tested extensively.
- After that, one can move chunks of 5000 programs to integration testing and production in a matter of days.