Meine Kollegen versuchen, BizTalk 2006 R2 über den DB2/MVS-Adapter mit einer Datenbank zu verbinden, die auf einem z/OS-Mainframe gehostet wird. Wenn die Verbindungseinstellungen zu testen, sie die folgende Fehlermeldung erhaltenBizTalk DB2-Adapter-Verbindungsfehler
Could not connect to data source 'New Data Source':
The network connection was terminated because the host failed to send any data.
SQLSTATE: 08S01, SQLCODE: -605
Wenn setzen Sie die Einstellungen in einer regulären Verbindungszeichenfolge und die Öffnung mit .NET-Code, das ist in Ordnung. Ich bin neu in BizTalk und DB2. Kann jemand vorschlagen, worauf man achten sollte, wenn dieser Fehler auftaucht?
24 8. August:
Nun, wenn normaler .NET-Code mit einer normalen DB2-Verbindungszeichenfolge verwendet wird, kann die Verbindung hergestellt werden und Anfragen vorgelegt. Was dieser DB2-Adapter meldet, ist, dass er nicht einmal einen richtigen Verbindungs-Handshake erstellen kann, ganz zu schweigen von dem Senden von Abfragen. Ich bin nicht sicher, was die eigentlichen Mechanismen sind, um eine DB2-Verbindung zu ermöglichen.
25 08 Aug:
Nach this MSDN forums posting, es scheint ein Login Thema.
Ich habe das gesehen und das ist hier nicht der Fall. Wenn wir den Benutzernamen als Paket-Sammlung angeben, trifft es immer noch auf dasselbe Problem.
26 08 Aug:
Aufgrund der spärlichen Informationen in Bezug auf Mainframe DB2-Datenbanken von Microsoft-Produkten verbindet, übernahm ich die Aufgabe rohe Netzwerkpakete zum Prüfen einen Anhaltspunkt zu bekommen, was zwischen dem vorgeht. Die Verbindung des NET-DB2-Anbieters (die funktioniert) und der DB2-Adapter von BizTalk 2006 (der bombardiert). Ich habe beobachtet, dass der DB2-Datenverkehr mit dem DRDA-Protokoll erfolgt. Und schloß schließlich die BizTalk Adapter Methode fehlschlägt von da was in dem Antwort des Servers SECCHKRM Paket aufgezeichnet ist
DRDA (Security Check)
DDM (SECCHKRM)
Length: 55
Magic: 0xd0
Format: 0x02
0... = Reserved: Not set
.0.. = Chained: Not set
..0. = Continue: Not set
...0 = Same correlation: Not set
DSS type: RPYDSS (2)
CorrelId: 0
Length2: 49
Code point: SECCHKRM (0x1219)
Parameter (Severity Code)
Length: 6
Code point: SVRCOD (0x1149)
Data (ASCII):
Data (EBCDIC):
Parameter (Security Check Code)
Length: 5
Code point: SECCHKCD (0x11a4)
Data (ASCII):
Data (EBCDIC):
Parameter (Server Diagnostic Information)
Length: 34
Code point: SRVDGN (0x1153)
Data (ASCII): \304\331\304\[email protected]\301\[email protected]\301\344\343\310\305\325\343\311\303\301\343\311\326\[email protected]\206\201\211\223\205\204
Data (EBCDIC): DRDA AR: AUTHENTICATION failed
Warum die gleichen Anmeldeinformationen hier ausfallen, während in dem .NET-Provider Erfolg ist mir schleierhaft. Was ich jetzt beobachten kann, ist ein deutlicher Unterschied zwischen den einzelnen Methoden, wenn es um die Reihenfolge der übertragenen Pakete geht.
.NET DB2 Provider
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP kpop > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1
2 0.000399 [DB2 server IP] [client IP] TCP 50000 > kpop [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.000414 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1 Ack=1 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
4 0.000532 [client IP] [DB2 server IP] DRDA EXCSAT | ACCSEC
5 0.038162 [DB2 server IP] [client IP] DRDA EXCSATRD | ACCSECRD
6 0.041829 [client IP] [DB2 server IP] DRDA ACCSEC | SECCHK | ACCRDB
7 0.083626 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=108 Ack=542 Win=65535 Len=0
8 0.190534 [DB2 server IP] [client IP] DRDA ACCSECRD | SECCHKRM | ACCRDBRM | SQLCARD
9 0.199776 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
10 0.293307 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
11 0.293359 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
12 0.293377 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=1444 Win=64092 [TCP CHECKSUM INCORRECT] Len=0
13 0.293404 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
14 0.293452 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
15 0.293461 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=2516 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
16 0.293855 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
17 0.293908 [DB2 server IP] [client IP] DRDA SQLDARD
18 0.293918 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=3588 Win=64464 [TCP CHECKSUM INCORRECT] Len=0
19 0.293957 [DB2 server IP] [client IP] DRDA QRYDSC
20 0.294008 [DB2 server IP] [client IP] DRDA QRYDTA
21 0.294017 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=4660 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
22 0.294023 [DB2 server IP] [client IP] DRDA SQLCARD
23 0.295346 [client IP] [DB2 server IP] DRDA RDBCMM
24 0.297868 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
25 0.421392 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
26 0.456504 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
27 0.456756 [client IP] [DB2 server IP] DRDA RDBCMM
28 0.488311 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
29 0.498806 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
30 0.630477 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=5157 Ack=1579 Win=65171 Len=0
31 0.788165 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA
32 0.788203 [DB2 server IP] [client IP] DRDA ENDQRYRM
33 0.788225 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1579 Ack=5815 Win=64380 [TCP CHECKSUM INCORRECT] Len=0
34 0.788648 [client IP] [DB2 server IP] DRDA RDBCMM
35 0.795951 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
36 0.807365 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
37 0.838046 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
38 0.838328 [client IP] [DB2 server IP] DRDA RDBCMM
39 0.841866 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
40 0.973506 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1906 Ack=6304 Win=65482 [TCP CHECKSUM INCORRECT] Len=0
BizTalk DB2-Adapter
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP 28165 > 50000 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2 0.002587 [DB2 server IP] [client IP] TCP 50000 > 28165 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.010146 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0
4 0.019698 [client IP] [DB2 server IP] DRDA EXCSAT
5 0.020849 [DB2 server IP] [client IP] DRDA EXCSATRD
6 0.034699 [client IP] [DB2 server IP] DRDA ACCSEC
7 0.036584 [DB2 server IP] [client IP] DRDA ACCSECRD
8 0.042031 [client IP] [DB2 server IP] DRDA SECCHK
9 0.046350 [DB2 server IP] [client IP] DRDA SECCHKRM
10 0.046642 [DB2 server IP] [client IP] TCP 50000 > 28165 [FIN, ACK] Seq=160 Ack=200 Win=65336 Len=0
11 0.053787 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=200 Ack=161 Win=65536 Len=0
12 0.056891 [client IP] [DB2 server IP] DRDA ACCRDB
13 0.058084 [DB2 server IP] [client IP] TCP 50000 > 28165 [RST, ACK] Seq=161 Ack=295 Win=0 Len=0
Es ist interessant, die .NET-Provider Problem aus verschiedenen DRDA-Protokoll-Pakete innerhalb in einem einzigen TCP-Segment zu bezeugen. Der BizTalk-Adapter legt andererseits nur ein Protokollpaket pro TCP-Segment ab. Ich weiß nicht, warum das so ist. Allerdings denke ich im Moment, dass dies ein Ablenkungsmanöver ist und der wahre Unterschied, der den Fehler bei der Authentifizierung verursacht, ist der DRDA-Datenaustausch. Ich kenne das DRDA-Protokoll nicht, also muss ich es studieren, bevor ich mehr Sinn darin finde.
18 8. September:
In diesem Stadium ist das Problem noch nicht gelöst, wie die Zusammenarbeit von dem DB2 DBA-Team bekommen und Hilfe von Microsoft wurde mit vielen Hindernissen begegnet.
Was ich berichten möchte, ist, ich habe vielleicht einen entscheidenden Unterschied zwischen all den Fällen der erfolgreichen Verbindung im Vergleich zu dem gescheiterten Versuch beobachtet:
Der BizTalk DB2-Adapter zugrundeliegend verwendet Microsoft ODBC-Treiber für DB2. Die anderen erfolgreich ausgeführten Softwaretests verwenden IBM DB2 ODBC DRIVER oder IBM DB2 ODBC DRIVER - IBMCL1. Die Parameterkonfiguration des IBM-Treibers unterscheidet sich von Microsofts Treiber. Wir sehen jedoch keinen offensichtlich kritischen Unterschied, der zu einer fehlgeschlagenen Authentifizierung für den Microsoft-Treiber führen könnte.