Checklist Item |
How can it be resolved |
Conversion of COBOL code To Maintainable & Cloud-friendly languages: Java or C# | High-Quality Translator The most cost effective and low risk approach to Java / C# is using a high-quality translator which can produce maintainable and functionally correct Java/C# code. SoftwareMining Translation tools achieve this by catering for 16 Features Essential for Successful COBOL to Java Conversion Projects |
From CICS (and other Transaction Processors) to Application Servers |
CICS Libraries
Java and C# Application Servers (Weblogic, WebSphere, Tomcat, and IIS for Microsoft .NET)
provide much of these functionality. The Translator must be able to generate code which will utilize such technologies.
Out of the remaining CICS functionality,
For more information about SoftwareMining's CICS libraries and modernization approach please see Approach to Migration of CICS Cobol to Java / C# . |
Online BMS / MFS Applications - Support for migration of BMS operations to legible statements |
Handling Legacy Screen Formats
The solution should be based on Application-Server deployment and should:
|
Access to Queue framework |
MQ Series
Most legacy COBOL applications use queueing framework for passing messages between modules.
Once translated, during testing phase the new system should be able to communicate with the legacy MQ Series.
Beyond the testing phase, the new application should be able to use any other commercial or Open-Source queueing system.
SoftwareMining translates to interface which allow implements to communication with any queueing system.
|
Conversion of JCL to Unix or Windows Shell Scripts | Viable solution to JCL translation
Most mainframe shops rely heavily on JCL scripts. A successful deployment on the cloud requires the JCL solution to work hand-in-hand with the converted Java or C# application. A viable JCL solution needs to address:
|
Data-Files: KSDS Indexed Files to SQL Database | Data Migration While many COBOL applications have already been moved to SQL Database, there are still many which use KSDS files to their data. SoftwareMining conversion automatically addresses the migration of VSAM / KSDS structures to SQL databases schemas by catering for the following issues:
|
COBOL / DB2 Applications | The conversion of COBOL + EXEC SQL to Java / C#
needs to change the dialect of SQL - from COBOL centric (using Host-Variables, Null-Indicators)
to Java (using '?') or C# centric.
Additionally, for performance reasons, the converter will also need to try and reduce the amount of data-based communication, as these may have higher overheads on the Cloud. There may also be performance issues when communicating between DB2 on mainframe and external Java/C# applications. For more information, see detecting cause of performance issues. |
Data-Files: IMS and other Database to SQL Database |
In some cases, the database migration can be performed in same manner as KSDS approach.
For other cases, such as IMS DB, the database migration needs to be performed in a separate stage by creating a "middle-data-access-layer".
For further information please see COBOL Platforms.
|
Assembler or other variants (e.g. Algol code) | Assembler type scripts are generally used to provide extensions to Operating-System functions.
They often do not contain any "Business-Logic" which need to be translated.
Assembler programs should be reviewed case by case. In many cases they can be replaced simply by Java and C# libraries, which offer a much more rich framework and libraries than COBOL. |
© 2022 SoftwareMining is a trademark of Software Modernization Technologies Ltd (UK). Registered in England company no: 07300248. Reg Offices: 79 Stevens House, Jerome Place, Kingston Upon Thames, KT1 1HX, United Kingdom.