SQLCODE -516: DESCRIBE names an unprepared statement

What it means

DESCRIBE asks Db2 to fill an SQLDA with details of a prepared statement, such as how many columns a SELECT returns and the type and length of each one. Programs that build SQL at run time use it to set up storage before they fetch. Plain DESCRIBE is the same as DESCRIBE OUTPUT. DESCRIBE INPUT does the same job for the parameter markers in the statement.

DESCRIBE only works on a statement name that holds a prepared statement right now. When the name holds nothing, Db2 returns -516.

The reasons are the same family as -514 and -518. A failed PREPARE leaves nothing to describe. A COMMIT or ROLLBACK destroys prepared statements unless the package was bound with KEEPDYNAMIC(YES). And a prepared statement belongs to the package that prepared it. IBM has fixed at least one tool that issued its DESCRIBE from a different DBRM than its PREPARE, and that tool got exactly this code.

Common causes

• The PREPARE failed and the program went straight on to DESCRIBE without checking SQLCODE.
• A COMMIT or ROLLBACK ran between the PREPARE and the DESCRIBE, including one issued by a called subprogram, a CICS SYNCPOINT or an IMS checkpoint.
• The DESCRIBE is issued from a different program, and so a different package, from the one that ran the PREPARE. Generic SQL modules and tools that split the work across modules hit this.
• The DESCRIBE names the wrong statement, for example STMT2 when the code prepared STMT1.
• Db2 rolled back the unit of work after a -911 deadlock or timeout, and the program carried on.

How to find the problem

1. Look at the SQLCODE returned by the PREPARE for the same statement name. A negative value there is the real problem.
2. Check the statement name in the DESCRIBE against the name in the PREPARE.
3. Trace the commits. Look for COMMIT, ROLLBACK, EXEC CICS SYNCPOINT or IMS checkpoint calls between the two statements, in this program and in anything it calls.
4. If PREPARE and DESCRIBE are in different modules, check the precompile listings to see which DBRM each statement belongs to.
5. Check KEEPDYNAMIC for the package in SYSIBM.SYSPACKAGE if the program expects statements to survive a commit.

How to fix it

• Check SQLCODE after every PREPARE and stop on a negative value.
• Use PREPARE with the INTO clause. It prepares the statement and describes its output in one step, so there is no separate DESCRIBE to go wrong.
• Prepare again after every COMMIT or ROLLBACK, or bind with KEEPDYNAMIC(YES) if the program is designed to reuse statements across commits.
• Keep the PREPARE and the DESCRIBE in the same program. If a vendor tool gets -516, check for a fix from the vendor, since the cause is in their code.

What it looks like

DSNT408I SQLCODE = -516, ERROR:  THE DESCRIBE STATEMENT DOES NOT SPECIFY A PREPARED STATEMENT
DSNT418I SQLSTATE   = 26501 SQLSTATE RETURN CODE

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.