Hi, my name is Mario Mees, and I work here at Anubex. We are modernization specialists migrating mainframe applications to the cloud.
Today I wanted to talk a little about “inherent modernization”.
Before we can talk about this, let’s go one step back and allow me to explain briefly how we work:
We typically take all the artifacts of an application – or for that matter a mainframe – and convert them into native technologies on the new platform: this means languages such as COBOL, Assembler, PL1 or Natural get transformed to Java or C#, and data stores such as VSAM or Adabas get converted to relational databases.
Of course, to make this all feasible and manageable, there are two very important principles:
1) This entire process is automated, and this means: the conversion and the testing are automated;
2) The migration is “like-for-like” or “iso-functional”, meaning that the application will behave, and look and feel exactly the same as before, once it is executed in the cloud.
During the migration process, we also modernize as much as possible within the two just mentioned principles: this is called “inherent modernization”.
So, if
1) it can be automated, and if
2) it produces the same result: we will modernize.
Let me share a few examples.
(Example 1)
On the code side, it is pretty obvious that an awful lot of inherent modernization takes place when transforming for example a 60 year old procedural language such as COBOL to an object oriented language such as Java or C#. Suddenly, the applications – still functionally equivalent – will use object oriented paradigms!
And, admitted that the result will never be as object oriented as when written from scratch, it is a fantastic head start to move to these modern languages in a planned and controlled way, e.g. by using gradual introducing re-factoring approaches.
(Example 2)
The same applies to the scripting language when z/OS Job Control Language, or JCL for short, gets converted into a modern scripting language such as PowerShell for example.
Imagine, finally one is not dependent any more on languages that have not been taught in most universities since a few decades!
(Example 3)
Let’s continue with a simple example on the data side: Adabas (a pre-relational database) does not know the concept of a date or time field. When converting Adabas files to a relational database, we can easily convert the date to real date and time fields in the RDBMS …. Assuming the dates in those original fields are indeed valid dates of course.
(Example 4)
Or a VSAM or Adabas file with repeating groups in the record structure: when converting to a RDBMS, we can normalize this into separate tables or records. Actually, we can reconvert at any time and normalize and de-normalize as much as you want.
(Example 5)
I wanted to end with one last example, this one is from the user interface, or UI side. If the front-end of the application are still green screens, or 3270 screens, these can be converted so they can run in a terminal emulator – needed if there is a lot of screen scraping – but ALSO into HTML running a browser. Again, this is inherent modernization.
We would be happy to provide more information. Please have a look at www.anubex.com!
