SQLCODE -900: Not connected to a server

What it means

A Db2 application process always has a current connection or is in the unconnected state. It enters the unconnected state when something takes away its current connection and nothing replaces it. Db2 for z/OS names a previous failure as the cause, and adds that a failed request to switch the user on a trusted connection can do it too.

From there, any statement that needs a server fails with -900. That includes SELECT, INSERT, OPEN and the rest. CONNECT, COMMIT, ROLLBACK and SET statements that only touch local special registers still work.

-900 is a symptom. The real error came earlier, and the job log or the program's own error handling usually shows it. IBM notes that some programs check for -900 on purpose as a way to detect the unconnected state.

Db2 for LUW uses SQL0900N and Db2 for i uses SQL0900, both with SQLSTATE 08003. Db2 for i lists DISCONNECT, and RELEASE followed by a commit, as normal ways to get there.

Common causes

• A CONNECT failed, for example with -30081 or -30082, and the program carried on running SQL without checking the SQLCODE.
• The program released its connection and committed, then ran SQL without a new CONNECT or SET CONNECTION.
• A DISCONNECT ended the current connection.
• A request to switch the user on a trusted connection failed.
• The remote server or the network dropped the connection after an earlier error.

How to find the problem

1. Look earlier in the job log, the program's messages or the client log for the first failing SQLCODE. It explains why the connection went away.
2. Check the error handling after each CONNECT. A program that ignores a failed CONNECT reaches -900 on the next statement.
3. Search the program for RELEASE, DISCONNECT and COMMIT, and follow the path that runs between them and the failing statement.
4. For trusted connections, check the switch-user request and the security messages on the server.

How to fix it

• Fix the first error, such as a communication or security failure, then rerun.
• Test the SQLCODE after every CONNECT and stop or retry before running other SQL.
• After a RELEASE and COMMIT, issue CONNECT TO location or SET CONNECTION location before the next statement.
• If the program checks for -900 on purpose, make sure it reconnects in that branch.

What it looks like

DSNT408I SQLCODE = -900, ERROR:  THE SQL STATEMENT CANNOT BE EXECUTED BECAUSE THE
         APPLICATION PROCESS IS NOT CONNECTED TO A SERVER
DSNT418I SQLSTATE   = 08003 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.