SQLCODE -901: System error, later statements can run

What it means

Db2 uses -901 for errors in its own processing that are limited to one statement. The full message text says the error does not preclude successful execution of subsequent SQL statements, and that's the key point. The thread is still usable.

Db2 for z/OS lists these causes when the statement didn't go to an accelerator.

• The statement length is less than 0 or more than the maximum allowed.
• Distributed commit processing hit an error. Servers that support two-phase commit back out the unit of work. A server that doesn't must be checked to see whether its changes were committed.
• Commit post-processing couldn't complete, so the commit failed. Typical reasons are an update that moves a row to another partition, a resource that isn't available, held cursors and unique constraint violations.

When the query was sent to IBM Db2 Analytics Accelerator, the message has a second form with an accelerator-info token holding the accelerator's own error.

Db2 may also request an X'04E' abend for the application. A program with a recovery routine can recover from it and retry. Db2 for LUW uses SQL0901N, and Db2 for i uses SQL0901, "SQL system error". Both use SQLSTATE 58004.

Common causes

• Dynamic SQL passed to PREPARE or EXECUTE IMMEDIATE with a wrong length field, for example a VARCHAR host variable whose length doesn't match the text.
• An error during distributed commit, with one or more remote servers in the unit of work.
• Commit post-processing that failed because a resource was unavailable, often reported on the console at the same time.
• An update that changes a row's partitioning key and moves it to another partition, held cursors, or a unique constraint problem found during commit processing.
• A query routed to an accelerator that the accelerator couldn't run, sometimes because of a logic error such as division by zero.

How to find the problem

1. Check the console and the ssnmMSTR job log in SDSF for resource-unavailable messages around the time of the error.
2. Look for an X'04E' abend and its reason code in the job log or SYSLOG. The reason code says which Db2 component failed.
3. For dynamic SQL, display the statement text and its length field just before the PREPARE.
4. For accelerated queries, read the accelerator-info token in the message.
5. On Db2 for i, look at the messages before SQL0901 in the job log with DSPJOBLOG. They usually name the real problem.

How to fix it

• Correct the statement length for dynamic SQL and run again.
• If a resource was unavailable, wait until it's available or have it started, then retry the work.
• For a failed distributed commit, check each server that doesn't support two-phase commit to see whether its changes were kept.
• For accelerator errors, fix any logic error in the query. If the query is fine, send the accelerator-info value to IBM Support.
• If the error repeats with no clear cause, collect the 04E dump, SYSLOG and the statement and open a case with IBM.

What it looks like

DSNT408I SQLCODE = -901, ERROR:  UNSUCCESSFUL EXECUTION CAUSED BY A SYSTEM ERROR THAT
         DOES NOT PRECLUDE THE SUCCESSFUL EXECUTION OF SUBSEQUENT SQL STATEMENTS
DSNT418I SQLSTATE   = 58004 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.