COBOL with DB2 and Embedded SQL to Java

SoftwareMining's automated, rule-based COBOL-to-Java and COBOL-to-C# Conversion Toolkit converts enterprise COBOL applications that access DB2 through embedded EXEC SQL into maintainable Java or C# source code. It translates SQL statements, host variables, null indicators, cursors, SQLCODE handling and transaction processing together with the surrounding COBOL business logic.

The generated application uses standard Java or .NET database-access technologies and SoftwareMining runtime components where COBOL or DB2 behaviour must be preserved. Applications can continue to use DB2 or be adapted for another relational database, subject to differences in SQL syntax, data types and database behaviour.

Database connections, transaction boundaries and connection pooling can be configured for the target application architecture. The resulting application can be deployed on cloud, private-cloud or on-premises infrastructure without requiring the application and database to reside on the same system.

Example of COBOL EXEC SQL Translation

This example compares COBOL with embedded EXEC SQL on the left with the corresponding Java generated by SoftwareMining on the right. It demonstrates input and output host variables, null-indicator handling and SQLCODE processing.

EXEC SQL
  SELECT CUSTOMER_NAME
    INTO :CUSTOMER-NAME
     :NULL-INDICATOR-1
    FROM CUSTOMER
   WHERE CUSTOMER_ID =  :CUSTOMER-ID
END-EXEC


IF SQLCODE NE 0
   ...
   

sqlProcessor.prepare("SELECT CUSTOMER_NAME "
  + "FROM CUSTOMER "
  + "WHERE CUSTOMER_ID = ? ");

sqlProcessor.setOutParameter(1,customer.getCustomerName()
                              , customer.getNullIndicator1());
sqlProcessor.setInParameter (1, customer.getCustomerId());
sqlProcessor.executeQuery();
sqlProcessor.next();

if (sqlca.getSqlcode() != 0) {  ... }
 

SoftwareMining generates the parameter binding, field access, null-indicator handling and database-access code according to the generated Java or C# data structures and target database configuration.

How SoftwareMining Translates COBOL EXEC SQL

• Embedded SQL and Host-Variable Translation

  SoftwareMining translates embedded EXEC SQL statements into parameterized Java or C# database-access code. COBOL host variables, such as :CUSTOMER-ID, are mapped to the corresponding generated fields and bound to JDBC or .NET database parameters.

  The translator also identifies input and output host variables, data types, cursor operations and associated null-indicator variables. The generated code and SoftwareMining runtime libraries work together to convert values between COBOL representations and database types, set null indicators after retrieval and supply SQL NULL values where required.

• Database Vendor Flexibility

  The generated application can continue using DB2 or be adapted for another relational database, such as Oracle, Microsoft SQL Server or PostgreSQL. SoftwareMining provides configurable SQL return-code mapping so that the converted business logic can continue to handle expected DB2 SQLCODE values where the target database reports different vendor-specific codes.

  Database substitution may still require changes for vendor-specific SQL, stored procedures, functions, data types and transaction behaviour.

• Migrating Supported COBOL Stored Procedures

  Where supported COBOL programs are invoked as database stored procedures, SoftwareMining can translate their business logic into Java or C# and generate interfaces for the selected target architecture. Database-specific registration, invocation and deployment requirements are addressed as part of the migration design.

• Reducing Database Calls in Batch Processing

  Batch applications can issue SQL statements solely to obtain or format values such as the current date and time. When the application and database are deployed on separate systems, each call may introduce unnecessary network and database-processing overhead.

  Where equivalent behaviour can be reproduced safely, SoftwareMining converts these SQL operations into calls to its Java or C# runtime libraries. For example, a DB2 request used only to obtain a formatted date-time value can be replaced by a local library call that returns the required representation without a database round trip.

  This optimization is applied only where a local operation can produce the required result without changing observable application behaviour. SQL operations involving business data, database state or transaction processing remain database operations.