This article addresses the unpredictability of the value in the RETURN-CODE special register once COBOL has called an Oracle routine.
Problem:
In an application that uses Pro*COBOL, COBOL passes control to Oracle routines (for example, during a SQL CONNECT), after which the flow of control returns to COBOL. On one occasion the COBOL special register RETURN-CODE had been modified by Oracle and that it carried a large and meaningless value. This was despite the fact that the SQL statement had succeeded and the SQLCODE was zero.
As a rule COBOL does not modify RETURN-CODE (except if the program contains RETURNING syntax or if a fatal runtime error occurs). A meaningless value supplied by Oracle will remained unmodified within COBOL. At the end of the program, COBOL will report this RETURN-CODE to the invoking shell.
The shell can access it via "$?", for example:
cobrun myprog
if [ $? -ne 0 ]
then echo "non-zero return code"
fi
On one occasion, a shell script noticed the non-zero return code from COBOL and reported that something had gone wrong with the COBOL program, when in fact the program had succeeded. It was a mystery why Oracle had supplied a non-zero return code, considering that the CONNECT (and indeed all other database accesses) had completed successfully. Why is it so unpredictable?
Resolution:
Oracle’s documentation, in the Pro*COBOL Precompiler Programmer's Guide, Appendix B "Operating System Dependencies", says:
-- RETURN-CODE Special Register May Be Unpredictable.
The contents of the RETURN-CODE special register ... are unpredictable after any SQL statement or SQLLIB function.
Oracle customers with a username/password can access the Pro*COBOL documentation on the Oracle web site, otherwise a web search on "Pro*COBOL RETURN-CODE" should show Appendix B.
Based on this, Micro Focus customers can safely MOVE 0 TO RETURN-CODE after all SQL calls to avoid unpredictable return codes being reported to the shell.
Another approach might be to insert MOVE 0 TO RETURN-CODE as the last statement executed in the program, instead of after each SQL call. This approach would be safe only if the program makes no other use of RETURN-CODE.
Incident Number: 2128966
