A fix is available
APAR status
Closed as program error.
Error description
DB2DDF DB2DSHR DB2TCPIP Defects pm81671 dpm81671 165822 d165822 165992 d165992 ABEND=0C9-00000009 AT LOC=DSNLDTML.DSNLEDDA+345A AFTER APAR PM43293 APPLIED AND ONLY WHEN ZPARM CONDBAT SET TO 0 *************************************************************** Additional Symptoms and Keywords: ABEND0C9 AB0C9 S00C9 0C9 0C9-00000009 00000009 RC00000009 DSNLEDDA DSNLEDDA+345A 345A OFFSET345A SYSPCDB CONDBAT value of zero 0 DSNL031I MSGDSNL031I 00D351FF RC00D351FF DSNLZRPA DSNLZRPA0001 DSNL413I MSGDSNL413I DSNV408I MSGDSNV408I RESET YES DSNV460I MSGDSNV460I V460 AGNPRMRM SQLCODE -1224 SQLCODE1224 SQL1224N SQL01224N is detected by remote client environments, and the SQL statement fails to be seamlessly rerouted, after the DB2 server detects a DSNL027I 00D3003E or 00D3003F condition. The application must explicitly reconnect to the DB2 server where this was not necessary prior to the PM43293 change. The condition occurs because PM43293 caused an AGNPRMRM to be incorrectly returned when the 00D3003E or 00D3003F conditions are detected. 00D3003E RC00D3003E 00D3003F RC00D3003F
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All Distributed Data Facility (DDF) users. * * Specifically where: * * * DB2 is a member of a data sharing group * * and is configured with a MAX REMOTE * * CONNECTED (DSN6SYSP CONDBAT) value of 0, * * and/or * * * DB2 is utilized as a server, via a * * TCP/IP connection, on behalf of a * * remote DB2 for z/OS requester. * * * DB2 is a member of a data sharing group * * and is accessed by remote client * * environments which utilize the * * KeepDynamic Refresh capability * * (introduced by DB2 9 APAR PK69339). * * DB2 10 for z/OS users only. * **************************************************************** * PROBLEM DESCRIPTION: After PTF UK90325 (APAR PM43293) is * * applied, the following conditions may * * be observed: * * * Abend 0C9-00000009 DSNLEDDA+345A. * * * A DRDA AGNPRMRM reply is returned * * to remote DB2 for z/OS requester * * systems. * * DB2 for z/OS requester system * * symptoms may include: * * . Message DSNL031I displayed * * instead of DSNL511I. * * . An application may receive SQLCODE * * -30020 instead of SQLCODE -30081. * * . Message DSNL413I, which may result * * in message DSNV460I (V460) being * * issued in the -DISPLAY THREAD(*) * * TYPE(INDOUBT) command report. * * * Distributed client applications * * may receive SQLCODE -1224 errors. * **************************************************************** * RECOMMENDATION: * **************************************************************** As part of the new support introduced by PTF UK90325 (APAR PM43293), the following problems may be observed: * If DDF has been started when the subsystem is a member of a data sharing group, DDF will periodically notify z/OS Work Load Manager (WLM) of a change in the subsystem's health value as the number of remote client connections approaches the value specified for the MAX REMOTE CONNECTED (DSN6SYS CONDBAT) subsystem parameter. DDF can be started with a set of subsystem parameters or a different set of subsystem parameters can be loaded (online changed) where the value of CONDBAT is 0. When CONDBAT is 0, remote clients cannot connect to this DB2 subsystem because the DDF server capability is disabled. However, the new (APAR PM43293) DB2 system health notification capability did not consider the condition where CONDBAT is 0 which results in a divide by 0 exception (abend 0C9-00000009). * DB2 for z/OS requesters do not expect a DRDA AGNPRMRM (Agent Permanent Error reply message) to be returned from a DB2 for z/OS server when the server agent abnormally terminates. Thus, once PTF UK90324 is applied to a DB2 for z/OS server, a server agent abend condition will be reported as a DRDA AGNPRMRM (Agent Permanent Error) reply message rather than a connection failure. When a DB2 for z/OS requester sees this condition, it will issue message DSNL031I (REASON=00D351FF, ERROR ID=DSNLZRPA0001) instead of message DSNL511I, and return SQLCODE -30020 instead of SQLCODE -30081 to an application. Additionally, if the server agent abend is detected during commit processing, the DB2 for z/OS requester may also issue message DSNL413I in conjunction with message DSNL031I. This will result in the -DISPLAY THREAD INDOUBT command reporting a thread requiring manual intervention (RESET=YES and message DSNV460I) to resolve. * Distributed applications using the IBM Data Server Driver or Client product family that have been configured to utilize the KeepDynamic Refresh capability (introduced by DB2 9 APAR PK69339) do not expect a DRDA AGNPRMRM to be returned from a DB2 for z/OS server when the server has determined that the thread/connection should be refreshed. As such, the client application may now receive a SQLCODE -1224.
Problem conclusion
DB2 has been changed as follows: * DB2 will now ensure that the MAX REMOTE CONNECTED (DSN6SYSP CONDBAT) subsystem parameter is not 0 before determining whether or not WLM must be notified of a change in the subsystem's health. If CONDBAT is 0, no notification of the subsystem's health will be made to WLM because no remote client work can be accepted by the member. This means that the WLMHEALTH value displayed in message DSNL094I, issued as a result of the -DISPLAY DDF DETAIL command, will be 0. The subsystem health value will still be reported by message DSNV507I, which is issued for the ACTIVE MONITOR as a result of the -DISPLAY THREAD(*) TYPE(SYSTEM) command. * DB2 will no longer return an AGNPRMRM to a DB2 for z/OS requester. That is, relative to remote DB2 for z/OS requester systems only, DB2 server AGNPRMRM reply behavior introduced by APAR PM43293 has been restored to prior behavior. Users should be aware that if symptoms are observed on DB2 for z/OS requester systems, the solution is to apply this change to the associated DB2 10 for z/OS server system. * DB2 will no longer return an AGNPRMRM to a distributed client being terminated for KeepDynamic Refresh purposes.
Temporary fix
Comments
APAR Information
APAR number
PM81671
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
A10
Status
CLOSED PER
PE
YesPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2013-01-29
Closed date
2013-04-05
Last modified date
2013-07-31
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK93177
Modules/Macros
DSNLAGNT DSNLAGNX DSNLCTRC DSNLDALB DSNLEDDA
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
RA10 PSY UK93177
UP13/04/20 P F304
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
31 July 2013