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 ACUCOBOL-GT 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. Since 9D takes two bytes and DBMaker secondary errors can be five bytes in length, the first parameter should be pic x(7).
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, for ACUCOBOL-GT Version 4.0, you might use the following format:
runcbl -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 an DBMaker error message that means syntax error. This is usually caused by having a field name that is a reserved word for DBMaker. 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 one of the options shown below, and turning on Trace Files (TF) when execution begins:
runcbl -dle errfile -x yourprog
(for ACUCOBOL-GT Version 4.2 or later, 32-bit runtime)
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 n <return>
where n is a number from 1 to 9. The higher the number you enter, the more debugging information you receive.
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.
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: 955
An existing object already uses name.