Remote BIND error - OS/390 to UDB v8 (Linux)

[McRickFSU]

TCPIP return code - where can I look them up?
1128.76630291

DSN SYSTEM(DB2T)
BIND PACKAGE(UDBTEST.FSUDBA_BATCH)+
MEMBER(UDBCOB2) LIBRARY('FSUDB2.TEST.DBRM')+
OWNER(<valid owner>) QUALIFIER(<valid qual>)
SQLERROR(NOPACKAGE)+
VALIDATE(BIND) FLAG(I) ISOLATION(CS)+
CURRENTDATA(NO) DEGREE(ANY) RELEASE(DEALLOCATE)+
EXPLAIN(NO) NOREOPT(VARS) KEEPDYNAMIC(NO)+
DBPROTOCOL(DRDA)+
ACTION(REPLACE)
END
SQLCODE = -30081
SQLSTATE = 08001
SQLERRMT =
TCP/IP.SOCKETS.146.201.105.120.CONNECT.1128.76630291.0000.
SQLWARN 0= ,1= ,2= ,3= ,4= ,5= ,6= ,7= ,8= ,9= ,A=
DSNT233I -DB2T UNSUCCESSFUL BIND FOR
PACKAGE = UDBTEST.FSUDBA_BATCH.UDBCOB2.()

 

[MarcLodge]

McrickFSU,
An article here:

https://aurora.vcu.edu/db2help/db2h1/frame3.htm#db2h137

says that the most common errors for TCPIP are:

TCP/IP
1. Services file
2. Database manager configuration SVCENAME parameter
3. Environment variable DB2COMM set to include TCPIP. Make sure that db2start completes without any warning.

It also mentions that 'If the DRDA AR is DB2 for OS/390, make sure that the following fixes have been applied: APAR PQ05771/PTF UQ06843 and APAR PQ07537/PTF UQ09146.'

Don't know if this is gong to be any help to you,but it was worth a shot.

Marc

 

[MarcLodge]

Have you anymore error messages by the way, as I would have thought that you would receive some extra stuff with regards the SQL -30081 ? I would have expected an SQL30081N message somewhere, with all the diagnistic info that that gives, eg.:

SQL30081N A communication error has been detected. Communication protocol being used: <protocol>. Communication API being used: <interface>. Location where the error was detected: <location>. Communication function detecting the error: <function>. Protocol specific error code(s): <rc1>, <rc2>, <rc3>.


Explanation: An error has been detected by the communication subsystem.

If the connection has already been established, possible causes include the following:

A communication subsystem error at the client node or server node has caused the connection to go down.
A communication subsystem error at the SOCKS server, if one is being used, has caused the connection to go down.
A network error has caused the connection to go down.
The database agent at the server was forced off by the system administrator.
The database agent at the server was terminated due to an abnormal termination of a key database manager process.
If you are trying to establish a new connection, possible causes include the following:

The remote database server has not been cataloged correctly at the client.
The database manager configuration file at the server has not been configured with the proper communication parameters.
The communication subsystem at the client node or server node has not been configured correctly, or has not been started successfully.
The communication subsystem at the SOCKS server, if one is being used, has not been configured correctly, or has not been started successfully.
The DB2COMM environment variable at the server doesn't specify the communication protocol used by the client.
The database manager at the server has not been started, or has not been started successfully. One or more of the communication protocols specified by DB2COMM may not have been successfully started.
Refer to the token values for details. Depending on the protocol being used and the communication function invoked, some tokens may not be applicable. The following is the explanation of the token values:



<protocol>
The actual communication protocol being used. Valid token values are:
TCP/IP
APPC
NETBIOS
IPX/SPX

<interface>
The application programming interface used to invoke the above communication protocol services. Valid token values are:
SOCKETS
SOCKS
CPI-C
DLR or DD
TLI or Connection/Bindery

<location>
This is a protocol specific ID which uniquely identifies the node that detected the error. If the protocol being used is:
TCP/IP
The format of the ID is the Internet address in dot notation.

APPC
The format of the ID is the fully qualified LU name (networkID.LUname).

NETBIOS
The format of the ID is the Workstation name (nname).

IPX/SPX
The format of the ID is the network address and node address in hexadecimal notation (network.node).


If the location information is not available at the time that the error occurred, this token is not filled in.


<function>
The name of the communication subsystem function that returned the error code(s).

<rc1>, <rc2>, <rc3>
The list of the available error codes and subcodes that are specific to each protocol being used. Tokens that are not applicable contain "*".
If the protocol being used is:

TCP/IP

If present, <rc1> contains the global errno value from the TCP/IP sockets function call. When using Windows Sockets, if present, <rc1> contains the error from the TCP/IP sockets function call returned by WSAGetLastError().
If present, <rc2> contains the global h_errno value from the TCP/IP database function call. When using Windows Sockets, if present, <rc2> contains the error from the TCP/IP database function call returned by WSAGetLastError().
If <rc3> is present and contains "0", it means that the TCP/IP connection has been closed. This could be caused by one of the following:
The database agent at the server was forced off by the system administrator.
A database agent could not be started at the server because the maxagents database manager configuration parameter has been exceeded. Check the First Failure Service Log (DB2DIAG.LOG) at the server to see if an error message has been logged.
The database agent at the server was terminated due to an abnormal termination of a key database manager process.
Note: When using Windows Sockets, if the <function> is WSAStartup, and <rc1> is 0, then <rc2> contains the Windows Sockets Specification version level requested by DB2, and <rc3> contains the Windows Sockets Specification version level supported by the Windows Sockets DLL.

APPC
<rc1> contains the return code from the CPI-C function. If present, <rc2> contains the global errno value from the CPI-C function call. <rc3> is not applicable.

NETBIOS
<rc1> contains the return code from the call to NetBIOS. <rc2> and <rc3> are not applicable.

IPX/SPX
<rc1> contains the global t_errno value from the call to TLI Services, or the return code from the call to NetWare Connection or Bindery Services. If the <rc1> t_errno is TLOOK, <rc2> contains the TLI event that has occurred. If the <rc2> event is T_DISCONNECT, <rc3> contains the disconnect reason code. On AIX, if the <rc1> t_errno is TSYSERR, <rc3> contains the system errno (defined in sys/errno.h). If <rc1> contains the error return code from a call to AIX NetWare Connection or Bindery Services, <rc2> contains the error generator.

See the Communications Errors appendix of the Messages Reference for more information on specific communication error codes.

User Response:

If the connection has already been established, check if:

The database agent at the server has been forced off.
The database manager at the server has abnormally terminated.
A communication subsystem or network error has occurred. See the Messages Reference for more information on specific communication error codes.
If you are trying to establish a new connection, check if:

The remote database server is cataloged properly on the client node.
The database manager configuration file at the server is configured with the proper communication related parameters. If the database manager configuration parameters have been updated at the server, ensure that you stop and then re-start the database manager, for the changes to take effect.
The communication subsystems on both client and server nodes are configured and started up properly.
The DB2COMM environment variable at the server specifies the communication protocol used by the client.
The database manager at the server is successfully started. Start database manager processing at the server should have returned SQL1063, and not SQL5043. If SQL5043 is returned, check the First Failure Service Log (DB2DIAG.LOG) for more information.
A communication subsystem or network error has occurred.
If the problem persists, consult with your network administrator and/or communication expert to determine the cause of the problem using the set of tokens provided.

sqlcode: -30081

sqlstate: 08001

 

[McRickFSU]

Marclodge:
Thanks for your effort and interest. Yes, I did get SQL30081 per below:
SQLCODE = -30081 SQLSTATE = 08001
SQLERRMT =
TCP/IP.SOCKETS.146.201.105.120.CONNECT.1128.76630291.0000.
SQLWARN 0= ,1= ,2= ,3= ,4= ,5= ,6= ,7= ,8= ,9= ,A=
DSNT233I -DB2T UNSUCCESSFUL BIND FOR
PACKAGE = UDBTEST.FSUDBA_BATCH.UDBCOB2.()

This is the message that lead me to ask about TCP return codes.

Thanks for the link - I'll start checking those settings today. Multitasking - we are also installing and configuring DB2II today for Federated DB access.
Fun, Fun, Fun!