By Huiya Zhang and Jim Pickel
In Db2 13 for z/OS, you can apply the PTF for APAR PH62137 to prevent flooding of z/OS console by overwhelming numbers of DSNL030I messages, which has become a significant pain-point for database administrators. This APAR introduces a new DSNL061I message to handle repeated authentication or authorization failures with ‘00F300xx’ reason codes.
Background
Managing database systems like Db2 for z/OS requires not only performance but also efficiency in error handling. A recurring challenge for system and database administrators is the overwhelming amount of DSNL030I error messages, particularly when dealing with repeated authentication or authorization failures. Such messages flood the z/OS console, making it difficult to track more critical system alerts and possibly leading to adverse system behaviors, like the Db2 MSTR address space termination.
When a remote application connects to a Db2 for z/OS server but fails due to authentication fails (such as invalid password, invalid RACF ID, revoked user ID etc.) or authorization fails (such as removed DSNR access from a user), Db2 generates the DSNL030I message with ‘00F300xx’ reason code. This message is accompanied by RACF's ICH408I message and other informational IRR series messages, all of which are sent to the z/OS console. In many cases, poorly implemented applications may continually attempt to reconnect using invalid credentials, leading to a flood of these frequent messages.
This flooding not only clogs up the z/OS console but also risks exhausting the Extended Common Service Area (ECSA) storage which may cause the Db2 MSTR address space to abnormally terminate.
Moreover, DSNL030I messages lack essential diagnostic information like the client IP address (in cases where Db2 Connect is used as a gateway to access Db2 for z/OS), or product identifier, which are essential for database and system administrators to troubleshoot effectively.
Solution
Instead of issuing DSNL030I, ICH408I, and IRR messages for every failed authentication, the system now consolidates these authentication errors into a new DSNL061I message at a minimal interval of 5 minutes for each unique combination of the reason code, IP address, user ID, and product identifier.
By issuing a single DSNL061I message instead of many DSNL030I messages, Db2 enables administrators to monitor authentication problems without risking message overload. Moreover, this change allows critical system messages to remain visible on the console, thus reducing the chances of important information being missed due to message flooding.
The DSNL061I message also provides more comprehensive details in the THREAD-INFO compared to the previous DSNL030I. It now includes critical client information like the user ID, security mechanism in use when EXTSEC system parameter is set to YES, product identifier, and both the client and gateway IP addresses (if available). Additionally, the DSNL061I message includes the number of times the failure occurred since the last issued message, allowing administrators to monitor the persistence of failed authentication attempts.
This additional data helps administrators identify problematic clients or misconfigurations without the need for excessive message output.
Vendor Impact
As a result of this change, database and system administrators will see fewer DSNL030I messages in the console, which could affect automated operations. It is advised to add automation for this new message DSNL061I. Db2 will continue issuing DSNL030I for other reason codes.
Conclusion
With the introduction of the DSNL061I message, Db2 for z/OS now has a more robust mechanism for handling authentication and authorization failures. This solution prevents console flooding, ensures critical diagnostics are maintained, and improves the overall stability of Db2 environments.
#Db2forz/OS
#Highlights-home