Migrating mainframe COBOL DB2-based business functions to a cloud-native architecture is a daunting task. In our previous series, we discussed the various complexities involved in ensuring a smooth transition without disrupting business operations or affecting customers. Moving databases from a mainframe to the cloud adds an additional layer of complexity.
Here’s a look at some of the challenges I’ve observed during database migration:
Changing the Database
Sometimes, architects may decide to overhaul not only the application architecture but also the databases and their designs.
While this might seem like a good idea, several considerations and complexities arise:
- Data Transfer and Synchronization: Ensuring seamless data movement and synchronization between systems.
- Codepage Complexities: Managing differences in character encoding scheme.
- Ongoing Data Validation: Continuously verifying data integrity.
- Security and Access Controls: Maintaining secure and appropriate access.
- Functional Parity: Ensuring that new systems meet the same functional requirements as the old ones.
Sticking with the DB2 Family
Moving from DB2 z/OS to DB2 LUW:
This transition itself presents several challenges, including:
- Handling HIGH Values (0xFF) in SQL WHERE Clauses: These values will be treated differently.
- Differences in SQL ORDER BY/GROUP BY Collating Sequences: SQL sorting and grouping will behave differently across systems.
Staying with DB2 on z/OS:
Even if you decide to stay with DB2 on z/OS, migrating from COBOL to Java using JDBC introduces its own set of issues:
- SQLCODE Behavior Differences: For example, COBOL programmers might rely on the “Singleton SELECT” and SQLCODE -811 to identify multiple qualifying rows but they also exploit this negative SQLCODE and utilize the data returned after the execution. In JDBC, you need to open a cursor and simulate this behavior to return the first row, however there is no guarantee that data will be the same as returned by COBOL singleton SELECT unless an ORDER BY clause is used.
- Unsupported Syntaxes in JDBC: SET statement syntaxes are not supported, requiring changes in SQL (see Balaji’s blog for details).
- Logic Differences Due to Dependency On z/OS-Specific Special Registers: Business logic might rely on special registers like “CURRENT MEMBER”, “CURRENT PACKAGESET, “CURRENT USER” or “CURRENT SERVER” etc.
- Timestamp Format Differences: JDBC handles timestamp formats differently compared to COBOL based SQL, though JDBC parameter override can offer some relief.
- Multiple Codepage Differences: I have seen customers using different codepage for COBOL e.g. CP1140 while the DB2 is set up with different sets of codepages (CP037, CP1047, or CP500 etc.) and finally the JDBC translates them using UTF-8 codepage. Multiple translations can cause data issues, particularly with special characters (line feeds, carriage returns, square brackets, etc.). Debugging these issues will surely delay your project. Refer tohttps://www.ibm.com/support/pages/ccsid-comparisonsto understand the differences.
- Isolation Levels Differences: Concurrency requirements and isolation bind parameters can impact business logic behavior differences while modernizing.
Conclusion
The challenges listed above are only a small set of examples that illustrate the complexities involved in modernizing COBOL DB2 applications. To navigate this intricate process, it’s crucial to have modernization experts on your team. CloudFrame Modernization toolkits, enhanced by AI, are designed to help you tackle these challenges effectively.
