You can retrieve a secondary error code by using selected runtime options or by calling the library routine C$RERR (described in Appendix I of the compiler documentation). Note that you can pass two parameters to C$RERR for interface errors (rather than just one). The first parameter retrieves the complete code; the second parameter retrieves a message associated with the error condition. Since 9D takes two bytes and Oracle secondary errors can be four bytes in length, the first parameter should be pic x(6).
Here are three methods for storing the complete error code along with some helpful text that describes it.
Method One
At runtime, if you specify an error file and use the -x option, the runtime puts the secondary error code and some text associated with the error into the error file. You'll see two levels of error codes in the file.
For example:
runcbl -le errfile -x yourprog-l causes the contents of the runtime configuration file to be included in the error output
-e causes the error output to be placed in the file named immediately after the option
errfile is the user-specified name of the error file
-x causes the secondary error numbers to be included
yourprog is the name of your object file
The text of the error would then have this format in the file:
***File system error value = 3 ***
*** Dictionary (.xfd) file not found ***
File error 9D,03 on filename
Dictionary (.xfd) file not found
Method Two
Occasionally you may receive an Oracle error message that means syntax error. This is usually caused by having a field name that is a reserved word for Oracle. We can help you examine the error file and determine the cause of the problem if you receive this error code. We'll need you to rerun the program, specifying the options shown below, and turning on Trace Files (TF) when execution begins:
runcbl -dle errfile -x yourprog
Notice that the only change from Method One is the -d option, which turns on the debugger. The source code does not need to be compiled in debug mode.
After you press <return>, you will be at the debugger screen. Type:
tf <return>
FILE TRACE will be echoed on the screen. Type:
g <return>
You will now be running your program normally. Proceed until you encounter the error condition, and then exit. Your error file will contain the error information described in Method One, above, and will also contain the SQL queries that the interface constructed. Examining these queries can help us to determine the cause of the syntax error.
Method Three
You might want to separate the error codes and their associated text, and store them in variables. The variables can then be displayed to the screen or handled in whatever way you deem appropriate.
You saw an example of the usage of C$RERR in Using the sql.acu Program. In the simplified example shown below, we use the library routine C$RERR with two parameters to retrieve the complete error code (first parameter) and its associated text (second parameter).
DATA DIVISION.
.
.
working-storage section.
01 error-status.
03 primary-error pic x(2).
03 secondary-error pic x(4).
01 error-text pic x(40).
PROCEDURE DIVISION.
.
.
get-file-err.
call "C$RERR" using error-status,
error-text.
display "FILE ERROR: ", primary-error.
display "DATABASE ERROR: ",
secondary-error.
display error-text.
accept omitted.
stop run.
Here's an example of the output you might get from this:
FILE ERROR: 9D
DATABASE ERROR: 955
Name is already used by an existing object.
NOTE
See the Oracle: Common Questions and Answers section for more information, particularly regarding the use of the "oerr" syntax to find errors.