1. Eranea's technology for Cobol to Java transcoding
distinctive features
July 4th
, 2015
Table of Contents
1.Preamble..................................................................................................................................................1
2.Introduction.............................................................................................................................................2
3.Eranea's solution.....................................................................................................................................2
3.1.Methodology...................................................................................................................................3
3.2.Technology......................................................................................................................................6
3.2.1.Transcoding.............................................................................................................................7
3.2.2.Runtime framework.................................................................................................................8
3.2.3.processing cluster.....................................................................................................................9
3.2.4.Development environment.....................................................................................................11
1. Preamble
1. 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
contact@eranea.com
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

2. 2. Introduction
This 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 last
maintenance 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 a
progressive 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 probably
as important as the target platform for the CIO when decision to transform the system is being made.
3. Eranea's solution
According 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.
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 2 of 11

3. 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 absolutely
the 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 when
migration is over in order to leverage all browser capabilities]
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 3 of 11

4. 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,
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 4 of 11

5. 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 confidence
on 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 can
be 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 virtualized
instance when it matches SLA requirements) is necessary to host the transactions or jobs
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 5 of 11

6. 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 disappears
when 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.
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 6 of 11

7. 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 source
code 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,
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 7 of 11

8. ◦ 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
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 8 of 11

9. 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) and
emulation (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
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 9 of 11

10. 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 layer
remotely 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.
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 10 of 11

11. 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 large
additional 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 to
extend 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.
July, 4th 2015 © 2015 Eranea SA | http://www.eranea.com page 11 of 11