Modernization, Redesign, Renewal–A Revamp of a Legacy COBOL System

Given an outdated COBOL legacy system that is possibly 30 or 40 years old, there are multiple ways to do a rewrite that will breathe some new life into it.


First, you could do a COBOL modernization. Modernizing an application involves rewriting an existing COBOL application in a newer language, such as Java. It means interpreting the existing logic and converting it into the new language without reusing any of the existing COBOL code. The existing data storage may be reused in this method if you can connect to it through the new technology. For example, a Java to DB2 database implementation, replacing a COBOL to DB2 database implementation.


Another overhaul method is a redesign, which would entail rebuilding the current COBOL-coded logic into a newer design. This would, in effect, mean replacing the inevitable mishmash of spaghetti code that accumulates after 30 or 40 years of continuous coding changes. For example, the logic could be redesigned into a three-tiered model that separates out the presentation, business, and data layers. This type of modularization makes the code more efficient and easier to debug.


A third example of a revision is a renewal. This type of rewrite requires an analysis of the existing COBOL code, looking for possible improvements, and focusing efforts on those areas. Other items in the code that are functional are basically left ‘as is’ in this method. For example, this could mean pulling repetitive logic out of the existing system code and replacing it with a Business Rules lookup procedure. This would make the logic more efficient and easier to maintain.


As a COBOL coder for the last 25 years, these are the main types of rewrites that I have been part of or have seen. I am sure this is not an exhaustive list and there are probably as many permutations and combinations of possible restorative methods as there are system designers.

What are some of the COBOL Legacy overhauls you have seen? Why were they initiated? Did they go to completion? Were they successful?


A COBOL Programmer’s Second Month of Social Isolation

The Home Office

For the last two months, I have dragged myself out of bed every morning and downstairs to my cold office, still in my pajamas, hair unbrushed, where I sit all day in my home office. There is only a laptop, a corner of the desk, that I share with my husband and a cheap desk chair that was originally purchased for occasional use. Daily, I miss my large monitor and my ergonomic chair with my sizable cubicle space that was all mine.

I fire up my VPN, connect to the work network, and my Mainframe connection. I am all set to go when the VPN unexpectedly disconnects—as it does at random times during the day. I reconnect and let my team know I am available through our chat system. We all say (write) “good morning”, but we have not actually seen each other for weeks. I am lucky I worked with my team members personally before the virus hit and can picture a face to go with a name. The only people I see in person on a daily basis now are my two daughters and my husband who are socially isolating with me. These days, I get all my programming assignments through chat or email. It is definitely more of a challenge to work without being able to talk personally with other people on the team.

The Pre-Pandemic Office

In the before time, I would get up early to shower and get dressed in my business casual work clothes. Then I would drive out for my hour-long commute, stopping for a Tim Horton’s coffee and a muffin along the way. In my temperature-controlled office building, I rode elevators with other people in close proximity, brushed up against people in the hallways, attended daily meetings in rooms packed with people, ate in a full cafeteria, and didn’t give any of these activities a second thought. I also enjoyed saying “hello” to people in person and having brief “water cooler” conversations during the day. I especially took for granted being able to go to see coworkers at their desk when I had a specific question or just wanted to bounce an idea off them.

I did not realize at the time how fragile my daily routine really was. One day, I was at work, as usual, the next day, me and all my coworkers, country-wide, were sent home to work in isolation. My building was left deserted, my desk calendar, frozen in time, and my plants unwatered.

A couple of weeks after we started working at home, we got a broadcast from the property maintenance staff saying that a lightbulb in the building parking lot had been changed. We all had a (virtual) laugh at the irony in that, since the parking lot was now almost empty.

The Post-Pandemic workplace

We know we are not going back to the way things were before, but we have no idea what the “after pandemic” world will look like for a programmer. Maybe our current reality is actually the new reality. Perhaps, for a programmer, the new work environment will be remote work.  No more commutes, random socializing during the day, and unnecessary meetings. Ultimately, when all of the uncomfortable bugs are ironed out in the home offices and the new way of work becomes a habit, the result will hopefully be acceptance and increased productivity.

What is your new reality? Are you developing new habits?


5 Reasons Why COBOL is Ideal for Remote Computer Work

Especially with the recent world events, today’s society has so many available forms of remote communication software, such as video conferencing, teleconferencing, chat, and email, to name just a few. It should be a given that every Information Technology organization offers workers, who have proven their reliability and work ethic, the opportunity to work remotely at least for a few days a week.

Due to the stability of its environment, COBOL is particularly suited to a work at home scenario. This discussion assumes that the employer has given their employee remote access to log on to the corporate Mainframe. Presuming that the environment is also set up and accessible remotely, as an experienced COBOL programmer, these are 5 reasons why I think that COBOL programming should be considered a remote job:

  1. Environment Setup:

A Mainframe session can be connected to remotely and the programmer has ready access to the whole Mainframe development environment. There is no need to have servers or separate software on the remote computer. The programmer can log on to the mainframe, write and compile programs. They would also have access to CICS sessions to execute online programs, as well as JCL to run their programs in batch.

  1. Access to Connecting Applications

If your application needs to call, or be called by, another application, logging on to the Mainframe remotely facilitates access to these other applications. Some coordination is required to ensure that all of the applications have current versions and up to date data available, but all systems can work on the same mainframe, with the programmers doing the work remotely.

  1. Access to Test Data

The types of businesses that use COBOL are banks, insurance companies, government, etc. Due to the nature of these businesses and the fact that they support large amounts of data, a Mainframe is ideally suited for their purposes. As a result, when the remote COBOL developer logs on to the Mainframe to do their programming, they also typically have security-restricted access to large amounts of Mainframe test data.

  1. Ease of Coding

Since the syntax of COBOL is similar to natural language, it can be easily coded from system specifications. Given such specs, a remote programmer can effortlessly translate the user requirements into COBOL code without the face to face interaction that an analyst might need to have with the user in order to create the specifications.

  1. Many Programmer Roles

A COBOL Programmer generally wears several hats in their role. The programmer may have to interpret the system specs given to them by the analyst. In this context, they take on an analyst role. When their coding is complete, the programmer will also perform basic unit tests before handing it over for system integration and user acceptance testing. In this way, they become a tester. Since the programmer has so many responsibilities, they are always busy with measurable tasks. This is something fitting to remote work, since their work can be easily tracked.

These are some of the reasons why cities and organizations still ran well during a country lockdown with mandatory work at home rules. COBOL is basically a plug and play computer language.

As long as there is remote access to a Mainframe that has already been set up to code COBOL and an experienced programmer to write the code, working at home is quick and easy and should be considered on an ongoing basis.


Have you had experience with other languages that may be as easy to code remotely as COBOL? What would be the pros and cons of remote workers programming in other languages?



Yes, COBOL Coding is Social


Photo courtesy of Pexels

The picture of a COBOL programmer hunched over their desk, day in and day out, in isolation, pumping out thousands of lines of code is unrealistic, especially with the Agile mentality of today’s IT world. Currently, to be a successful programmer, in any language, you need to interact continuously with your client and your team in an effective way both orally and in writing.

Client Service

In fact, coding is essentially a client service. Someone has requested a piece of work from you, and you provide that client with a finished product, in accordance with their requirements. The client is then able to see the work as it progresses and provide feedback. In another version of client service, the coder may not communicate directly with the client. They may provide service to an intermediary, such as a business analyst who in turn passes along status updates and other information to the client. In any case, the COBOL coder is constantly involved in providing client service.

Photo courtesy of Pexels


The COBOL coder typically works closely with a team. The team may be comprised of a team leader, business clients, analysts, testers, coders, designers and whatever other specialized roles may be required. As previously mentioned, it is unusual for a COBOL coder to work in isolation. At a minimum, the program(s) being developed are attached to business requirements, often integrate with programs written by other coders and need to be tested.

Photo courtesy of Pexels

Effective interactive communication

In addition to writing program syntax in a logical way, the COBOL coder must also be able to communicate verbally as well as in writing. Programmers may need to attend several meetings a week to provide updates and answer questions as required, so they need to be able to communicate effectively vocally. In today’s context, they may even be expected to present, or demo, their work. Excellent written communication is also a must-have for a programmer. Their job may depend on being able to receive requirements and specification updates by email and being ready to respond to any questions/concerns that might come up.

Contemporary Programming

Programmers have moved on, but the out-dated misconception of them as loners, who rarely move out of their cubicle to interact with the outside world, has not. Programming can be a very exciting, interactive career, not the lonely one that is often portrayed.

If you are a programmer, do you agree? Disagree?

If you are not a programmer, take a minute and think of what your picture of a computer programmer is. What’s the first descriptive word that comes to mind? Is it a positive or a negative word?