Unisys MCP COBOL-to-Java Conversion Tools

Unisys MCP COBOL applications commonly use DMS, DMS-II or DMS-2000 databases. These databases are closely integrated with the Unisys platform through DDS schema definitions, record navigation, set relationships, database status codes and platform-specific data-access APIs. Migrating the COBOL code alone would therefore leave the converted application dependent on the original Unisys database environment.

A complete migration requires a path from the DMS-II database to a relational database that can be accessed by the new Java or C# application. This process begins by parsing the associated DDS schemas and mapping database structures, records, fields and relationships into corresponding SQL tables.

SoftwareMining provides automated, rule-based tools for converting Unisys MCP and Burroughs COBOL applications into maintainable Java or C# source code. The tools generate relational database definitions from the DDS schemas and convert DMS-II data-access operations into object-relational data-access components for the target application.

Some organizations already replicate DMS-II data into a relational database using products such as OpenText DataBridge. SoftwareMining can generate table structures closely aligned with those produced by DataBridge, allowing an existing relational copy of the data to be used where appropriate.

SoftwareMining's Conversion Toolkit converts supported Unisys MCP COBOL language constructs and platform dependencies into corresponding Java or C# implementations. Related batch workflows can be migrated from WFL to compatible Unix shell scripts or Windows batch scripts through a separate, assisted conversion, review and validation process.

Handling DMS, DMS-II and DMS-2000 Database Access

Unisys COBOL programs commonly use DMS, DMS-II or DMS-2000 databases and their associated APIs. The migration process must convert both the database definitions and the COBOL operations that access them.

DMS-II database conversion takes place in several connected stages. The database DDS is parsed first, followed by the COBOL programs that use the generated database definitions.

1. Prepare the DMS-II Database Definitions

The DMS-II database definitions are taken from the compiler-generated DDS listing. Each 01 data-set definition is extracted into a separate COBOL copybook file containing its fields, data types, sets, indexes, keys and relationships.

These database copybooks provide the structural input required for the subsequent application and relational database conversion.

01 INVOICE-DDS STANDARD DATA SET(#42).

   INVOICE-IDX1 SET(#100,AUTO)
     OF INVOICE-DDS
     KEYS ARE
       INVOICE-NUMB   ASCENDING,
       INVOICE-ACT-NO ASCENDING.

02 INVOICE-NUMB   PIC 9(3).
02 INVOICE-ACT-NO PIC 9(3).
02 INVOICE-DATE                   PIC 9(8).
02 INVOICE-VALUE                  PIC S9(7)V9(5).
02 INVOICE-ADDR                   PIC 9(1).

2. Associate the Program with the Generated Copybook

When a COBOL program is parsed, its database declaration is associated with the generated INVOICE-DDS copybook.

DATA-BASE SECTION.
DB DB1.
01 INVOICE-DDS.

3. Generate the SQL Schema and Data-Access Objects

During conversion, the generated database copybooks provide the structural information needed to produce:

Relational SQL schema: DMS-II data sets are mapped to SQL tables, fields to columns, and supported sets and access paths to relational indexes.
Data-access objects: Generated Java or C# DAO classes provide access to the corresponding SQL tables from the converted application.

In this example, INVOICE-DDS is used to generate the relational invoice structure and an InvoiceDao class. The converted program creates an instance of this class to perform the database operations previously handled through DMS-II.

InvoiceDao invoice = new InvoiceDao();

See how COBOL structures and records are represented in the generated target code:

COBOL-to-Java Conversion Features

COBOL-to-C# Conversion Features

4. Convert DMS-II FIND and Status Handling

Data set / DAO Access path / lookup Key fields / parameters Status handling


FIND INVOICE-IDX1
  OF INVOICE-DDS
  AT  INVOICE-NUMB   = WS-NUMB
  AND INVOICE-ACT-NO = WS-ACT-NO
  ON EXCEPTION
    IF DMSTATUS(NOTFOUND)
      MOVE "NOT FOUND" TO WS-ERR-MESS.

InvoiceDao invoice = new InvoiceDao();
try {
    invoice.setCondition(
        "(INVOICE_NUMB = ?) AND (INVOICE_ACT_NO = ?)" );
    invoice.addSearchParameter(iData.getWsNum());
    invoice.addSearchParameter(iData.getWsActNo()    );
    invoice.find();

} catch (Exception ex) {
    if (this.IsStatus(DMSMonitor.NOTFOUND)) {
        iData.setWsErrMessage("NOT FOUND");
    }
}

5. Convert Additional DMS-II Operations

The same conversion approach is applied to supported DMS-II operations such as CREATE, STORE, LOCK, FIND and SELECT. These operations are represented through generated DAO methods and SoftwareMining runtime components, while the required DMS status behaviour remains available to the converted application.

Other supported Unisys-specific APIs are handled through generated code and SoftwareMining runtime libraries. This allows the Java or C# application to use a relational database without retaining the Unisys MCP environment solely for DMS-II database access.

The converted operation preserves the original indexed lookup and DMS-II status handling.

Supported Unisys MCP Features

Unisys MCP Feature	Modernized Java / C# Implementation	Comments
FIND	Equivalent keyed database retrieval	Primary key lookups are converted into equivalent Java or C# data-access operations.
FIND FIRST / LAST	Ordered database queries	Record ordering and navigation semantics are preserved using generated SQL and data-access logic.
FIND NEXT / PRIOR	SQL cursor or iterator navigation	Forward and backward navigation through ordered record sets is represented in the converted application.
SET ... TO BEGINNING / ENDING	Navigation state management	Database positioning statements are preserved using equivalent Java or C# navigation logic.
DMSTATUS Handling	Status and exception processing	DMS status codes are converted into equivalent status handling or exception processing while preserving application behaviour.
Database Sets and Indexes	Generated relational indexes	Primary and secondary access paths are preserved using generated SQL indexes and data-access methods.
Business Logic	Java generated using predefined, repeatable rules, with optional C#	COBOL calculations, business rules and processing logic are converted using predefined, repeatable rules and validated against the original application.
Deployment	Java application server or ASP.NET	The converted application can be deployed on modern server infrastructure, either on-premises or in the cloud.

LLM-Assisted Migration of Unisys WFL

Unisys MCP applications commonly use Work Flow Language (WFL) to coordinate COBOL programs, file processing, sorting and other batch operations. WFL is also a programming language and may contain variables, conditional logic, loops, error handling, file management and other application-specific processing.

During modernization, each WFL workflow must therefore be analysed rather than treated simply as a list of programs to run. Job sequences, parameters, conditions, dependencies, completion-status handling and operational logic can be mapped to Unix shell scripts that coordinate the Java or C# programs generated by SoftwareMining.

Supporting functions can use SoftwareMining runtime utilities for operations such as sorting and generation-data management where applicable. More complex procedural logic may require corresponding shell functions, scripts or supporting Java or C# components.

SoftwareMining supports WFL conversion by providing structured migration specifications for use with suitable LLM-based development tools. These specifications describe how WFL constructs should be mapped to Unix shell scripts or Windows batch files that can coordinate the Java or C# programs generated from the Unisys COBOL application.

The migration specifications define SoftwareMining runtime interfaces, program-launch conventions, parameters, return-code handling and the use of supporting utilities such as SORT and generation-data management. They also provide guidance for converting WFL conditions, variables, file operations and procedural logic.

Because WFL is a programming language and individual workflows may contain application-specific logic, LLM-generated scripts require technical review and execution-based testing. The converted workflow should be validated against the original WFL processing to confirm job sequence, conditional behaviour, file handling, restart processing and final results.