Eranea : solution for Cobol to Java transcoding (100% automatic and strictly iso-functional)

Eranea's technology for Cobol to Java transcoding

distinctive features

July 4th, 2015

Table of Contents

1.Preamble..................................................................................................................................................12.Introduction.............................................................................................................................................23.Eranea's solution.....................................................................................................................................2

3.1.Methodology...................................................................................................................................33.2.Technology......................................................................................................................................6

3.2.1.Transcoding.............................................................................................................................73.2.2.Runtime framework.................................................................................................................83.2.3.processing cluster.....................................................................................................................93.2.4.Development environment.....................................................................................................11

1. Preamble1. This document uses “Cobol” for the sake of brevity because it is the most common case but

reader should understand “each legacy language processed by Eranea” each time he sees “Cobol”. Similarly, we focus hereafter on mainframes (IBM machines equipped with z/OS) as they produce the most attractive business cases / ROIs , but we've already completed projects starting from other systems (Unix, AS/400, etc.)

2. Similarly, the new Java application is most oftened installed on x86 hardware (Intel Xeon processor) powered by Linux. It is currently the most efficient platform from price / performance standpoint. But, we already completed PoCs and projects where target platform was different : MS-Windows, UNIX, z/Linux, z/OS itself, etc.

3. The details hereafter can be visually illustrated by our slides accessible at http://www.eranea.com/presentation Check out slides beyond page 35 if you want to get a flavour of the extensive tooling that we supply to make the core technology attractive, flexible and efficient : 40+ screenshot showcase various services of the full solution.

4. For any additional information that you need or any question that you have, send an email to [email protected]

5. We can very rapidly do a Proof of Concept (PoC) on your application as well. Just, get in touch !

July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 1 of 11

mailto:[email protected]

http://www.eranea.com/presentation

2. IntroductionThis document describes the key distinctive features of Eranea's technology / solution for transcoddng Cobol / 3270 to Java / web when compared to competition:

• 100% automation : the legacy code is transcoded to Java and the UI is moved to web/html fully automatically (no human intervention at all) and very fast (> 1 million lines per minute). Consequently, the transcoding can be done again and again as needed (over 20 times per day in some of our project at no additional HR cost. It is part of our migration methodology to do it at least once a day (in fact many times a day) to generate a Java version on functional par with lastmaintenance on Cobol version

• strict iso-functionality : the generated Java code does exactly what the original legacy code is doing, to the “very last bit” for all computed and displayed results. This is critical in achieving aprogressive and riskless approach. Users still working on the legacy and users already transferred to the private cloud share the results of their activity and cooperate as they have always done : via storing and retrieving the data through a single and unified database.

The positive impact of these features on migration are detailed below.

The combination of those 2 features is specific to Eranea's solution. It delivers all the advantages described hereafter in order to achieve a very fluid and riskless migration.

Additionally, the transcoding to Java and html/javascript delivers massive modernization : legacy programming language (Cobol) is replaced by Java, “green screen” interface is replaced by html/javascript, proprietary platform is replaced by Linux. Further modernization potential in unleashed for the subsequent manual maintenance via the use of Java and html/ajax as new programming environment.

Last but not least, this migration delivers huge savings : usually over 85-90% of initial costs when the starting point is mainframe and the target is x86.

It is a distinctive feature of Eranea's solution to be able to deliver both huge savings and massive modernization at once.

But, additionally, the path to destination platform (riskless, fluid and incremental migration) is probablyas important as the target platform for the CIO when decision to transform the system is being made.

3. Eranea's solutionAccording to the size, complexity and criticality of the core IT system of a large corporation, a brutal migration (“Big Bang”) is clearly doomed to failure and consequently out of scope.

Based on this assumption, Eranea has developed its specific technology and methodology: we propose a migration path relying on total absence of risks and on complete incrementality in the process of mainframe offloading / workload transfer.

At the same time, this methodology allows further functional evolutions of the system while transfer to Java is under way by allowing continued maintenance of Cobol source code throughout the entire migration.


For end-users, the strict iso-functionality of the new Java system brings an essential positive impact: they can switch from the old to the new system without any need for additional training as everything (structure and position of fields, input / navigation keys, inter-screens chaining, etc.) remains absolutelythe same.

It is key in the flexibility of the migration especially when external users are involved. In addition, this absence of additional training contributes significantly to lower costs of the project for all parties.

At the end of migration, developers can pursue their daily programming activities to maintain the new Java source code without any loss in productivity as they find again, in this new Java source code, all the program structures, algorithmic and syntactic constructions that they were familiar with.

Additionally, they do those activities in a much more productive environment with state-of-the-art tools: IDE Eclipse IDE, Java QA component, etc.

3.1. Methodology

Eranea has developed its technology in order to reach an optimal methodology for migrations : incremental, flexible and without risks.

It is based on the use of the mainframe database (DB2 for example) as « pivot » for communication and real-time collaboration between old (Cobol version) and new (derived Java version) systems.

Our tools allow for a migration :

• 100 % automatic : the original source code source is transformed towards Java / JEE and html/javascript without any human intervention at all. Such human interventions are unrealistic when matched with volume of source code to be processed, especially if they have to repeated on a recurring basis to match the daily (see below) transcoding process. 1% of manual changes would mean 10'000 lines changed per million of lines of source code. It would be clearly intractable over the course of the incremental migration !

• strictly iso-functional : the Java code produces the same results « down to the bit level » as the original Cobol code. The algorithms and the way they are coded are also rigorously preserved (high numerical precision, rounding rules, etc.) in the generated Java code. Consequently, results, stored in the database or displayed on screen, are fully indistinguishable whether they are computed in Cobol and Java. Regarding the UI, its ergonomics and structure is fully identical in its resulting html/ajax form: same fields in the same screens, same keystrokes to enter values and same chaining across screens. [Of course, UI will be changed recurrently whenmigration is over in order to leverage all browser capabilities]


migration via full automation and strict iso-functionality

From these 2 fundamental characteristics derive numerous advantages of this methodology :

1. permanent functional equivalence : the full automation allows to regenerate a new Java version at no additional cost as soon as any change is made on the original Cobol version. Consequently, the new Java system can be updated exactly at the same time as the Cobol system gets updated: both systems remain permanently functionally equivalent as long as they need to run in parallel.

2. continuity of evolution : the previous point allows for the continuation of maintenance on the original Cobol system, while migration is running, as law, business changes, launches of new products, etc. impose software changes. This continuity is very important when the incrementality of the migration is leveraged to its maximum (up to several months in some projects) for safety or size reasons, thereby extending the duration of the project.

3. parallel & collaborative operations : the transcoded Java application is connected to the DB2 database of the original system on z/OS. This database serves as a pivot as well as a real-time collaboration vector while the migration is running.

The results produced by the old Cobol system and those produced by the new Java system cannot be distinguished. Consequently, as a common non-duplicated database is used to store the results of computations done in either one of the 2 systems, users share the results of their work and collaborate in the exact way as they were doing it in the original system alone: through the information collaboratively built then stored in the database.

The database used for this collaboration is, consequently, the initial one, as long as migration is not terminated. When migration is finished and when database replacement (as part of mainframe full stop) is a target, the database can itself be migrated to an open system : it is,


generally, a quick, riskless and easy achievement as the iso-functionality between platforms for the database of a given supplier is usually extensive: for example, regarding IBM, DB2 for Linux is totally iso-functional to DB2 for z/OS. But, a full OSS stack can also be implemented by replacing DB2 by PostgreSQL.

When asynchronous messaging (like MQ Series on z/OS) is also used, the same technique is applied : the central messaging server remains on the mainframe throughout the entire migration. It is shifted to Linux at the end of project when all of its customers have themselves been moved to Linux already.

4. incrementality of migration : the previous point allows for a very incremental migration. For the system as a whole, the results of a given processing are identical whether executed in Cobol or in Java. As the database is unique, it is then irrelevant whether this processing gets executed in Cobol or in Java: database content is identical at the end of the transaction. Consequently, it becomes possible to move each interactive user or each batch processing fully independently from the others. These moves can, then, be defined according to constraints or objectives external to the migration project itself. The speed of project execution can also be fully adapted to the current operational context of the customer: the flexibility of progressive migration can be leveraged to maximize project efficiency.

5. absence of risks : the progressiveness of migration allows for total elimination of risks because users can switch on an individual basis to the new system. It needs initially only a few “pioneers” to validate each migrated component / sub-application: their daily activities are used to validate the migration. This doesn't even incur any productivity loss for them as those pioneers share the same database as their colleagues still working on the old system. Then, the bulk of the crowd can also come through successive waves of ever increasing size as confidenceon the system is acquired. It is the technique of “continuous small steps forward”: it induces some duration but bring much bigger guarantees for success.

6. continuous testing : the level of risk is further reduced by the implementation of an automated test system. As a matter of fact, the strict iso-functionality allows for a “mechanical” validation of the system.

Reference scenarios are captured on the old Cobol system via the 3270 interface. Then, they canbe replayed automatically on demand on the new Java system via the html/ajax interface in order to check the equality of results, both on screen and in database content. The old Cobol system can, then, be seen as “live specifications” as long as it exists : recurring comparisons (excuted automatically after the transcoding) against its results demonstrate the non-regression of the Java system as it as regenerated daily to incorporate very last functional maintenance.

Consequently, the simultaneous updates of Cobol and Java systems mentioned above can be validated ahead of time in order to maintain quality of service. In fact, these tests validate both the Cobol (against its previous versions) and Java system (against the current Cobol version).

Those unit functional tests can also be used for performance stress tests when several instances get executed in parallel in order to guarantee level of service under peak conditions.

7. minimal increments et investments : in absolute terms, only a single x86 server (or virtualizedinstance when it matches SLA requirements) is necessary to host the transactions or jobs


migrated first. The initial investment cost is then absolutely minimum. Also, servers or virtualized instances corresponding to further growth of migrated system can be acquired and installed one after the other when needs for more power arise. Clearly, they can be of the same kind as those already used within the existing server farm.

8. maintainability : the Java source code generated from the original application is aimed to become the new reference source at the end of the project when Cobol gets abandoned. Consequently, Eranea made very significant investments to bring its readability and maintainability to the highest level.

Additionally, important investments have been made by Eranea to simplify the switch of developers to their new source code even if they are not Java experts: algorithms and syntactic constructs have been preserved to the maximum in order to make developers “feel at home”, to ease their transition and to easily transport their business competences (their most important competences !) in source code from which they know and master structure.

Eranea deliberately chose to maximize the productivity of developers in their new environment and their support to the project (as they see their job safe !) rather than to maximize the orthodoxy of generated Java from an object-oriented perspective : the resulting Java is perfectly valid but favors the original mindset of the developers. Pragmatism has been put in front !

In fact, it would be counter-productive and probably even unrealistic to dump millions of lines of massively restructured code over the developers: they would, at best, need lots of time to get productive again and, at worst, get definitively lost in this newly structured source code when its only purpose is to better match the canonical rules of object-oriented programming.

3.2. Technology

The technology of Eranea is made of 3 separate domains :

• The tools for transcoding, used as long as Java has not fully become integrally the new reference language for the migrated application.

• The runtime framework, used during and after the project, as long as the Java code makes use of services providing iso-functionality or emulation as delivered by those libraries. It disappearswhen source code has been heavily maintained by developers to leverage Java / JEE to its maximum.

• The IDE components: Eclipse plugin (or other IDE) allowing efficient editing of Cobol as well as efficient access to functions of software lifecycle management.

Eranea has developed internally 100% of its technologies for transcoding, runtime and development. The third-party libraries or components on which it relies are among the most famous components of the Open Source world. Our solution clearly offers maximum guarantees for rock-solid quality, long-term sustainability and adaptability.


3.2.1. Transcoding

transcoding system

In order to leverage all the key advantages of the solution described in previous section, Eranea installs,for each project, its transcoding system (see scheme above) in the premises of the client. It is mainly composed of :

• a software repository continuously fed by the legacy system with the evolutions of Cobol sourcecode and Java source code produced by the transcoder,

• a “Continuous Integration” (CI) engine responsible for scheduling and executing all automated tasks during the project :

continuous integration : synoptics

◦ acquisition of Cobol source code from legacy system and storage in the software repository,

◦ structural / syntactic analysis and package-suited structuring of Cobol source code,

◦ transcoding Cobol → Java,

◦ Java compilation,

◦ Java packaging Java : war, ear, etc.,

◦ testing the Java packages for non-regression,


◦ rollout on test and production systems.

• a capture and execution system for the 3270 <> html/ajax comparative tests. As a matter of fact,this system is :

◦ part of the application NeaControlCenter (see below) for its interactive part,

◦ scheduled by the CI engine (see below) for its batch part (recurring non-regression tests).

• a relational database storing permanent information related to all those tasks :

◦ code-mining (Cobol and Java) analysis reports: errors, suggestions for improvements, etc.

◦ definitions of automated tests reports about their successive executions,

◦ journals of all tasks executed by the CI engine,

◦ logs and miscellaneous informations collected from live systems.

• the NeaControlCenter application allowing :

◦ efficient and advanced access / query of the database for all information above,

◦ direct manual triggering of tasks also possible on demand: transcoding, rollout, etc.

◦ access to inventory of software assets of the customer (application list, programs, copy books, …) with sophisticated query capabilities: full-text, cross-references, coverage per unit text, etc.

The best practice is to host each of the above components (software repository, database, CI engine, application Integrate) on a dedicated Linux instance, all of them possibly virtualized on a single physical machine.

3.2.2. Runtime framework


combintation transcoder + runtime

Several libraries (delivered as jar files) compose the execution framework named NeaRuntime. They provide the services of iso-functionality (preserving initial Cobol and z/OS transactional semantics) andemulation (transaction monitor, UI management, etc.) of the original environment.

Those libraries are systematically integrated to the Java packages (war, ear, etc.) corresponding to transcoded applications and built automatically by the CI engine.

They are at the end of the project quite heavily used by the generated Java code.

But, as manual maintenance happens over time, their importance decrease progressively to reach total disappearance when source code have been heavily reworked by the developers now fluent in Java and no longer needing Cobol-like constructions to feel comfortable.

3.2.3. processing cluster


processing cluster architecture

For system operations efficient and reliable at large scale, Eranea proposes the architecture of a multi-stage “processing cluster”. This cluster is the host of the transcoded application. It is updated automatically and recurrently each time when a new version of the application is generated : this is all done via ad hoc jobs run on the CI engine, part of Eranea's transcoding factory.

This cluster relies on the combination of the most renown, efficient and reliable OSS components like Apache, JBoss / Tomcat, Linux and its high-availability components, etc.

Through their smart combination it is possible to deliver a system as reliable and efficient (performances) as legacy systems to a fraction of their cost. Eranea proposes a 3-layer architecture :

• unification : the first layer hides all other machines /instances behind in order the present the full cluster as a single an very reliable web server with a single IP address

• distribution : based on Apache and ad hoc plugin to obtain dynamic feedback about availability and load on back-end Java application server (Tomcat / JBoss / etc.), this layer receives all requests from end-users and distribute them according to chosen policy to back-end Java servers.

• processing : this layer really does the job of running the transcoded legacy programs. The Java servers at this layer are clustered / isolated to reflect organizational constraints (per branches of a large bank, etc.) and provide very high availability via distributed data caching / replication provided by standard caches available in OSS world (Infinispan, etc.). All instances in this layerremotely access the database hosted on the mainframe during migration and later on on a dedicated database server (possibly clustered too).

This architecture is a replica of the system architecture of the largest web shops (Google, Twitter, Facebook, etc.) which must sustain workloads much bigger than internal IT of any large corporation. So, we can confidently assert that they can cope with the migration of any proprietary legacy system.


Additionally, their increment for further horizontal growth is very tiny : the cost of an additional x86 server. Not to mention that we usually don't run on bare metal but rather in a virtualized environment providing room for further flexibility in growth.

Finally, being full open source, this software architecture is extremely cheap (up to totally free – as in “free beer”), so all software components can be replicated as needed, without any constraint from the cost or licensing sides, to cope with the most stringent environments.

And, as those components are heavily used by the “web stars” mentionned above as well as a very largeadditional community, they benefit continuous improvements.

By “standing on shoulders of giants”, Eranea can deliver a rock-solid, efficient and extremely cheap operational architecture to its customers.

This is clearly out of reach for competitive migration solutions based on their own proprietary architecture that does not benefit from the efforts of a community around the permanent improvement of common commodities.

3.2.4. Development environment

An Eclipse plugin (other IDE also possible) is installed on the workstation of each developer in order toextend the standard Java functions with easy access / view / editing / transcoding of Cobol source code during and after the project as long as original Cobol programs are needed.

This plugin also allows easy and efficient access to functions for software lifecycle management, that can be supplied either by the client's platform or by Eranea's one.


Eranea : solution for Cobol to Java transcoding (100% automatic and strictly iso-functional)

Technology

Transcript of Eranea : solution for Cobol to Java transcoding (100% automatic and strictly iso-functional)