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