Coding Demystified–10 Steps in a COBOL Fix

Background from Canva, Edited in Canva

When people think of a COBOL programmer, they no doubt envision someone, head down, working in a bubble, coding all day, creating new, exciting software products. In reality, aside from the rare new development work that may actually result in all-day coding sessions, a programmer’s job involves a procession of coding fixes on already implemented code. This article discusses 10 of the main steps you will find in one of these pieces of work, from the perspective of an experienced programmer of over 27 years.


1.  Understand the Problem

If you are a Programmer/Analyst, you will inevitably be assigned a coding issue to resolve. It will be some defect in the existing code, discovered by a tester or maybe a fellow programmer. This issue will be presented in writing or verbally. Your first job will be to interpret the problem and understand it yourself. This is what is referred to as analysis.

2.  Articulate the Problem

If the issue has been recorded in an incident report, there will already be a written description of the issue, made by the reporter. If it has been verbally reported, it will be up to you to explain the problem in such a way that others will understand it. For example, you, as a programmer, will be expected to describe system issues in a non-technical way for a User to understand.

3.  Discuss the Problem with the Client

Once you put the problem into your own words and have an understanding of the issue involved, you will need to make the client aware that there is a problem. This requires excellent communication skills in order to adjust to a business-oriented audience. This discussion should result in a written requirement.


4.  Identification of the Fix

Since the problem has now been articulated and recorded, it needs to be fixed. A potential solution should take into account, not only the area where the problem has occurred but also other parts of the system that may be impacted. Designing a solution requires the programmer to basically have an understanding of the whole system.

5.  Get Approval to Implement a Fix for the Problem

When an appropriate fix has been identified and designed, communication skills again come into play. This time the programmer must communicate the proposed solution to the client in a way they understand. The goal here is to get approval to implement the intended fix.

6.  Document the Problem—Specifications

At this point, the programmer is almost ready to make the change. Before diving in to code, however, it is important to create system specifications. These specs are an aid for the programmer making the change as well as documentation that can be used as a reference later on. They may be in the form of a flow chart, pseudo code, or even a word document description.


7.  Implement the Solution

Finally, it is time to start coding. Depending on the problem to be solved, the coding change may range from one line to many lines. It may take several days or just a few minutes. As well as making the coding change, this part of the solution involves compiling your change. The compiler will check the syntax of the new code and report any errors.


 8.  Unit Test the Fix

When the compiler errors have all been resolved, it is then time to unit test your implemented code. This is generally programmer testing to determine that the code is functioning as expected. Depending if it is an online or batch solution, you may test your code by accessing it through a CICS screen or by running a batch JCL job.

9.  User Acceptance Test

If the code has successfully run in Unit test to the satisfaction of the programmer, it will be made available to the client, or User, to perform User Acceptance testing. Before final implementation, the User will carry out enough tests to ensure that the solution fulfills the requirements decided on earlier.


10.  Maintain the Fix

The implemented code is still subject to future modifications. The requirements may change, resulting in necessary maintenance of the revised code. This will be ongoing for as long as the code is in use.


As you can see, writing code is just one skillset that a COBOL programmer is expected to master during their career. They must also excel as analysts, communicators, writers, and testers. It can be very satisfying to have a job that provides such a variety of challenges.



COBOL Plus JCL Equals Magic

Background from Canva, Edited by the Author in Canva

The Initiation

I’ve had a love-hate relationship with Job Control Language (JCL) ever since my first encounter with it back in the 1990s. If you wanted to program in COBOL, which I did, there was no way to avoid JCL. All beginner programmers had to complete a week-long JCL tutorial with information similar to that found in this current IBM Basic JCL Concepts tutorial. Of course, almost 30 years ago, my JCL tutorial was presented on a green screen in a non-graphic, dry way. I probably learned more in my first hour running my own JCL job than I did that whole week reading screen after screen of info that seemingly had no context.

The Effort

At the beginning of your career, which is what it will become if you have the tenacity to continue as a COBOL programmer, you can’t begin to comprehend how much time you will spend with JCL over the years. Early on, you may spend hours trying to figure out why your job isn’t running at all or why it abends in a step when it logically shouldn’t. You pour over the job output looking for clues, only to find that you’ve somehow added an extra space in your Jobcard, or your output file doesn’t exist when your job expects it to.

The Understanding

As time goes on, after you have run a few jobs and debugged a few outputs, it starts to become a bit clearer that there is a method to this madness. Maybe by this time, you have actually written a Batch COBOL program yourself that reads input, perhaps from a file, performs some processing, and writes output to another file. How do you get that program to run and produce that output? You wrap some JCL around it to tell it what file to use as input and where to save the output. Your job may even be scheduled to run at a certain time through a job scheduler like Control-M.

Graphic created by the Author

The Reward

In the end, if you stick with it, it can be a very satisfying experience to understand JCL, create a job, and run it successfully. There is something rewarding, almost magical, about producing JCL that runs your own COBOL program and produces an output that you can see. It took time, but it is a skill that I am happy I have learned and that I use almost daily.

What is your experience with JCL? Did you put in your own effort to come to understand it and, in the end, find it rewarding?