[Info-vax] Real live example...

[Denys Beauchemin]

On Monday, February 20, 2023 at 10:30:54 AM UTC-6, Arne Vajhøj wrote:
> On 2/20/2023 11:14 AM, Jan-Erik Söderholm wrote: 
> > Den 2023-02-20 kl. 15:57, skrev Arne Vajhøj: 
> >> For a Cobol/VMS application there are multiple options: 
> >> 1) stay on Cobol/VMS 
> >> 2) change both language and platform like to Java/Linux (*) 
> >> 3) change just platform like to Cobol/Linux 
> >> 4) change just language like to Java/VMS 
> >> 
>
It has been our experience that changing the language of the application during a migration makes the whole migration project exponentially more difficult, expensive, long and risky.  It makes the whole thing a moving target that is incredibly difficult to manage.  One fun feature is that you’re always waiting for something to be migrated before you can run even just some parts of the application.  Another fun feature is that testing is complex because of the differences between the two systems.

Our long migration experience has confirmed that a tools-based, like for like approach is best.  We have developed tools that transform the OpenVMS version of a language to a Linux-compatible version of the language, where such a language exists on Linux.  We have a transformation tool for COBOL, another for Fortran, and yet others for C/C++.  For languages that do not exist on Linux, such as Pascal, we have a translator that converts the Pascal to C++, and BASIC to C.

Using our transformational tool for COBOL (or Fortran…) allows us to migrate the entire codebase simultaneously.  There is no waiting for specific modules to me migrated in order to start testing.  We can migrate millions of LOC of COBOL in just a few minutes.  When we find errors in the generated COBOL code on Linux, we adjust the tool, not the generated code, and then we process the whole codebase again.  So, when we fix one error, it is fixed throughout the entire code base.  We never want to have hand modifications performed on the generated code.

Using a tools-based transformation tool is the best way to preserve all the business logic built into the application over the years and decades.  There is no code freeze needed, this methodology allows for continuous integration of new and enhanced source code at any time.  The transformation tool produce COBOL code that can be compiled on Linux by native compilers such as NETCOBOL (only needs an inexpensive development license, no run time licenses required) and you have native executables running on Linux, no interpreter or simulator needed.  The executables will run a LOT faster on Linux than they do on OpenVMS.

Since all VMS features such as logicals, FMS, and DCL scripts and so on are supported on Linux, the migrated application runs on Linux, exactly the same was as on OpenVMS.  Testing is easy, it’s like for like.  A test script on OpenVMS runs the same way on Linux and must produce the same results.  If it doesn’t, the bug is fixed in the migration tool and the codebase get completely migrated again.  This migration just takes a few minutes for millions of LOC of COBOL code.  The entire COBOL code base is migrated at the same time so testing never waits for some component that hasn’t been migrated yet.

Once the application is migrated and is now running on the new platform, you can start replacing various components with components written in other languages.  You can do this at your leisure and not worry about big bang deployments.  The development and support staff remain very current because it’s the same code running on Linux. They learn the new Linuxy tools at their own pace as components are rewritten in other tools, but they can continue to support the COBOL code directly on Linux for as long as needed.
One important, often overlooked benefit of a like-for-like migration is that you do not have to retrain the users.  We have done this for banks, insurance companies, manufacturing facilities, and other places with hundreds or thousands of users and the application runs exactly the same way for them.  This makes deployment very easy, and your users are unaware of the change, except that it runs faster.