The steps of our approach are:

• Audit

• Code improvement

• Deployment strategy and simplification of Non Regression Tests

• User workplace

PACBASE benchmark analysis

The first step in the migration is to ensure that the PACBASE repository is well consistent with the programs in production. Indeed, the elements of the repository such as SEGMENTS and MACROS could have evolved over time without regeneration of user programs and a new generation of programs would not produce the same COBOLs generated.

It is therefore necessary to carry out an analysis phase to identify the programs with a deviation and if this deviation can cause a malfunction.

Indeed, for example, a segment having evolved by adding zones taken from an end filler, will not cause any malfunction on the programs generated with the old version.

This deviation is said to be compatible.

The compatibility study is fully automatic for SEGMENTS, and partially for MACROS which require manual analysis. At the end of the analysis phase, the programs are divided into 2 groups:

1 – Programs without deviations and Programs with compatible deviations

2 – Programs with non-compatible deviations

The programs of group 1 will be migrated from the current version of SEGMENTS and MACROS which will be transformed into COPY.

The programs of group 2 will be migrated from the version of SEGMENTS and MACROS having been used to generate them. An additional study will assess whether it is preferable to migrate to an extended COBOL or a COBOL using specific COPYs for SEGMENTS and MACROS in deviation.

 

Migration of PACBASE components

The second step of the migration consists in migrating the PACBASE objects into the new repository by producing a maintainable native COBOL code.

We carry out this operation by an approach of reconciliation between the code generated by PACBASE of which the behavior should be preserved because it is in production and the PACBASE source which contains the developer vision.

The strategy is to keep the logic of a PACBASE program in order to limit the learning of maintenance teams as much as possible.

Comments are reintegrated into the COBOL code.

The COBOL code restructured by replacing the GOTOs with IF / THEN / ELSE blocks. Block codes are kept as comments in the margin.

The code is indented in a standard way and extended in full page mode (programming beyond column 72) to better visualize the nesting of the FIs. The workstation will integrate support functions such as viewing IF ELSE ENDs of the same nesting level.

The instruction groups corresponding to technical functions generated by PACBASE, are replaced by a structured and more readable equivalent. The optimum is reached for programs in line with the PACBASE standard for which it is possible to identify a maximum of improvement patterns.

The Working Storage Section is redesigned to replace the extended SEGMENTS with a COPY REPLACING and delete all unused items.

For the programs of group 2 migrated with specific COPYs for SEGMENTS and MACROS in deviation, we insert comments intended for maintenance to propose a realignment with the standard repository during the next modification.

 

Deployment and testing strategy

In the case of a PACBASE exit project without change of platform, it is not necessary to migrate and certify all the programs at once.

It is common for many heritage objects to be very stable. It is not essential to migrate and certify them before the first maintenance. This makes it possible to smooth the certification burden over time. The migration load is very low due to automation.

To certify a program, we compare the executions of the original PACBASE generated program and the target structured COBOL program and verify that each instruction block has been executed the same number of times. The iso-functionality of the original PACBASE generated instruction blocks and their structured COBOL equivalents having been certified beforehand.

We will associate to each object of the configuration manager a status:

• Source (original generated)

• Improved

• Certified Improved

• Migrated

We can initially certify only the programs of the maintenance plan and smooth in time the certification of the other programs. The certification mechanisms will be integrated into the workstation under Eclipse.

In order to optimize the productivity of maintenance teams, we offer a development workshop using Eclipse and a set of plugins.

The workshop does not create adhesion with the migrated code which can be maintained without it but offers a set of functions facilitating the work of the developer.

The general functions of the PACBASE Software Engineering Workshop are reproduced in the form of plugins integrated with each other.

The workshop has a 3270 connector which allows programs to be compiled in the background or which enriches the COBOL development workshops on the market with which it integrates.

PACBASE Software Engineering Workshop Removal Solution

PACBASE migration to native COBOL.

Mainframe IBM MVS.

Mainframe BULL GCOS7.

UNIX Environnements.