When running your DB2 application on either a workstation or OS/390, errors encountered during static execution of SQL statements can be debugged using the sqlca variable that is set when an SQL statement is executed.
Note: | Some embedded SQL statements (for example, DECLARE CURSOR) cause Smalltalk source to be generated but will not result in the setting of the sqlca. |
The object in the sqlca variable is a subclass of OSPtr, and its contents are described in the application programmer guides for both DB2 for workstation 2 and DB2 for OS/390. The printOn: method has been defined for the sqlca to provide a useful description of the sqlca in an inspector window.
In the SQLCA, look for the sqlcode, which contains an integer return code. See DB2 Messages and Codes for an explanation for the return code. Other useful fields in the sqlca include the sqlstate, a five-digit code that sometimes offers more information on what happened, and the sqlerrmc, a field that lists the tokens referred to by the sqlcode and sqlstate descriptions.
DB2 applications require additional steps to build and install on OS/390 and there are several common SQL return codes (in the sqlca) that indicate a setup or build error:
A BIND message that your DBRM is in an inconsistent state indicates that the DBRM name stored in the DBRM is not the same as the member name of the DBRM in the library. The DBRM name is an attribute of the AbtPackageSpec and can be set using the TrailBlazer browser in your Smalltalk development image. Once changed, the AbtPackageSpec must be precompiled and your application must be repackaged.
Halting your application during execution on a workstation can leave your development image in an incorrect application state (for example, cursors might be left open). This incorrect state can cause errors when you run your application again.