So, do you think your program is ready to test just yet? If you answered yes, then you may be missing a very crucial check – reviewing of the compiler output for any warnings and informational messages.
A healthy habit after creating a new COBOL program, or making changes to an existing program, is to look closely at the COBOL compiler output to ensure that all the warnings have been handled.
In my previous blog, I showed how the compiler can be used to remove dead code from your programs. In this article, I will attempt to show how a closer look at the compiler warnings could have saved abends and promoted stability in our production regions.
One of the production support groups supporting an application got a page for a S0C4. A standard analysis of the dump revealed that an array had an index value was higher than what it was supposed to be. The group was initially very confident that they had checks in multiple places to prevent this from happening.
After an initial investigation of the compiler output for warnings, my eye caught the PERFORM statement shown below.
1 XXXXXX PERFORM 2005-MOVE-INPUT
IGYOP3094-W There may be a loop from the "PERFORM" statement at "PERFORM
7069.01)" to itself. "PERFORM" statement optimization was
1 XXXXXX THRU 2500-EXIT
At first glance, this statement looks correct, but if you take a very closer look, you will notice that the programmer intending to use 2005-EXIT, mistakenly coded 2500-EXIT. This caused the index, in one of the paragraphs between 2005-EXIT and 2500-EXIT, to be continually incremented and eventually caused it to go outside its array bounds and come down with a S0C4 in production. If the compiler warning was heeded, this S0C4 could have been prevented.
Another production support group was paged to a bridge because the users experienced heavy clocking in the IMS On-lines. The IMS support group, and they noticed that there was one IMS MPP that was sitting for more than 20+ minutes and not coming out (either successfully or a U0240). Because it never came out, it kept holding all the database locks, thereby preventing additional transactions to access those databases, which in turn caused the clocking to compound.
A Strobe report on the MPP revealed that it was looping in COBOL code and pointed to the set of statements enveloped by the PERFORM statement below.
PERFORM VARYING WS FROM 0 BY 1
UNTIL WS > 99
……. Additional statements
IGYPG3173-W The result of the comparison of operands WS and 99 is known at
compile time, based on the attributes of the operands. Unconditional
code was generated.
Because this loop was executed in an IMS MPP (online transaction), the IMS transaction did not get a U0240 timeout abend since the loop was in COBOL. Since IMS does not know that you are looping in COBOL code, you cannot ABDUMP this transaction leaving you with the only option of issuing an Omegamon KILL to free this transaction.
The solution in this case was to use a PIC 9(03) variable to allow the variable to “grow” beyond 99.
Had the developer paid close attention to the compiler output, such situations could have been prevented.
I could go on and on about the beauty of the COBOL compiler. The above two cases are just a fraction of what the COBOL compiler can does for you.
So, the next time you are paged to a bridge, take a look at the compiler listing of the programs that are involved, your solution might lie with what the soothsayer had “warn”ed you about!
PS: If you want additional information, or would like to see specific topics to be covered here, please contact me via email at firstname.lastname@example.org .