5 Reasons Why COBOL is Ideal for Remote Computer Work

Background from Canva, Edited in Canva by the Author

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?



Author: Donna Jennings

I have a BA and a BComm, as well as a Diploma in Programming. I have been a COBOL system designer and coder for over 25 years, and I am still trying to demystify the language for myself...I Love the culture of COBOL and how it has provided so many people, including myself, with a lifelong livelihood. The opinions in my posts are completely my own, based on my many years of experience working in a COBOL development environment.

Leave a Reply

Your email address will not be published. Required fields are marked *