Why Object Orientation for COBOL?

Bridging Legacy COBOL with Modern .NET

When a business first builds its core systems in COBOL, it rarely envisions rewriting them when a new platform arrives. Those legacy applications are often the backbone of financial, inventory, and customer‑service operations, and the cost of a full rewrite is huge. That’s why Microsoft has chosen to make COBOL a first‑class citizen in the .NET ecosystem, and why Fujitsu Software is championing the same direction. The idea isn’t to discard COBOL; it’s to give it a new life by letting it coexist with C++, Visual Basic, and ASP.NET inside a single, unified runtime.

Consider a company that processes payroll on a mainframe using a 20‑year‑old COBOL program. The payroll logic is solid, but the reporting team wants a modern web interface that can pull data in real time. Without a migration plan, the only options are to write a new web layer that calls the legacy COBOL through a batch process, or to re‑write the whole payroll module in C#. The first approach leaves a brittle, hard‑to‑maintain bridge; the second incurs a massive upfront cost. Instead, by moving the COBOL code to .NET, you can expose it as a COM server or a .NET class, call it directly from ASP.NET, and still reuse every line of business logic.

The .NET framework offers more than just a language switch. It brings a rich set of class libraries for data access, networking, cryptography, and user interface design. A COBOL developer who learns a few simple object‑oriented concepts can then take advantage of these libraries without leaving the comfort of COBOL syntax. This is what Fujitsu Software is helping to achieve: a gradual shift to object‑oriented COBOL (OOCOBOL) that opens up new possibilities without demanding a total rewrite.

Another powerful benefit of bringing COBOL into .NET is interoperability. In a mixed‑language environment, a COBOL class can inherit from a C# base class or be inherited by a VB.NET module. This makes it possible to write common business logic once and share it across the whole organization. The old divide between COBOL programmers and those who write in C++ or Visual Basic disappears because both can now reference the same COM object or .NET assembly. Teams that once worked in silos can collaborate on a single project, reducing duplication and accelerating delivery.

From a maintenance perspective, the shift to OOCOBOL also improves testability. Object‑oriented code is easier to unit‑test because each method can be isolated and called independently. With a procedural COBOL program, you often have to run the entire routine to see the effect of a small change. By converting to a class, you can expose the business logic as a method, mock out dependencies, and write automated tests that run fast and reliably. This not only speeds up development but also gives confidence that the legacy logic remains correct after each change.

Finally, modern deployment scenarios - cloud hosting, containers, microservices - are built around .NET assemblies. By moving COBOL code into .NET, you can package the application as a Docker image, deploy it to Azure App Service, or run it as a serverless function. The same code that once lived on a mainframe can now run in a cloud environment, giving the organization agility and cost efficiency.

In short, Microsoft’s support for COBOL in .NET and Fujitsu’s tools for OOCOBOL are designed to let businesses keep their reliable legacy logic while taking advantage of modern software practices, new platforms, and cross‑language collaboration.

From Procedure to Object: A Practical Transformation

Let’s walk through the steps needed to turn a small procedural COBOL program into an object‑oriented module that can be called from any .NET language. The example program opens an ISAM file, prompts the user for an area code, searches for the corresponding state, and prints the result or an error message. The original code lives in a file called PROCED.COB. We’ll transform it into AREACODE.COB, a class named AREACODE, that can be registered as a COM server.

1. Rename the program identifier. Replace the PROGRAM-ID line with CLASS-ID AREACODE. The CLASS-ID tells the compiler that this file represents a class. After the name, include the repository path: AS "Dotnet.areacode". This tells the .NET runtime where the compiled assembly will reside.

2. Add a repository statement. In the CONFIGURATION SECTION insert REPOSITORY and list any external types the class will reference. For our error handling we’ll need System.ArgumentException. The line looks like this: REPOSITORY System.ArgumentException. This makes the runtime aware that our class will throw this .NET exception type.

3. Declare the object. After the REPOSITORY section add OBJECT AREACODE. This marks the start of the class body. The class will be instantiated with the NEW keyword from any .NET caller.

4. Add a procedure division for the object. Inside the class, include PROCEDURE DIVISION as you would in a normal COBOL program. Then insert a METHOD-ID GETSTATECODE line. Methods are the entry points for code that will be called from outside. We’ll keep the method name short and descriptive.

5. Define the environment. Add an ENVIRONMENT DIVISION block. This is optional but useful for specifying external file references. In our case the ISAM file is defined in the DATA DIVISION, so we’ll leave this minimal.

6. Adjust the data division. The WORKING-STORAGE SECTION now contains the data used internally by the method. Because this is an object, you can add class-level variables that are shared across method calls. For example, declare a WORKING-STORAGE SECTION with a variable WS-ERROR-CODE and WS-ERROR-MSG to hold error information.

7. Introduce a linkage section. Since the method will be called from outside, it must accept parameters and return values through the LINKAGE SECTION. Add LINKAGE SECTION with the following definitions: LINKAGE AREA-CODE PIC X(3). and RETURN-STATE PIC X(2). These act like method arguments and return values in .NET. The caller passes an area code and receives a two‑character state code.

8. Rewrite the procedure header. The PROCEDURE DIVISION USING clause now lists the linkage parameters: PROCEDURE DIVISION USING AREA-CODE RETURN-STATE. This replaces the old main program header that used CALL statements.

9. Move business logic into the method. Copy the code that prompts for input, searches the file, and sets the return value into the body of GETSTATECODE. Remove any UI calls (like DISPLAY statements) if you want the class to be UI‑agnostic. Instead, assign the state code to RETURN-STATE and, if an error occurs, throw a System.ArgumentException using the RAISE statement.

10. Terminate the method and class. At the end of the method add EXIT-OBJECT. and close the class with END-OBJECT AREACODE. This mirrors the EXIT-PROGRAM that ends a traditional COBOL program.

After these ten changes, the file AREACODE.COB compiles to a .NET assembly that exposes a single method. You can now create a new instance in C#: var area = new AREACODE(); string state = area.GETSTATECODE("123"); and handle any exceptions in the normal .NET way.