COBOL Challenge: Answer to #2
I hope you have been enjoying the COBOL challenges that Jessielaine Punongbayan has been creating. To bring you up to speed, you can find them here. In this latest challenge, we took an existing program from the Open Mainframe Project’s COBOL programming course and enhanced a report, adding in a few bugs to tackle along the way. The aim of this blog is to walk you through the process of resolving those errors.
First a little background. CBL0106 is a COBOL program that was derived from CBL0006. The source for this program can be found in the above GitHub project. If you were to compile, link and run this program, the output written to the PRTLINE DD would look something like this:
Screen 1:
CBL0006 takes a list of accounts and displays information about each one in a financial report. In addition, it tallies all of the accounts that are from the state of Virginia.
Our fictional data includes an account limit and an account balance. If you notice, some of the balances are above the limit. CBL0106 adds a new line to this financial report that sums the number of accounts that have a balance over the limit. If you were to compile, link and run CBL0106, the output would look something like this:
Screen 2:
Notice that the last 2 lines of the report are not correct. The second to last line previously displayed the number of accounts in Virginia. It appears to be corrupted. The last line shows the accounts that are over the limit. But the number is 46. That doesn’t seem right. That looks like it is counting all accounts. Let’s tackle that one first.
If I were to know nothing about this program, I would likely edit the source and do a find for ACCOUNTS. Using Zowe Explorer and my COBOL Language Support extension, I’m positioned in the source to this set of code:
Screen 3:
I am in the WRITE-OVERLIMIT subroutine. This subroutine will set up the record to be written in OVERLIMIT-STATUS and then write the record. It looks like SUB1 is used to tally the number of accounts that are over the limit. So let’s see when SUB1 is updated. If I right click SUB1, I can choose ‘Find All References’. Doing this shows only one place where the variable is updated, ADD 1 TO SUB1. Choosing that brings me to the code I am interested in:
Screen 4:
The IS-OVERLIMIT paragraph tests if the account limit is less than the account balance. If it is, it moves some information to an array. However, SUB1 has 1 added to it outside the IF statement. This ADD statement should be inside the condition, between the IF and END-IF statements. Making that change and rebuilding the program produces this REPORT:
Screen 5:
Ah, nice. Now the program is reporting only 7 accounts are over the limit. That sounds more reasonable.
Now let’s tackle the other bug. If you recall, that one looked more like something overlaid an existing part of the report.
If you remember, the report was supposed to have a line indicating how many accounts are from Virginia. (see Screen 1). So let’s return to the source and find the string ‘VIRGINIA’. The first occurrence is in the DATA DIVISION:
Screen 6:
We suspect that this variable is being overlaid with something. So let’s scroll up to see what variables occur right before it.
Screen 7:
Here we see an array. From the name, it looks like it holds all of the accounts whose balances are over the limit. After correcting the first bug, we are reporting that we have 7 accounts that are over the limit. But this array has only 5 occurrences. So it looks like we didn’t account for the possibility of more than 5 accounts that are over their limit. Let’s change this to OCCURS 20 TIMES. After rebuilding and rerunning the job, our PRTLINE now looks like this:
Screen 8:
Our overlay problem has been resolved and we have a legible report! Case closed, right? Well, not quite!
What we’ve done is to leave room for a slightly higher number of accounts exceeding their limits, but we haven’t eliminated the problem. In fact, sometime in the future another programmer might run into this exact same problem because all I’ve done is increase the threshold.
A better solution would be to test the subscript before updating the table, and display a clear error message when the limit is reached. And depending on your actual needs, you may even want to dynamically allocate storage for the array so that it can expand to be as long as it needs to be. But now I’m taking you into another blog entirely, perhaps something for another day.
As I mentioned earlier, I hope that you have been enjoying Jessielaine Punongbayan’s COBOL challenges. Keep an eye out for her next challenge and we will post a solution shortly after.
Happy coding.
