proetcon.de > Software Migration > CoJaC > Migration Aspects
CoJaC Migration Aspects FAQ Download
[CoJaC]

MIGRATION PATHS

The accompanying table shows the migration paths of basic components into the corresponding target systems.

Basic system Target system
COBOL
(COBOL85, IBM, MFC, ...)
Java 1.6
Middleware
(Tuxedo, Pathway, CICS, ...)
Java web services
Files Relational databases
Embedded SQL
(Oracle, DB2, ...)
Dynamic SQL
(Oracle, DB2, MS SQL Server, ...)
DOWNLOAD
All documents are in German.
[PDF] CoJaC datasheet
[PDF] "BEST OF 2012" certificate
[PDF] COBOL-Java migration FAQ
[Basic and target system]

ARCHITECTURE MIGRATION

The migration widely comprises a pure program transformation in addition to an architecture migration:
  • Online programs (server) are provided as web services within the Java target system.
  • COBOL batch programs are transformed into autonomous Java programs (1:1 migration).
The accompanying graphic exemplary outlines the architecture of a typical COBOL application and the resulting Java target system.

CoJaC RUNTIME SYSTEM

[Examples of using the Java runtime system]
Examples of using the CoJaC runtime system
The runtime system provides classes for the execution of the migrated programs within the Java target environment. This includes classes for the COBOL data types (numeric and alphanumeric data) and basic classes for arrays and structures. Furthermore, there are methods that implement the functionality of certain COBOL statements for which there are no native statements in Java (e.g., STRING and INSPECT). Further components are static methods for the mapping of Intrinsic functions and methods for type conversions and classes, which provide the functionality of the interfaces (files, SQL, middleware). The runtime system builds the basis for compact, maintainable Java code.
[Example of middleware migration]
Example of middleware migration

MIDDLEWARE MIGRATION

CoJaC can optionally transform COBOL servers, which work under the control of middleware (transaction monitors), into Java web services. During this process, middleware-specific data and statements are removed or replaced by adequate web service functionality. The interface is thus not conceptually modified. The web services process the same messages as the COBOL servers before. Necessary conversions are encapsulated by the runtime system, which also carries out transaction management.

FILE MIGRATION

[Example of file migration]
Example of file migration
During the migration, the data files used in COBOL are transferred into database tables. The several access modes and forms of organisation are thereby considered. The table structure is derived from the record structure attached to the file via the FD structure within the FILE SECTION. The runtime system encapsulates the database accesses and provides methods for mapping the COBOL statements for file processing (OPEN, READ, READ NEXT, CLOSE, etc.). By migrating the files into database tables, the data are also made available for other applications and tools.
[Examples of migration of embedded SQL]
Examples of migration of embedded SQL

MIGRATION OF EMBEDDED SQL

CoJaC converts embedded, static SQL statements to dynamic SQL statements. The Java runtime system contains methods for managing the database access and connection, for reading and writing data into host variables and for error handling, all of which map the functionality of the basic system. Experience shows that the change to dynamic SQL implies no runtime disadvantages. Simultaneously, the flexible creation and modification of SQL statements becomes possible.

MIGRATION OF SCREEN MASKS

[Example of screen mask migration using MaTriX]
Example of screen mask migration using MaTriX
There are several options for screen mask migration, any of which can be carried out according to customers' requests:
  1. Keeping the existing screen masks: Because the interface of the migrated web services is not conceptually modified, clients can be maintained with some small technical adjustments. This migration is transparent for the user.
  2. Automated migration: The screen masks can be converted automatically by our tool MaTriX into Web-2.0-based user interfaces.
  3. New development: The screen masks can be newly developed corresponding to customers' requests, e.g., as JavaServer Pages.