Posted on

COBOL: Not only for mainframes

Recently, there’s been a lot of news about growth in opportunities for work in the COBOL language, owing to a resurgence of the IBM mainframe platform both to support mission-critical applications in key industries and to take advantage of IBM Z cloud computing capabilities. While IBM Z accounts for the majority of existing COBOL applications, the language is relevant to other platforms, as well.

Historically – if I may use such a word for an industry less than a century old – the computing market has been segmented into more levels than just “micro” and “mainframe.” Mid-sized enterprises have long faced a dilemma: Use relatively inexpensive microcomputer equipment and systems that barely keep up with the company’s demand for computing power, or pay heavily for mainframe systems that have several times more capacity than the company will ever use.

To serve that market, a number of computer companies provided midrange computers.

Most of the media play centers on the big iron – IBM Z – but midrange systems are in the same position today with respect to legacy systems and virtualization, and with respect to the generation of people who have been supporting them going into retirement. Companies have significant investment in and dependency on legacy systems, and the old systems are being modernized and cloud-enabled.

Which programming language do you suppose people used to write most of their applications on midrange systems? You guessed it: COBOL.

Continue reading COBOL: Not only for mainframes

Posted on

Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed

I began my career working on IBM mainframes in 1977, moved away from that platform gradually from about 1987 to about 1994, and have recently begun to return “home” again (also gradually). I have been heavily influenced by some of the advancements in software development in the world of Java, C#, and similar languages.

As I work more closely with mainframers and with vendors and open source developers who focus on the IBM mainframe platform, I’m confronted with cultural differences between those who work on mainframes and those who work, as mainframers put it, in the “distributed” world (that is, everything that isn’t a mainframe).
Continue reading Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed

Posted on

Notation and Thought in Unit Testing

The paper “Notation as a Tool of Thought” by Kenneth E. Iverson of the IBM Thomas J. Watson Research Center was published in the Communications of the ACM, Volume 23, Number 8, 1980-08. It’s available online at https://www.jsoftware.com/papers/tot.htm. Thanks to John Arundel (https://twitter.com/bitfield) who called attention to the paper in a tweet.

The paper deals with the way an appropriate notation influences people’s thinking in a given domain. Iverson was interested in the domain of mathematical computing, and he uses the APL language to illustrate his ideas. APL is an array-processing language Iverson developed in the 1960s. It has a following even today. You can read more about it on the APL Wiki at https://www.aplwiki.com/. You can try it out online here: https://tryapl.org/,

In this piece, I’m going to stretch the point a bit and apply some of the principles of notation Iverson presents in his article to a different domain: unit testing of application software.
Continue reading Notation and Thought in Unit Testing

Posted on

Microtests and Unit Tests for z/OS Applictions

The idea of “unit testing” is pretty well-known in programming circles. Everyone has some concept of what it means and most software developers practice some form of unit testing.

Yet, there is disagreement about unit testing. If you’re trying to get a handle on this topic for purposes of supporting existing applications in a z/OS environment, you may find a lot of contradictory information online. Opinions are often presented as facts, and are defended strongly. I’d like to try to tease some of that apart so you can make practical sense of it.
Continue reading Microtests and Unit Tests for z/OS Applictions

Posted on

Cobol Rising

As early as the mid-1980s, people were quite certain Cobol was on its way out. Most of us looked for opportunities to learn emerging technologies and shifted our career focus away from Cobol and from its primary platform, IBM mainframes.

At that time, opportunities opened up for those who understood the old technology and could help re-implement solutions in the new. It was a way for us to learn other technologies and build a new career path.

There was pressure to replace older applications based on Cobol, as the mainframe was due to die at any moment.

Cobol forgot to die

But a funny thing happened on the way to the cemetery. Writing in Forbes in July, 2020, Tom Taulli notes:

  • “[Cobol] powers about 80% of in-person financial services transactions and 95% of ATM swipes.
  • On a daily basis, it processes $3 trillion in commerce.
  • There are over 220 billion lines of code and 1.5 billion are written each year.”

See COBOL Language: Call it a Comeback?.

Continue reading Cobol Rising

Posted on

COBOL is not the problem

In the midst of the Coronavirus pandemic, there’s a lot of buzz on social media about a sudden need for COBOL programmers to help US State government agencies cope with the problem. IBM is even offering free COBOL training courses through a partner that specializes in mainframe-focused technical training.

But what’s the problem, really?

Domino #1: Coronavirus, knocks down domino #2: Constrained mobility, which knocks down domino #3: Reduced demand for workers, which knocks down domino #4: Increased unemployment rate, which knocks down domino #5: Increased demand for State services, which bangs its head against wall #1: Inadequate computing capacity to handle the increased workload.

Many of the State government computer systems are written in COBOL. Therefore (the reasoning goes), there’s a desperate need for more COBOL programmers.

Let’s pause for a moment and take a deep breath (through our masks, of course).
Continue reading COBOL is not the problem