The PACBASE migration solution provided by RaincodeLabs allows organizations to maintain the value of large PACBASE portfolios in a risk-free migration project. The legacy application is then free from any dependency on any proprietary tool or technology. PACBASE Migration offers:
- A 100% automated migration solution, from PACBASE to native COBOL
- Proven in production
- Guaranteed functional equivalence
- No performance loss
With more than 10 years of development on a proven technology, RaincodeLabs is the leader on the market. Over 200 million lines of code, and several large accounts which already have been migrated, make RaincodeLabs the only player to master PACBASE migrations in production.
The solution of RaincodeLabs does not provide any new technical dependencies. RaincodeLabs is also tailored to the customer environment, allowing them to customize according to their requirements or needs.
And thanks to its high level of automation, it can deal with the biggest portfolios in a cost effective way, and have them migrated in months rather than years.
- Supports all versions of PACBASE, all platforms, all databases;
- 100% fully automated (Not 99, or 99.99, but 100%!);
- Produces structured, readable and maintainable COBOL code;
- 100% functional equivalence guaranteed;
- Allows for multiple iterations to tune the result’s quality to the company’s specific requirements.
- Proven in use – this technology has already been applied to over 200 million lines of code;
- Cost and quality – the level of automation allows for aggressive budgets and planning;
- Independence – as the migrated application can be easily rehosted. It only relies on de facto standard components for which replacement products are available on different platforms (CICS, IMS, DB2, etc.);
- Flexible process – without any freeze period during which maintenance must be suspended or duplicated;
- Scientifically designed testing process – an order of magnitude more efficient than the more conventional approaches.
PACBASE’s technical merits are impeccable. It is an efficient and rigorous development environment that has proven its ability to master complexity and ongoing changes over the years.
Even so, using a proprietary environment to maintain mission-critical applications induces a dramatic risk, such as, when the – sole – vendor of the tool changes its focus, or decides to terminate the product altogether.
To best address this concern, RaincodeLabs’s PACBASE migration solution induces no dependency. At the end of the process, the application does not depend on any additional proprietary component or tool, be it RaincodeLabs’s or anyone else’s. It produces standard COBOL code that can be maintained using standard tools available in a vibrant marketplace.
Going to standard COBOL also opens a number of options including:
- One can tap the COBOL market for more advanced needs than maintenance alone, to care for impact analysis, cross-referencing, quality control, etc.
- COBOL consultants are far easier to find than PACBASE consultants, especially in an outsourcing context
- COBOL systems can be rehosted to any target system, even if it relies on CICS or IMS/DC, as a wealth of emulation tools are available, thereby reducing the cost of ownership dramatically
- The database can be migrated if needed, using one of the many specialized service providers in this area.
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.
RaincodeLabs’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.
RaincodeLabs’s PACBASE migration solution is based on 140 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 140 elementary transformations. They are applied repeatedly, each pass possibly enabling other transformations, until no more transformations can be applied.
The transformations can be enabled or disabled one by one, together with additional parameters.
Transformation example – A simple case
In this example, only one transformation is applied
Transformation example – A complete case
In this example, all transformations have been applied. On the left is the original generated code from PACBASE, on the right the result of the transformation. The code is smaller, the intention is clear, all GOTO’s and labels have been removed.
Promoting Technical Quality
The transformations performed by RaincodeLabs’s PACBASE migration facility aim at improving technical quality, as defined by the following 3 axes:
The charts below shows the reduction in the number of GO TO and PERFORM THRU statements:
GO TO STATEMENTS
Percentage of GO TO statements in a coherent set of programs, on the original generated code from PACBASE, and then with different parameters. Raincode doesn’t introduce any synthetic variables.
Percentage of PERFORM THRU statements in a coherent set of programs, on the original generated code from PACBASE, and then with different parameters.
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.
PACBASE’s code generation introduces a lot of redundancy in the generated code, as many artifacts are repeated in hundreds or even thousands of programs. Centralizing these distributed components in copybooks removes duplicated code and improves maintainability. Along with that it also reduces the cost of ownership almost linearly hence the amount of the code is drastically reduced.
The amount of code under maintenance can shrink by as much as 30%, in conjunction with the size reduction resulting from the code restructuring.
This centralization is performed by the clone detection process, which goes through the code, and identifies components that can be represented by plain COBOL copybooks, possibly with parameters.
Macros and Segments
In addition to clone detection, which applies to the entire portfolio after transformation, PACBASE macros and segments are dealt with specifically at the very beginning of the process. Data structures referring to PACBASE segments, and code fragments expanded from PACBASE macros are recognized, and replaced by native COBOL copybooks as a preliminary phase, so that these components, which are so essential to the PACBASE way of designing systems are centralized in a recognizable fashion. This allows ongoing maintenance to keep a full trace between the original PACBASE artifact and the resulting COBOL code.
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 30 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 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.