You might consider changing your applications to use the SQL diagnostics area instead of the SQL communications area (SQLCA), because the SQL diagnostics area provides some significant advantages over the SQLCA.
One of the best reasons is that the SQLERRM field in the SQLCA is only 70 bytes in length. This is often insufficient for returning meaningful error information to the calling application. Additional reasons for considering the SQL diagnostics area are multiple row operations, and long column and object names. Reporting even simple warnings is sometimes difficult within the restrictions of the 136 byte SQLCA. Quite often, the returned tokens are truncated to fit the restrictions of the SQLCA.
Current applications include the SQLCA definition by using the following:
EXEC SQL INCLUDE SQLCA; /* Existing SQLCA */
With the conversion to using the SQL diagnostics area, the application would first declare a stand-alone SQLSTATE variable:
char SQLSTATE[6]; /* Stand-alone sqlstate */
And possibly a stand-alone SQLCODE variable:
long int SQLCODE; /* Stand-alone sqlcode */
The completion status of the SQL statement is verified by checking the stand-alone SQLSTATE variable. If upon the completion of the current SQL statement, the application chooses to retrieve diagnostics, the application would run the SQL GET DIAGNOSTICS statement:
char hv1[256]; long int hv2; EXEC SQL GET DIAGNOSTICS :hv1 = COMMAND_FUNCTION, :hv2 = COMMAND_FUNCTION_CODE;