IBM Support

PTF Application Causes Message CPF3E06 in Source System Job Log

Troubleshooting


Problem

Application of PTFs may cause message CPF3E06 error in the AR / Source / Client job log and failed DDM connection attempts. This is also documented in APAR SE60642.

Symptom

After applying PTFs, a Client connection request (RDB name "RMTDB" is used in this example: STRSQL "CONNECT TO RMTDB") fails to connect with errors :

CPF3E06   Escape 40  04/07/15  11:53:24.696550  QCNSMCTL   QSYS   *STMT  QRWSARDB   QSYS   *STMT

           From module . . . . . . . . :   QCNSMCTL

           From procedure  . . . . . . :   QCNSMCTL

           Statement . . . . . . . . . :   3036

           To module . . . . . . . . . :   QRWSARDB

           To procedure  . . . . . . . :   CNNRMT

           Statement . . . . . . . . . :   11824

           Message . . . . :   Relational database RMTDB not found or
                               not available.

           
           Cause . . . . . :   The relational database (RDB) name
                               sent during connection processing
                               did not match the name of the
                               relational database identified by
                               the *LOCAL entry in the RDB
                               directory, nor did it match the RDB
                               name of any available auxiliary
                               storage pool (ASP) group that may
                               exist on the system.

           Recovery  . . . :   *N is the name of the *LOCAL
                               relational database. Send *N as the
                               relational database name during
                               connect processing or, if the
                               system has one or more ASP groups
                               configured, ensure that the name
                               sent matches the RDB name of an
                               ASP group that is available when
                               trying to connect.

Technical description . . .:   The relational database name sent
                               on the DDM Access relational database
                               (ACCRDB) command did not match the
                               name of an available database.  This
                               will result in SQLCODE -30061 and
                               SQLSTATE 08004 at the application
                               requester.


SQ30061   Diagnostic   30 04/07/15  11:53:24.696691  QSQCONN    QSYS   *STMT    QSQCONN     QSYS        *STMT

            From module . . . . . . . . :   QSQCONN

            From procedure  . . . . . . :   CLEANUP

            Statement . . . . . . . . . :   22519

            To module . . . . . . . . . :   QSQCONN

            To procedure  . . . . . . . :   CLEANUP

            Statement . . . . . . . . . :   22519

            Message . . . . :   Relational database RMTDB not found.

           
            Cause . . . . . :   Relational database RMTDB was either not
                               in the relational database directory or
                               defined at the remote location.
           Recovery  . . . :   Do one of the following:
                               -- Use the Add Relational Database

                                   Directory Entry
                                   (ADDRDBDIRE)command to add the
                                   relational database name to the
                                   relational database directory.
                               -- Change the relational database

                                   name to match the relational
                                   database directory entry.
                               -- Verify the relational database

                                   name is defined on the remote
                                   location.

Error message CPF9190 with return code 17 or 15 is also possible in the source/client-side job log.

A typical scenario is that a relational database directory entry exists on the Client by the name "RMTDB" and points to the IP name of the Server system. However, either there is no RDB entry on the Server system by that name OR the RDB entry on the Server by that name is not an ALIAS to the *LOCAL RDB name of the Server.

The Using the Relational Database directory section of the Distributed Database Programming topic in the Knowledge Center explains that the RDB name passed on the connection request must match a valid entry on the target machine:
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/ddp/rbal1rdbdir.htm

Some DDM/DRDA programs had been exploiting a defect where connectivity was allowed despite either a non-existent RDB name being passed on the connection request or the RDB entry on the Server by that name is not an ALIAS to the *LOCAL RDB name of the Server.

Cause

Applications exploiting a defect in RDB name access may fail after application of SI56042 and SI56081.

Resolving The Problem

Options to resolve are as follows:

1.

Remove the incorrect RDB entry on the Source system and replace it with a source-side alias where the RDB name matches the *LOCAL RDB name on the Target system and the RDB Alias name matches the previous entry which was removed. (This is the easiest fix as nothing else needs to be modified on either system.)
2.Create an RDB alias on the Target that points to the *LOCAL entry on the target. This option requires PTF for APAR SE61305 be applied. For example, on the AS/Target/Server:
===> ADDRDBDIRE RDB(ASLocalName ASAliasName) RMTLOCNAME(*LOOPBACK)
...replacing ASLocalName with the *LOCAL RDB name and replacing ASAliasName with whatever RDB name the AR/Source/Client system is attempting to connect with.
3.Change the name of the *LOCAL entry on the Target to match the name used to contact the Target (RMTDB, in this case). Note that this may break other connections that were defined using the correct RDB name.
4.Change the RDB name in the Source application or DDMF to match the name of the *LOCAL entry on the Target. Note that this requires updating or recreating objects that referred to the RDB name that is presently failing to work; they will all need to be modified to use the new, correct RDB name.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Document Information

Modified date:
18 December 2019

UID

nas8N1020951