web-dev-qa-db-ja.com

IBMのiSeries ODBCドライバーは、isqlまたはその他の方法で呼び出されたときにトラフィックを送信せず、[08S01] [unixODBC]および[ISQL]エラーを取得します：SQLConnectできませんでした

注：IPアドレス、データベース名、サーバーユーザーを例に置き換えました。それは何にも影響を与えないはずです。

セットアップ

UnixODBC（yum install unixODBC）とIBMの公式iSeries ODBCドライバー（yum install ibm-iaccess-1.1.0.5-1.0.x86_64.rpm、IBMのログイン領域からダウンロードされたRPM）をインストールしました）。インストールにより、ドライバーが正常に追加されました。 to /etc/odbcinst.ini：

[IBM i Access ODBC Driver]
Description             = IBM i Access for Linux ODBC Driver
Driver          = /opt/ibm/iaccess/lib/libcwbodbc.so
Setup           = /opt/ibm/iaccess/lib/libcwbodbcs.so
Driver64                = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup64         = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading               = 0
DontDLClose             = 1
UsageCount              = 1

[IBM i Access ODBC Driver 64-bit]
Description             = IBM i Access for Linux 64-bit ODBC Driver
Driver          = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup           = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading               = 0
DontDLClose             = 1
UsageCount              = 1

参照されているライブラリファイルは存在し、正しくリンクされています（lddでチェックされ、リンクが欠落していません）。

私の~/.odbc.iniファイルは次のようになります。

[Foo]
Driver          = IBM i Access ODBC Driver
DATABASE        = FooDB
SYSTEM          = 123.45.67.8
HOSTNAME        = 123.45.67.8
PORT            = 446
PROTOCOL        = TCPIP

問題

isql Foo USER PASSWORD -vを実行すると、約1分後に次の出力が得られます。

[email protected] [~]# isql FooDB USER PASSWORD -v
[08S01][unixODBC]
[ISQL]ERROR: Could not SQLConnect

トラブルシューティング

タイムアウトしているようですね。

ping 123.45.67.8は以下を返します：

[email protected] [~]# ping 123.45.67.8
PING 123.45.67.8 (123.45.67.8) 56(84) bytes of data.
64 bytes from 123.45.67.8: icmp_seq=1 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=2 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=3 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=4 ttl=63 time=31.0 ms
64 bytes from 123.45.67.8: icmp_seq=5 ttl=63 time=29.9 ms

telnet 123.45.67.8 446は以下を返します：

[email protected] [~]# telnet 123.45.67.8 446
Trying 123.45.67.8...
Connected to 123.45.67.8.
Escape character is '^]'.
foobar
^]
telnet> quit
Connection closed.

/etc/odbcinst.iniでTraceおよびTraceFileを使用してODBCログを有効にすると、次のような出力が生成されます。

[ODBC][22093][1454628360.104274][__handles.c][450]
                Exit:[SQL_SUCCESS]
                        Environment = 0x13a4750
[ODBC][22093][1454628360.104316][SQLAllocHandle.c][364]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x13a4750
[ODBC][22093][1454628360.104339][SQLAllocHandle.c][482]
                Exit:[SQL_SUCCESS]
                        Output Handle = 0x13a5080
[ODBC][22093][1454628360.104363][SQLConnect.c][3614]
                Entry:
                        Connection = 0x13a5080
                        Server Name = [FooDB][length = 4 (SQL_NTS)]
                        User Name = [USER][length = 7 (SQL_NTS)]
                        Authentication = [*******][length = 7 (SQL_NTS)]
                UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

                DIAG [08S01]

[ODBC][22093][1454628423.118602][SQLConnect.c][3982]
                Exit:[SQL_ERROR]
[ODBC][22093][1454628423.118628][SQLError.c][430]
                Entry:
                        Connection = 0x13a5080
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118656][SQLError.c][467]
                Exit:[SQL_SUCCESS]
                        SQLState = 08S01
                        Native = 0x7fff9a5bd5a8 -> 10060
                        Message Text = [[unixODBC]]
[ODBC][22093][1454628423.118685][SQLError.c][430]
                Entry:
                        Connection = 0x13a5080
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118704][SQLError.c][467]
                Exit:[SQL_NO_DATA]
[ODBC][22093][1454628423.118722][SQLError.c][510]
                Entry:
                        Environment = 0x13a4750
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118739][SQLError.c][547]
                Exit:[SQL_NO_DATA]
[ODBC][22093][1454628423.118765][SQLFreeHandle.c][279]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x13a5080
[ODBC][22093][1454628423.118784][SQLFreeHandle.c][330]
                Exit:[SQL_SUCCESS]
[ODBC][22093][1454628423.118827][SQLFreeHandle.c][212]
                Entry:
                        Handle Type = 1
                        Input Handle = 0x13a4750

ハンドルの割り当てに成功した後、データベースへの接続を試み、汎用SQL_ERRORで失敗し、エラーで何かを実行しようとし（何がわからないのですか？）、ハンドルの割り当てを解除します。

私の最後の手段は、ネットワークトラフィックを直接チェックすることでした。 telnetを使用した最初のテストは次のとおりです。

[root@Host /opt/ibm/iaccess]# tshark -i tun0 -x
Running as user "root" and group "root". This could be dangerous.
Capturing on tun0
0.000000000   10.10.1.10 -> 123.45.67.8  TCP 60 42054 > ddm-rdb [SYN] Seq=0 Win=13660 Len=0 MSS=1366 SACK_PERM=1 TSval=1992917110 TSecr=0 WS=128

...PACKETS...

2.316931937   10.10.1.10 -> 123.45.67.8  TCP 60 42054 > ddm-rdb [PSH, ACK] Seq=1 Ack=1 Win=13696 Len=8 TSval=1992919427 TSecr=4147650000

0000  45 10 00 3c f1 b3 40 00 40 06 73 d2 0a 0a 01 0a   E..<..@[email protected].....
0010  ac 10 1e 02 a4 46 01 be e0 f5 71 c8 1d a8 3b 71   .....F....q...;q
0020  80 18 00 6b f5 9b 00 00 01 01 08 0a 76 c9 89 83   ...k........v...
0030  f7 38 1d d0 66 6f 6f 62 61 72 0d 0a               .8..foobar..

...PACKETS...

予想どおり、いくつかのTCPパケットがあり、そのうちの1つにはfoobarが含まれています。

さて、これがisqlでのテストです。

[root@Host /opt/ibm/iaccess]# tshark -i tun0 -x
Running as user "root" and group "root". This could be dangerous.
Capturing on tun0
^C0 packets captured

渋滞なし！？

正直なところ、私はここで少し立ち往生しています。次に何を試すべきかわからない。何がうまくいかないのか、またはこの困難な状況をトラブルシューティングする方法について何か考えはありますか？

サーバーのセットアップ自体は問題ないことに注意してください。 IBMのiSeries ODBC Windows用ドライバーを使用して、問題なく接続できます。

centos6ibmodbcdb2unixodbc
2
Agop

さて、ついにそれを理解しました。なんてばかげている。

まず第一に、新しいiAccessドライバーではなく、IBMの古いiSeriesドライバーの1つを手に入れてください。ログインしたら、_IBM Software > Downloads > No-charge products, tools, and toolkits_に移動し、odbcを検索します。 IBM i Access for Linux (V7R1)のようなドライバーが表示されるはずです。それらの1つをつかみます。

これらの古いドライバーを使用すると、適切なエラーメッセージが表示されます。

_[08S01][unixODBC][IBM][System i Access ODBC Driver]Communication link failure. comm rc=10060 - CWBCO1048 - A firewall blockage or time-out occurred trying to connect to the IBM i
_

いいね！少なくとも今では、問題が何らかの閉塞であると120％確実に確信できます。

しかし、何IS閉塞？IBMの驚くほどよく整理されたドキュメントの索引が救助に： http://www-01.ibm.com/support/docview.wss?uid = nas8N1012436

ここに再現された記事の表：

_PC Function                   Port (non-SSL) SSL Port
Server Mapper                 449            449
License Management (see Note) 8470           9470
RPC/DPC (Remote Command)      8475           9475
Sign-On Verification          8476           9476
Database Access               8471           9471
_

ポート_8471_（ "データベースアクセス"）のブロックを解除しました。すべてが機能し始めました！

2016年3月8日更新：何らかの理由で、WindowsはLinuxよりも多くのポートを開く必要があります。これをWindowsで機能させるには、_Server Mapper_ポートと_Sign-On Verification_ポートも必要でした。

ちなみに、この記事のもう1つの重要な段落は次のとおりです。

これらのポート番号（サーバーマッパー以外）は構成可能であり、デフォルトは上記にリストされていますが、システムの実際の値は異なる場合があります。ポートはサービステーブルから取得されます。問題のシステムでWRKSRVTBLEコマンドを使用してこれらのポートを判別し、ポートがデフォルト値から変更されているかどうかを判別してください。

0
Agop