Blog: A Smooth Transition

How I came to Know COBOL

As a sophomore in College I learned to program in both FORTRAN and COBOL utilizing 80-column punch cards. Each spring semester we used to compete to see how high we could make the tallest structure from the used cards in the atrium of the Engineering building.  The winning team always made it more than two stories high. More than 20 years prior (1959) a group of programmers had devised COBOL, a Common Business-Oriented Language, yet we did not consider what we did was becoming extinct.  We also never imagined that COBOL would still be in use in the year 2020 by numerous parts of the financial industry; 43% of banking systems, 80% of personal transactions, 95% of ATM transaction use COBOL  (Reuters 2017).   Now these systems are considered “Legacy Systems” built on a “Legacy Application”, however their use in today’s environment is considered mission-critical for commerce.

Punch Card


It all started with writing the program on a COBOL coding form designed for the punch card. Yes, we were taught to create a flowchart prior to coding but we all know that seldom happened so we created one to turn in after the program was complete.

COBOL Coding Form


Then we painfully typed each line of code onto the punch card via a punch card machine.

Punch Card Machine


Then I spent hours standing in long lines at 2 AM waiting for my turn at the compiler, hoping to not have a card bent during the process, and then frantically trying to smooth out the bend so I could recompile the large deck of cards-- Why 2 AM?  We were time-sharing the computing resource of the mainframe with the city of College Station and were only allowed a minimal amount of funds to run these programs.  The cheapest time was after batch in the middle of the night: Twenty cents versus a dollar and twenty cents-- Then off to Taco Bueno for a late night snack while waiting for my program to run.

Program Machine

My first encounter with the now “legacy technology” occurred at least a decade prior when my father began his career as a COBOL programmer. He would take me to the Army post where we were stationed, in the middle of the night, when there were issues with the mainframe or batch processing.  The setting was much different than today’s data centers; the mainframe was located in a series of trailers attached to a normal office building via a walkway.  One trailer contained the keypunch machines and printers, the next trailer the mainframe; all had the ability to run separate from the building power on generators.

Mainframe Truck


Who is Still Using COBOL?

Just because COBOL has been around longer than I have been alive does not mean it is inappropriate or has outlived its usefulness.  Still today, legacy systems written in COBOL and hosted on the mainframe are plentiful in the public and private sectors. Their demise is talked about often, but seldom accomplished.

COBOL is designed for reliable, high volume data processing and it accomplishes that purpose very well.   The IBM Z mainframe can execute 1.2 million transactions per second. Walmart runs an average of 500 million transactions per day on CICS at 10% of the cost of other solutions.  A 2019 survey by Forrester found that 56% of those surveyed planned to increase their mainframe usage over the next two years, while 36% planned on the same amount of use.  Doing the math, we can deduce that only 8% plan to lower their usage of mainframe by the year 2022.


Why COBOL Made Headlines in 2020

Yes, COBOL is outdated as a general-purpose language but nothing beats its high volume data processing.  A language’s age is not a direct indicator of obsolesce.  The fact that COBOL has been around this long stands to reason it is resilient and adaptive when solving mission critical business functions.  

So why, earlier this year, were we told that “obsolete” COBOL was to blame for the technology issues surrounding several State’s unemployment systems during March and April 2020?  (Sidebar: Thankfully the State of Nebraska had modernized just months prior to the unexpected spike in unemployment applications and the site remained functional.)  My belief is that the issues those states experienced were caused by problems that occurred on the front end of the website (obviously not written in COBOL). They wrote a web front end for the appearance of a modern customer interface, but did not anticipate the tremendous increase in capacity that occurred with Covid. My secondary belief is that the developers did not understand the backend power of the mainframe to take advantage of its processing ability.  There is a small possibility there could have been an issue with the mainframe itself, but with the processing speed of over a million transactions per second, I doubt that would be the issue.

Rather than blame the language, my instincts point to neglect.  To say, “we failed to manage the life-cycle of legacy applications”, is not easy to admit. Even more of a challenge is admitting that instead of integrating, we bolted on systems.  No matter the technical language in use, as developers we must hold ourselves accountable to documenting our code and the interfaces we build. Just like in College when my last task before turning in my programs was to reluctantly provide a flowchart and to add comments to my code, these same poor habits are unfortunately widespread and have seemingly gone unmanaged.  When developers neglect to document a legacy system it becomes a literal black box. Too many times, this is where neglect sets in, and this must change.

State governments put millions into legacy systems yet most often are reluctant to spend the resources or money on the operational oversight needed for maintenance. In the end applications simply work to produce output. We need to jump one step further in our development language discussions.  Delving into no-code/low-code would allow the business to maintain the data on the mainframe, introduce an interactive web front end, and make use of the power of the mainframe system. No-code/low-code supports speedier development and deployment of solutions, and if planned well, maximizes the life of legacy systems.  It allows for migration versus the costly and high risk rip and replace strategy.  Legacy transformation maintains and extends the investment and value of the legacy system through migration to new platforms.  This transformative process does not take place quickly by design. 

I believe no-code/low-code addresses the genuine need to modernize in order to meet the increasing citizen expectations, particularly around case management and process automation.  The State of Nebraska has been utilizing low-code for our Enterprise Content Management (ECM) application for several years now in combination with Agile development and we have realized the benefits of rapid deployment. The result is enhanced applications with customer-facing workflow automation. Small changes and also small failures are more palatable to the business and our customers. Updated functionalities can be added to meet business requirements not being met by the legacy application, which include enhanced browser and mobile access capabilities along with self-service for our customers.


Summing it Up

A better understanding of citizen needs will help close the more significant issue which are the process gaps that exist in legacy systems. States should be delivering solutions that enable productivity gains for both the State and our customers. Forms submitted by citizens online and then re-entered into the legacy system should be closely examined.  Taking this approach will allow us to efficiently migrate and update business functionality from the legacy systems into the production environment, using middleware to integrate with the backend functions still supported by the legacy system. Low-code tools enable organizations to build software with professional developers in far less time especially web and mobile applications while minimizing the need for native programming.  Lower cost with improved and rapid results via agile development will accelerate low-code platform growth and acceptance.

As always, I appreciate your hard work and respect for the taxpayers of the State of Nebraska, which you show each and every day.


As always, I appreciate the work you have all done to support the needs of the citizens of Nebraska, especially during these challenging times.