As much as enterprise IT evolves, we’re left running old hardware and software for many reasons. Perhaps there’s a regulatory requirement to keep data for as long as possible; perhaps there’s a dependency on code that remains 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’s not going away is the mainframe, especially in government and finance. A lot of critical data and software runs on those systems, and they’re not as outdated as we might think, running hypervisors and multiple operating systems—including up-to-date Linux distributions.
We now have a lot of options for building applications that work with those legacy systems, including technologies like the latest .NET releases. We’re not limited to the familiar .NET languages either, as the underlying runtime and compilers are accessible by a mix of commercial and open source language implementations, including some designed for working with mainframe data.
There’s still a place for Cobol
One language familiar 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 standardized by ISO. It might not have the popularity that it had 50 years ago, but there’s 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 costly, so the ability to develop and test on desktop PCs is increasingly important. That’s where technologies like .NET come in, allowing you to work with familiar development tools before running code on a mainframe Linux VM or hosting it in the public cloud. With several different .NET Cobols available in a mix of commercial and open releases, you’ve got a choice of tools. One of the more interesting options is the recently unveiled 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 .NET releases. Although it’s still under development and not recommended for production, it’s an interesting example of how the .NET community is expanding the platform and tools beyond the core Microsoft languages, providing support for older technologies as well as the latest cloud-native approaches.
Getting started with Otterkit is easy enough. The project is hosted on GitHub, and you can install it from NuGet via the .NET command line onto a .NET 7 host. It’s interesting to see a project taking a dependency on the latest .NET, though as it’s currently under development, this is less of a risk 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 of cloning the Otterkit repository and building from source.
A first look at Otterkit
It’s still very early days for Otterkit; the compiler only recently produced its first running code. The compiler pipeline is more a cross-compiler for now, as it takes your Cobol code, uses it to generate C#, which is then compiled using the .NET compiler, ready to run as a stand-alone 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 language.
There’s a lot of value in working with fixed formats like Cobol’s. It makes code easier to read—something that’s important with a language designed to be easily readable so non-specialists can quickly understand your code. This speeds up working with stakeholders and can aid in bringing Excel or similar applications across to a formal setting.
There’s no need for additional libraries at this point, as Otterkit is planned to include a standard library that should support most operations. For now, it offers a basic compiler pipeline and support for basic commands. For a new project that’s not bad, as it’s now public and accepting pull requests. Cobol might not be a fashionable language, but there’s definite demand, and that should drive community engagement.
For newcomers to the language, the formal structure of a Cobol application may seem a little odd, but once you start thinking of the divisions as ways of defining data connections and local variables, it starts making a lot more sense. A good editor should let you set tabs to space program elements correctly, and existing Cobol linters and language servers for Visual Studio Code can bootstrap a development environment. Hopefully, Otterkit will have its own tools in due course.
Modernizing Cobol with .NET
What’s perhaps most interesting about Otterkit taking a dependency on .NET 7 is its support for building containerized .NET applications. You now have the option to modernize existing Cobol code, updating 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, reducing risks by isolating your code from unnecessary resources and other applications.
Otterkit includes a way of translating Cobol to C#, which gives you a possible path to moving Cobol code to more modern languages. Use existing Cobol skills to migrate code to the latest releases, 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 come together is interesting. .NET’s well-documented APIs and languages make it a useful target for cross-compilers, much like the way the JVM supports languages like Kotlin. There might not be much of an economic incentive to build a modern implementation of Cobol, so having .NET as a foundation reduces both the required work and the associated risks. It’ll be interesting to see other languages follow Cobol and Otterkit to the cloud.
Copyright © 2023 IDG Communications, Inc.
