Java has evolved into a viable alternative to COBOL for many DB2 z/OS customers. There is an emerging trend for customers to write new business logic in Java, and in some cases replace COBOL business logic with Java. This offers several advantages -
- Standard Java APIs (such as JDBC) allows customers to enable applications for diverse mediums such as Web and Cloud.
- Developers can rapidly build applications by reusing existing business logic rather than bottom up development.
- Customers can easily attract talent to develop and maintain Java code.
- Speciality processors on mainframe (zIIP and zAAP) allow offload for Java applications lowering the total cost of ownership.
- Advances in Java technology on z/OS provides comparable performance, throughput and overall quality of service that are the hallmarks of native COBOL.
Many customers are in the process of running proof-of-concepts to evaluate Java technology choices in the context of their environment. It is an interesting experience to work with customers who are at the leading edge of business transformation. Java presents new opportunities for exploitation of business logic through many channels, but it also comes with a set of challenges that customers must be prepared to handle.
An important aspect we addressed with a couple of large COBOL heavy accounts who opted to use JDBC interfaces was a change in their mindset to be more aware of tuning considerations for DB2 and Java environment. It was a rewarding exercise to build awareness on the fundamental differences between native COBOL that goes through static SQL execution paths in DB2 versus JDBC that goes through dynamic SQL paths. Although static SQL may provide better out-of-box performance, dynamic SQL has tuning options that takes the performance at par with static SQL with all the flexibility of dynamic SQL. A few large accounts who prefer the predictability and security of static SQL are also evaluating SQLJ – which allows Java applications to use static sql with DB2 by binding packages. SQLJ applications do need coding of custom SQLJ syntax. There are several other important considerations such as decision to rewrite COBOL code into Java versus just introducing Java wrappers around COBOL logic (which will be faster to build). There are several smaller considerations such as connectivity options to DB2 (Type 4 vs Type 2) and recommended Java programming model for high performance.
Transformation from COBOL to Java for DB2 on z/OS is an investment – but it can yield returns in the short and long term by exposing core Systems of Records applications to modern Systems of Engagement. Enterprise modernization is maturing from a "nice-to-have" initiative to an essential initiative and what began as a modernization movement in a handful of leading edge adopters is now spreading across the global z/OS customer base. If you are one of those customers sitting on the fence for modernization, time to act is now. IBM taps into its global network of DB2, z/OS, CICS, COBOL and Java integration experts to provide guidance for the success of such legacy modernization projects.
An important aspect we addressed with a couple of large COBOL heavy accounts who opted to use JDBC interfaces was a change in their mindset to be more aware of tuning considerations for DB2 and Java environment. It was a rewarding exercise to build awareness on the fundamental differences between native COBOL that goes through static SQL execution paths in DB2 versus JDBC that goes through dynamic SQL paths. Although static SQL may provide better out-of-box performance, dynamic SQL has tuning options that takes the performance at par with static SQL with all the flexibility of dynamic SQL. A few large accounts who prefer the predictability and security of static SQL are also evaluating SQLJ – which allows Java applications to use static sql with DB2 by binding packages. SQLJ applications do need coding of custom SQLJ syntax. There are several other important considerations such as decision to rewrite COBOL code into Java versus just introducing Java wrappers around COBOL logic (which will be faster to build). There are several smaller considerations such as connectivity options to DB2 (Type 4 vs Type 2) and recommended Java programming model for high performance.
Transformation from COBOL to Java for DB2 on z/OS is an investment – but it can yield returns in the short and long term by exposing core Systems of Records applications to modern Systems of Engagement. Enterprise modernization is maturing from a "nice-to-have" initiative to an essential initiative and what began as a modernization movement in a handful of leading edge adopters is now spreading across the global z/OS customer base. If you are one of those customers sitting on the fence for modernization, time to act is now. IBM taps into its global network of DB2, z/OS, CICS, COBOL and Java integration experts to provide guidance for the success of such legacy modernization projects.
No comments:
Post a Comment