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 manual). Note that you can pass two parameters to C$RERR for interface errors (rather than just one). The first parameter retrieves the code; the second parameter retrieves a message associated with the error condition.
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:
wruncbl -le errfile -x myprog
-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
myprog 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 a Microsoft SQL Server error message that means syntax error. This is usually caused by having a field name that is a reserved word for Microsoft SQL Server. You can examine the error file and determine the cause of the problem if you receive this error code. You'll need to rerun the program, specifying the options shown below, and turning on Trace Files (TF) when execution begins:
wruncbl -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 to determine the cause of the syntax error. You can call Acucorp Technical Support if you need help.
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 file-status pic xx.
01 error-status.
03 primary-error pic x(2).
03 secondary-error pic x(40).
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: 1608
A network error was encountered when results were sent to the front end. Check the Microsoft SQL Server error log for more information.