As enterprise IT evolves, we are left with outdated hardware and software for many reasons. Perhaps there is a regulatory requirement to retain the data for as long as possible; maybe there is a dependency in the code that is still reliable and supported even after decades. Whatever the reason, we may need to work with that system and that data as part of a newer platform.
One platform that is not going away is the mainframe, especially in government and finance. Lots of critical data and software runs on those systems, and they’re not as out of date as we might think, running hypervisors and multiple operating systems, including up-to-date Linux distributions.
We now have many options for building applications that work with those legacy systems, including technologies like the latest versions of .NET. We’re also not limited to the familiar .NET languages, as the underlying compilers and runtime can be accessed by a mix of open source and commercial language implementations, including some designed to work with mainframe data.
There is still a place for Cobol
A familiar language to mainframe developers is Cobol, originally designed as one of the first high-level programming languages. Still under development, and now with support for object-oriented programming, Cobol is ISO standardized. It may not be as popular as it was 50 years ago, but there is code that needs maintenance and updates, and even new code that needs to be written.
Working with a portable Cobol makes sense; Mainframe time can be expensive, so the ability to develop and test on desktop PCs is becoming increasingly important. That’s where technologies like .NET come in, allowing you to work with familiar development tools before running your code on a mainframe Linux virtual machine or hosting it in the public cloud. With several different .NET Cobols available in a mix of open and commercial versions, you have a choice of tools. One of the most interesting options is the recently introduced Otterkit.
Introducing Otterkit Cobol
Otterkit Cobol is intended to be a freely available, open source implementation of the ISO Cobol 2022 standard, designed to run on the latest versions of .NET. Although still in development and not recommended for production, it’s an interesting example of how the .NET community is expanding the platform and tools beyond Microsoft’s core languages, providing support for older technologies and the latest native approaches to Cloud.
Getting started with Otterkit is pretty easy. The project is hosted on GitHub and you can install it from NuGet via the .NET command line on a .NET 7 host. It’s interesting to see a project that depends on the latest version of .NET, though as it’s currently under development , this is less risky than you might expect. Users who want to experiment with the latest tools are more likely to use a current release build rather than a long-term release. You even have the option to clone the Otterkit repository and build from source.
A first look at Otterkit
It’s still too early for Otterkit; the compiler recently produced its first running code. The compiler pipeline is more of a cross compiler for now, as it takes your Cobol code, uses it to generate C#, which is then compiled with the .NET compiler, ready to run as a standalone executable. Code can be written using fixed or free formats, allowing you to choose whether to use a strict code format or work with it like any other language.
There is a lot of value in working with fixed formats like Cobol’s. It makes the code easier to read, which is important with a language designed to be easily readable so that non-specialists can quickly understand your code. This speeds up working with stakeholders and can help bring Excel or similar applications into a formal setting.
There is no need for additional libraries at this time, as Otterkit is planned to include a standard library that should support most operations. For now, it offers a basic build pipeline and support for basic commands. For a new project that’s not bad since it’s now public and accepting pull requests. Cobol may not be a hot language, but there is a definite demand for it, and that should drive community participation.
To newcomers to the language, the formal structure of a Cobol application might seem a bit strange, but once you start thinking about slices as ways to define data connections and local variables, it starts to make a lot more sense. A good editor should allow you to set up tabs to space program elements correctly, and existing Cobol linters and language servers for Visual Studio Code can launch a development environment. Hopefully Otterkit will have its own tools in due time.
Modernizing Cobol with .NET
Perhaps the most exciting thing about Otterkit’s reliance on .NET 7 is its support for building containerized .NET applications. You now have the option of modernizing your existing Cobol code, updating it to the latest version of the language, and then delivering it in a portable container format, ready for mainframe Linux or the public cloud. Containerized code has a smaller attack surface than running on a full Windows or Linux system, which reduces risk by isolating your code from unnecessary resources and other applications.
Otterkit includes a way to translate Cobol into C#, giving you a potential path to port your Cobol code into more modern languages. Use existing Cobol abilities to migrate code to newer versions, then Otterkit can produce C# output in a new project, allowing you to move code from one environment to another with minimal work.
The point where open standards and open source meet is interesting. .NET’s well-documented languages and APIs make it a useful target for cross-compilers, just as the JVM supports languages like Kotlin. There may not be much financial incentive to build a modern Cobol implementation, so having .NET as a base reduces both the work required and the associated risks. It will be interesting to see other languages follow Cobol and Otterkit to the cloud.
Copyright © 2023 IDG Communications, Inc.
Be First to Comment