SQLCODE -30082: Connection failed for a security reason

What it means

When a client connects through DRDA, it sends a user ID and usually a password or other credential. The server checks them, on z/OS through RACF or another security product. If the check fails, the client gets -30082 with a reason code and a short reason string.

The codes you'll meet most are these.

• 1, PASSWORD EXPIRED. The password is correct but has expired.
• 2, PASSWORD INVALID. The password doesn't match.
• 3, PASSWORD MISSING. The request had no password.
• 4, PROTOCOL VIOLATION. The request didn't contain the right security information.
• 5 and 6, USER-ID MISSING or INVALID. No user ID was sent, or the server doesn't know it.
• 7, USER-ID REVOKED. The ID is revoked, often after too many bad passwords.
• 15, SECURITY FAILURE or PROCESSING FAILURE. Security processing failed at the server.
• 16, NEW PASSWORD INVALID. A password change didn't meet the server's rules.
• 17, UNSUPPORTED FUNCTION. The client asked for a security mechanism the server doesn't accept, such as an already verified user ID or an encryption option.
• 24, USERNAME AND/OR PASSWORD INVALID. The Db2 for LUW form for a bad user name or password.

Db2 for z/OS as a server writes a DSNL030I message with a Db2 reason code that gives more detail. Db2 for i reports SQ30082. Java programs using the IBM Data Server Driver for JDBC and SQLJ get ERRORCODE=-4214 with SQLSTATE 28000 instead.

Common causes

• The password was typed wrong, or a stored password in a data source, script or connection pool is out of date.
• The password expired on the server. Service IDs whose passwords follow the normal change interval hit this on a schedule.
• The user ID was revoked after repeated failed attempts, often by an application retrying with an old password.
• The client sends a security mechanism the server won't accept, such as an already verified user ID when the z/OS server's TCPALVER setting doesn't allow it (reason 17).
• On Db2 for LUW, the user name has the wrong case or format (reason 24).

How to find the problem

1. Read the reason code and reason string in the message. They narrow the cause to one of a few things.
2. On a Db2 for z/OS server, find the DSNL030I message on the console for the same time, and ask the security team for the matching RACF message for that user ID.
3. Check the user's status in the security product. Look for a revoked ID, an expired password or a disabled user.
4. For reason 17, compare the client's authentication setting with what the server accepts. On z/OS check TCPALVER, and the SECURITY_OUT column of SYSIBM.IPNAMES when z/OS is the requester.
5. Find every place the application stores this user's password, such as data sources, pool settings and scripts.

How to fix it

• Supply the correct user ID and password. Update stored passwords everywhere they're kept.
• For reason 1, change the password. A Db2 client can do it with CONNECT ... USER ... USING ... NEW ... CONFIRM.
• For reason 7, have the security team resume the ID, then fix whatever kept retrying with the old password.
• For reason 17, set the client to an authentication type the server supports, or have the server configured to accept it.
• For Db2 for z/OS as a requester, correct the outbound security settings in the communications database tables.

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.