migrating legacy applications (cobol, pl/i) to java on z/os

Automated transformation to Java on z/OSOctober, 2015

http://www.eranea,com 2 / 21

Agenda

● Solution highlights● Proposal● Architecture perspectives● Conclusion


Solution highlights


Value proposition● Incremental system migration approach

– automatic legacy code transformation to maintainable and iso-functional Java

– no freeze of application maintenance during migration

– replacement by equivalent system / admin tools● Safe transformation process

– automated replay of test scenarios

– big-bang avoided through incremental safe steps– leverage on existing HA features : Data

replication, Sysplex, GDPS, etc.


Solution fundamentals● Iso-functionality: exact same results "to the last bit and

pixel" produced during execution

● Replacement of CICS+BMS, SDF, JCL/JES2, DFSORT, ICETOOL, IDCAMS, SCF, SDSF, …

● Interfacing with MQ, DB2, PdfLib, LDAP, SMTP, FTP, SOAP, REST, ...

● Live transactional data sharing: access to the same data sources during the transformation

● System tooling:

– industrialized and repeatable DevOps processes for continuous delivery and automated "hot" deployments

– advanced production monitoring / administration– build & source code management and development tools


Why iso-functionality ?

● Needed to guarantee the same results after transformation

● Critical to allow live sharing of same data sources between legacy and Java, enabling incremental migration

● Allows objective and quantified tests: all data produced by tests run in legacy (Cobol) and Java must be identical

● Transparency for end-users and other applications


Incremental migration

time

DB2

TP / batch

z/OS

DB2DB2shared data sources

TP / batch

z/OS CPs

TP / batch

zIIPs or (z)Linux

incrementalmigration users & jobs

maintenance in Cobolmaintenance in Cobol or Java

start end

TP / batchTP / batch(Java)

TP / batch(Java)

TP / batch(Cobol)

TP / batch(Cobol)

data sourcesdata sources

z/OS CPs zIIPs or (z)Linux


Tests automation● Online :

– automated screens and data captures on the original system

– automated replays and captures on the Java system– advanced automated comparison of screens and database changes

● Batch :– automated captures (files, database changes) on the original system

– automated replays and captures on the Java system– advanced automated comparison of produced data / files


Architectural options


Initial dependencies

TPM(CICS, IMS)

TP / batchApplication

data sources(DB2, IMS-DB, MQ, etc.)

z/OS(files, GRS, etc. )

LPAR

SY

SP

L EX

DIS

TR

IBU

TO

R

CF

Cobol5

1

2 3 4

datareplication

5

1 direct dependency

1 indirect dependency


Nota Bene● Next slides describe a limited proposition

of incremental migration steps

● Discrete stages described hereafter are excerpted of a larger palette of possibilities:

– Cobol <> Java direct calling capabilities– Java <> legacy interfaces (JNI, etc.)– accessors / gateways to legacy (CICS

CTG, IMS Open Connect, WAS Wola, etc.)


Pipelined transformation

...

start

end

time

completion

0%

100%continuousprogress

DMJava TPM WAS CLOUD Appl 1

Appl 2

Appl 3

At time t, different applications may: - use a different pipeline - have a different target - be in a different progress stage

DMJava WAS CLOUD

Java TPM WAS

DMJava CLOUD Appl N

Java: Cobol to JavaTPM: TPM on z/OS as Java containerWAS: WAS on z/OS as Java container

CLOUD: JAS on cloud as Java containerDM: Data migration (transformation)


TPM on z/OS as container

TPM(CICS, IMS, MQ)

TP / batchApplication (Java)



LPAR

SY

SP

L EX

DIS

TR

IBU

TO

R

CF

JVM (in TPM)

runtime

JCICS / JIMS JDBC JZOS


Achievements / benefits● Required operations:

– Cobol to Java– use of TPM Java APIs (JCICS, JIMS)– use of z/OS java APIs (JZOS)– use of standard Java data access (JDBC, MQ, ...)

● Benefits:– platform architecture unchanged– development in Java becomes possible– generate savings: CP → zIIPs


WAS on z/OS as container




LPAR

SY

SP

L EX

DIS

TR

IBU

TO

R

CF

WAS

runtime

JDBC JZOS



– Cobol to Java– replacement of legacy TPM by WAS with implementation in Java (Eranea's runtime features) of CICS and IMS APIs

– use of z/OS java APIs (JZOS)– use of standard Java data access (JDBC, MQ, ...)

● Benefits:– platform evolution (Sysplex):

● legacy middleware support → WAS support● unchanged services: scheduling, SDR, etc.

– Java portability– generate bigger savings: zNALC, additional CP → zIIP offload


JAS on cloud as container




LPAR

SY

SP

LE

X D

IST

RIB

UT

OR

CF

WAS

runtime

JDBC JZOS


Linux

instance SC

WAS or other JAS

runtime

JDBC

Private cloud

WL

MA

NA

GE

R

NB: Private cloud can also be on System z via zLinux, LinuxOne, etc.



– all actions for WAS as container

– design and implement a high-availability and high-performance transactional private cloud

● Benefits

– cost savings

– synergy: reuse of x86 Java platform (when it exists)

– new architecture: private cloud → state-of-the-art


Data migration (DM)

WL

MA

NA

GE

R

SC


Linux

instance

WAS or other JAS

runtime

JDBC

Private Cloud

RDB

JMSetc.



– extract, transform and load data– guarantee transparent mapping to

legacy API● Benefits

– additional savings– legacy data formats (ex: IMS-DC)

abandoned


Thanks !

● Questions ?

send us a mail: [email protected]

migrating legacy applications (cobol, pl/i) to java on z/os

Technology