The following summary reflects our extensive project management experiences gained from assisting clients in converting their COBOL applications to Java or C#. The outlined steps are applicable to the migration of mainframe COBOL applications with VSAM/KSDS data files, CICS Transaction Processing, ILE COBOL on IBM ISeries, Tandem systems, as well as platforms utilizing CODASYL databases like BULL, Unisys, and VAX. It's worth noting that the conversion of COBOL/DB2 (SQL) applications tends to be more straightforward, often requiring fewer data-related migration steps.
Testing is one of the biggest tasks in any modernization, rehosting, or writing a brand-new application.
Writing test scripts involves running the COBOL application and noting the behavior.
The population of the new SQL tables from VSAM structures is achieved using Data-Access-Objects (DAO) created in the previous step.
One significant difference between the original data structures and the SQL tables is the representation of numeric fields and columns.
For instance, Packed-Decimal fields are stored as Binary Coded Decimal in the COBOL data file. After migration to a database, such fields will be represented as numeric columns, and the actual numeric values will be stored, rather than the binary representation of the value. This simplifies data comprehension in the database.
The Data-Access-Objects are utilized for a one-time EBCDIC to ASCII conversion - eliminating the need to work with EBCDIC after the migration and departure from the mainframe.
SoftwareMining's COBOL Converter will translate VSAM Indexed File Definitions (FD) to SQL Tables.
In this design every FD field will get its own database column, and Index Groups will be translated to composite keys.
With closer attention to the following issues, the translator can generate better designs for the database tables, making the effort in the following clean-up process very worthwhile.
In COBOL, Often different programs use a different File-Definitions structures for access to the same data-file.
For example, Prog-1 may define:
While Prog-2 may access the same data using a different structure :
05 IDEN PIC 9(5).
05 FILLER PIC X(20).
05 BAL PIC 9(5)V9(2).
01 CLIENT-RECORD. 05 ID PIC 9(5). 05 FORENAME PIC X(10). 05 SURNAME PIC X(10). 05 BALANCE PIC 9(5)V9(2).
When migrating data to SQL databases, the previously mentioned data structures will be consolidated into a single table. SoftwareMining's COBOL Converter offers the flexibility to achieve this task using either heuristic algorithms or configuration files, ensuring synchronization between both COBOL programs and their usage of the same database table.
However, the translator possesses a 'first-come, first-serve' capability. As a result, the names of tables and columns will depend on the sequence in which the programs are translated. Therefore, the following naming conventions will be employed in the example above:
But if 'Prog-2' takes precedence -
CLIENT-REC-1, IDEN, FILLER, BAL
CLIENT-RECORD, ID, FORENAME, SURNAME, and BALANCE
For further information, please see Mainframe CICS VSAM to Java Conversion.
Large applications often consist of hundreds or even thousands of programs. Commencing the translation process alphabetically may not always be the most efficient approach: program "A" might call program "Z," which is not scheduled for translation until later.
The call chain analysis process is designed to identify all programs and data files involved in a chain. Identifying the associated list of programs allows for their collective translation, while prioritizing the data files for the data migration process.
SoftwareMining's COBOL Analytics also provides Call-Chain Analysis - invaluable in identifying the artifacts and organizing their translation accordingly.
We recommend against translating the entire application on day one, all at once. Ideally, sets of related programs should be identified through the call chain analysis mentioned above and translated incrementally. While the testing team is engaged in their tasks, work can commence on identifying the next call chain, its translation, and subsequent testing phases.
Allocate a day for translation and compilation of each program set.
Please note that the data migration phase must have been completed for datasets accessed within this call chain.
Job Control Language (JCL) scripts are similar to shell scripts and serve various purposes, including:
The development of COBOL test cases and test harnesses should ideally begin earlier in the project. Functional testing can be seen as a form of regression testing, where the goal is to execute the same tests in the new language and reproduce the results in the new system.
The time allocated for testing naturally depends on the complexity of the programs within the chain and the chain's length. However, rough estimates suggest around five sets of call chains per developer-day. Typically, the initial few test sets may take longer to complete. This initial delay is due to developers and testers needing time to become familiar with the new system and to address technical challenges that often arise at the project's outset.
Once a certain level of confidence in the new code is attained, a spot-testing strategy may be adopted.
Performance requirements for both batch and online applications can often be addressed through different approaches:
After performing a significant overhaul of the language and architecture (transitioning from COBOL to Java or C#), there can be advantages to redesigning the user interface to leverage modern HTML/Browser technologies.
For instance, a SoftwareMining client revamped data entry screens to display 100 records, a significant increase from the 24 lines available on the mainframe terminal. Additionally, they introduced new drop-down boxes, menu items, and radio buttons to streamline data entry, resulting in a reported 15% increase in the efficiency of the data-entry pool and corresponding cost reductions.
Translating COBOL screens, whether in BMS, DMS, ILE, or other formats, produces character-based HTML screens that closely resemble the original screens. However, the translated system offers a plug-and-play architecture, allowing manually redesigned JSP or ASP.NET interfaces to be seamlessly integrated without altering any of the business logic code.
SoftwareMining also provides a Screen Designer for modernizing translated BMS screens, facilitating efficient screen modernization.
User Acceptance Testing is a critical phase, particularly for online applications, where end-users play a pivotal role in validating the system's readiness for production use. During UAT, users will conduct a series of tests that encompass various aspects, including:
© 2024 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.