Common questions.
Clear answers.

Code Conversion

Our goal is to support the entire spectrum of features of IBM Z/OS Enterprise Cobol. We currently have support for about 95% of COBOL features. This includes all legacy variable types (zoned, binary, packed decimal, redefines, arrays etc), all type of control flow (including goto), all arithmetic, nearly all statements, and most standard intrinsic functions. Copybooks are converted to reusable Java classes. Furthermore we support batch file handling (sequential as well as VSAM) and most common features of embedded SQL (targeting PostgreSQL currently). Support for CICS, JCL and other languages such as PL/I are on our road map. Please contact us to discuss your specific requirements.

Any missing features are clearly logged by our tools during the discovery phase, when running over your code. Missing features will either be implemented in our tools as part of the project, or integrated/worked around by the client development team depending on what was agreed at project start.

Data Conversion

We also assist with data conversion, ensuring that your data is accurately transferred and transformed during the modernization process.

• For VSAM, we provide convenient conversion using a combination of IDCAMS and FTP on the mainframe side, and a Java-based conversion tool on the target side.
• For relational databases, we provide a tool that connects to the source database to discover the schema and produces template configuration files. After manual tuning of the configuration, the tool connects to both source and target databases and performs the actual conversion of DDL and data.

The generated code needs to fulfil two essential requirements: it must support 100% automation (to allow fast and repeated conversion of huge code bases), and it must be functionally equivalent to the original application under all circumstances. Within these constraints, we claim to produce the best possible Java code, better than any of our competitors. Don't just believe us: send us a sample and we will happily convert it for you.

We do not claim to produce green-field code. This is intentional: by keeping the code structurally similar to the original COBOL, we allow ex-COBOL developers to quickly "feel at home" in the converted code. Keeping these people on board after the conversion is an important factor in the success of a conversion project.

We aim to convert towards native Java constructs and strong typing whenever possible. Still, a support library is available that provides supporting features not readily available in standard Java. Hiding these features behind a support library API allows us to keep the business logic concise, while still being able to guarantee 100% functional equivalence. Support library calls are clearly recognizable as such; their API feels natural even for a Java developer and is well-documented and available in source code form should you wish to examine or modify it.

Last but not least: maintainability is measured not only by code quality, but by the efficiency of the entire development ecosystem. Converting towards Java improves maintainability by leveraging modern tooling, improved developer experience, and higher avaiability of developers.

Iso-functional means the converted Java application is intended to have the exact same observable effects as the original program: computations, reports, file output, database updates and other business outcomes.

Testing is an essential (and perhaps the largest) part of a conversion project. The Java application must be proven to behave identically to the original application. The major benefit of an iso-functional conversion is that validation can be done merely by running the same application against the same data on both the original and converted systems. Given the same input, both systems should produce exactly the same output.

When properly set up, most of the validation tests can be automated and re-run frequently, for instance after each change to the conversion tools, until the converted application is fully validated.

The conversion process is fully automated, fast and repeatable. It can convert roughly one million lines of COBOL source code in an hour.

There is of course much more to a modernization project than just code conversion. The total project time includes many other activities such as environment setup, data conversion, testing, change management, developer (re)training, new devops procedures, go-live planning and final switch-over.

The total project time depends on many factors, including the size and complexity of the application, the availability of test data, and the experience of the team executing the project. We can provide guidance on project planning and execution based on our experience with previous projects.

The generated Java uses a small support library. Its source code is delivered with the converted code and becomes part of the customer's project, so the dependency is visible and can be built and maintained as part of that project.

The support library provides features that are not readily available in standard Java, but are needed to support the original application in an iso-functional manner. While some of these features could be implemented in the converted code itself, we prefer to keep the business logic concise and readable by hiding them behind a support library API.

No. We provide the conversion tools, extensive tools documentation, assistance with project setup, technical support for the tools during the project, and high-level guidance and best-practices on how to approach a conversion project.

The customer or its chosen reseller executes the conversion project. This model gives organizations control over delivery and helps us offer a cost-effective solution compared with service-heavy alternatives.

Yes. Resellers are welcome to license the conversion tools for use in their own modernization projects. They can execute projects for their customers while using our tools and, where applicable, our technical support and project delivery expertise.

Before a project starts, we provide an indicative quote based on the expected size of the project (lines of code, number of files and tables). We always perform an assessment on a representative sample of the code to be converted, to ensure that the tools can handle the project. Any potential complexities or functionality gaps are identified and communicated. We then provide a binding fixed-price quote that covers the following components:

• Consulting services for the project setup, planning and high level guidance.
• Use of the conversion tools and runtime components throughout the project.
• Perpetual use of our runtime components in your post-project environments (dev, test, UAT, production).
• Technical support during the project and the first year of production use.

After the first year, you decide whether you want to continue the technical support plan (yearly renewable).

Cost of each component (services, tools license, runtime license, technical support) depends solely on the size of the project in terms of technical resources (lines of code, number of files and tables).

There are no recurring runtime fees.

Yes. The generated Java is "plain old Java" with no third-party dependencies (apart from JDBC for database access). It is straightforward to embed into existing or new Java development, and to either call or be called by other Java code. The generated code can be maintained, built and deployed using standard Java devops tools and processes.

A useful starting point is an inventory of the COBOL source code, copybooks and database schemas. We can help with tool setup and planning so your team or reseller can run the conversion and validate the result.

LGC Software (pronounce "Legacy Software") is a small startup software company that specializes in automated conversion of legacy source code.

We have been active in the automated software conversion field for almost 30 years, but decided to start building and distributing our own conversion tools, packing the experience and lessons learned from previous projects into a new generation of tools.

By focusing on the delivery of the tools, and leaving project execution and integration to our clients or resellers, we can remain a small, dedicated team and offer very attractive rates.

While we do use AI to build the conversion tools, the tools themselves do not use AI to perform the conversion. They use standard compiler technology and custom-made, detailed conversion rules to perform the conversion in a consistent and predictable manner.

AI-generated conversion results may certainly look impressive. However AI struggles with bulk code conversion because it lacks the consistency, predictability and accountability that enterprise modernization demands.

Traditional tools, while perhaps more blunt in their conversion approach and results, maintain consistency across the entire codebase and across multiple conversion runs. They leave an auditable trail of what was converted and why. Corrections can be re-applied quickly, precisely and consistently across the entire codebase.

This certainly doesn't exclude the use of AI in a conversion project. What we propose is to combine the best of both worlds:

• Use our purpose-built tools to handle the structural heavy lifting of COBOL to Java conversion, consistently and predictably.
• Use AI to perform specific, less repetitive or smaller scale tasks such as DDL or JCL conversions, or ad-hoc refactorings in specific areas of the generated code. Of course AI can also shine in design reviews, in integration work, and in the documentation of the application's business logic.

This hybrid model leverages each tool's strengths while minimizing weaknesses and risks.