Troubleshooting
Problem
With the inclusion of the DB2 Embedded Coprocessor in the z/OS XL C/C++ compiler, the variable names "SQLCODE", "SQLSTATE" and "sqlca" are considered compiler reserved keywords, and will cause compiler errors if used as user host variables.
Symptom
When compiling code that uses "SQLCODE", "SQLSTATE" and "sqlca" as variable names, compiler errors may occur when using the DB2 Coprocessor. See the following example:
>cat foo.c
EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL INCLUDE SQLCA;
EXEC SQL END DECLARE SECTION;
int foo()
{
int SQLSTATE;
int SQLCODE;
int sqlca;
int temp = SQLSTATE + SQLCODE;
return temp;
}
>xlc -c -qsql foo.c
WARNING CCN3865 DSNH527I DSNHOPTS THE PRECOMPILER OR DB2 COPROCESSOR ATTEMPTED TO USE THE DB2-SUPPLIED DSNHDECP MODULE.
ERROR CCN3277 ./foo.c:7 Syntax error: possible missing ';' or ','?
ERROR CCN3334 ./foo.c:8 Identifier sqlca has already been defined on line 7 of "./foo.c".
ERROR CCN3334 ./foo.c:9 Identifier sqlca has already been defined on line 7 of "./foo.c".
ERROR CCN3021 ./foo.c:11 Expecting struct or union.
ERROR CCN3021 ./foo.c:11 Expecting struct or union.
CCN0793(I) Compilation failed for file ./foo.c. Object file not created.
>
Other syntax errors are possible depending on how the variable names are used. If the variable names are used within embedded SQL, syntax errors also occur.
Cause
Using "SQLCODE", "SQLSTATE" and "sqlca" as keywords is a compiler design caused by the migration from the DB2 precompiler to the DB2 coprocessor. The previous design in the DB2 precompiler obtained the definition of these keywords from the <sqlca.h> header file, and it was possible to use #undef to undefine "SQLCODE" and "SQLSTATE", though this was improper usage.
With the DB2 coprocessor, the compiler recognizes these variable names as internally registered keywords with specific meanings. Using these keywords will create compile errors.
SQLCODE: A long int named "SQLCODE" inside an SQL BEGIN/END declare section.
SQLSTATE: An array of size 6 of chars (signed OR unsigned) named "SQLSTATE" inside an SQL BEGIN/END declare section.
sqlca: A variable of ANY type named "sqlca" inside an SQL BEGIN/END declare section.
Resolving The Problem
The compiler errors can be solved by renaming the variables.
Within an SQL BEGIN/END statement, errors involving variable names "SQLCODE" and "SQLSTATE" can be worked around by changing the type of the variable, as only the type/variable name combination noted in the 'Cause' section are considered keywords. For example, the type of SQLCODE can be changed to long long, and the type of SQLSTATE can be changed to char[7].
Another scenario where these keywords could cause an issue is if "SQLCODE", "SQLSTATE" or "sqlca" are being used as column names in a DB2 database. This is valid usage, but identically named user host variables will still cause an issue. To remedy this, it is possible to use aliased user host variable names to access these column names. There are two methods that can be used to circumvent the problem. These methods are described in detail in the IBM DB2 document, "SQL Reference, Volume 1", Chapter 4 --> SQL Queries, and the following constraints are taken into considerations:
a) There are columns named "SQLCODE" and "SQLSTATE", and these names cannot be changed.
b) There are host variables named "SQLCODE" and "SQLSTATE" that are used to hold the contents of these columns.
SQL column names do not have to match the C character set (that is, it is possible for the column names to contain spaces, or to start with characters like $), which means that there are alternative ways to access these columns with the column names remaining unchanged. There are two alternative column accessing methods that can be used to work around the problem:
i) Change statements of the form:
SELECT SQLSTATE, SQLCODE, ... FROM ...
to the more general:
SELECT * FROM ...
and then access the columns using numbers (as character strings) generated by DB2. This method is documented in the previously mentioned SQL document. This will allow the renaming of the SQLCODE and SQLSTATE host variables, without having to rename the table columns.
ii) As an easier solution, aliases can be created in the program for the column names, which will allow changes to the host variable names to match the aliases. For example:
SELECT SQLCODE as SQLCODE2
The host variable can now be renamed to SQLCODE2 as well, and bind properly.
Was this topic helpful?
Document Information
More support for:
z/OS XL C/C++
Software version:
1.8, 1.9, 1.10, 1.11
Operating system(s):
z/OS
Document number:
129753
Modified date:
23 June 2018
UID
swg21408225