As we all know every COBOL program, when compiled, produces a compile output. The compile output shows a list of the severe errors, warnings and informational messages in your program. Severe errors terminate the compilation and throw a Return Code RC=12. Warnings and Informational messages throw a Return Code RC=4, and proceeds to link-edit and generates a successfully compiled and executable code.
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.
Case 1:
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
not attempted.
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.
Case 2:
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
END-PERFORM
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.
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.
Case 1:
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
not attempted.
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.
Case 2:
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
END-PERFORM
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.
Even though nothing obvious jumps out from this innocent looking PERFORM statement, a closer look at the PIC clause of WS variable reveals that it is a 9(02) variable. This essentially means that no matter how you increment, the WS will NEVER be greater than 99 causing this PERFORM statement to go into an endless loop.
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!
Happy compiling!
PS: If you want additional information, or would like to see specific topics to be covered here, please contact me via email at pkganapathi@yahoo.com .
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!
Happy compiling!
PS: If you want additional information, or would like to see specific topics to be covered here, please contact me via email at pkganapathi@yahoo.com .
