WRKRDBDIRE MS Sql Server ansprechen

[Malte]

Hallo Zusammen,

Ich stehe grade vor der Aufgabe Daten von einem MS SQL-Server(im Netzwerk) in die AS400 zu übernehmen.

Also habe ich mir gedacht richte ich den doch einfach über WRKRDBDIRE ein.
So weit so gut wenn ich hier eine andere AS400 ein richt kann ich diese auch ansprechen, bei dem MS SQL Server klappt das leider nicht.

Zu den Daten:
V7R2
Relationale Datenbank . . . . . : MS_SQL
Ferner Standort:
Ferner Standort . . . . . . . : xxx.xxx.xxx.xxx
Art . . . . . . . . . . . . : *IP
Port-Nummer oder Servicename . : *DRDA
Ferne Authentifizierungsmethode:
Bevorzugte Methode . . . . . : *USRIDPWD
Einfachere Authentifiz. zul. : *NOALWLOWER
Sichere Verbindung . . . . . . : *NONE
Verschlüsselungsalgorithmus . : *DES
Text . . . . . . . . . . . . . . :


Art der relationalen Datenbank . : *REMOTE


select * from MS_SQL.dbo.Chart

Darauf bekomme ich diesen Fehler :
Nachrichten-ID . . . . : SQ30080 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Diagnose

Nachricht . . . : Übertragungsfehler während der Verarbeitung in der
verteilten Datenbank aufgetreten.
Ursache . . . . : Es ist ein Übertragungsfehler aufgetreten. Mögliche
Ursachen sind:
-- Das ferne System ist nicht verfügbar.
-- Das DFV-Netzwerk ist nicht verfügbar.
-- Die Benutzer-ID, die zum Starten der Verbindung verwendet wurde, ist
auf dem fernen System nicht vorhanden.
-- Für das ferne System ist unter Umständen die Verschlüsselung des
Kennworts erforderlich.
-- Das Kennwort ist möglicherweise für die Benutzer-ID nicht gültig. Die
Schreibweise des angegebenen Kennworts muss exakt mit dem Kennwort im fernen
System übereinstimmen.
-- Möglicherweise ist ein Server-Berechtigungseintrag für das ferne System
(falls verwendet) falsch. Server-Namen müssen in Großbuchstaben angegeben
werden. Der Systemwert QRETSVRSEC muss auf '1' gesetzt werden, um Kennwörter
beizubehalten.
Geht dieser Nachricht die Nachricht CPE3425 (Verbindung zurückgewiesen)
voran, sind folgende Ursachen möglich:
-- Der DDM/DRDA-TCP/IP-Server wurde auf dem fernen System nicht gestartet.
-- Für das ferne System wurde ein falscher Anschluss angegeben.
-- Für DRDA-Anschlüsse gelten auf dem fernen System Einschränkungen.
-- Der SOCKS-Server, falls verwendet, ist nicht korrekt konfiguriert.
Der übergeordnete APPC-Rückkehrcode lautet 00, der untergeordnete
Rückkehrcode 00. Bei TCP/IP lauten beide Rückkehrcodes 00. Lauten die
Rückkehrcodes nicht beide 00, kann ihre Bedeutung unter dem Thema "APPC
Programming" im Information Center unter
http://www.ibm.com/systems/i/infocenter/ gefunden werden.
Fehlerbeseitigung: Weitere Informationen enthalten die vorhergehenden
Nachrichten. Den Status des fernen Systems und das DFV-Netzwerk auf mögliche
Fehler prüfen. Handelt es sich bei dem Anwendungsserver um DB2 für IBM i,
die Nachrichtenwarteschlange QSYSOPR auf Fehlernachrichten prüfen.


Anpingen des Servers von der AS400 geht auch ohne Probleme.

Vieleicht habe ist es aber auch nur das Problem das ich nicht weiß wo ich Anmeldedaten mit gebe, obwohl ich auf dem Server auch schon einen Benutzer angeleght habe der meinem AS400 Benutzer entspricht und sysadmin und db_owner ist.



Danke schön schon Mal,
MfG Malte

[malzusrex]

Hier empfehle ich das Tool von Dieter
http://www.bender-dv.de/AppServer4RPG.html

Habe damit gute Erfahrung gemacht
Gruß Ronald

[BenderD]

... MS SQL Server kann kein DRDA, deshalb geht das nicht.
Es gibt da allerdings eine Bridge namens ArdGate und das ist sogar Open Source. Das kannst Du Dir von SourceForge runterladen und installieren.

D*B

PS: Wenn's schnell gehen soll, kann man sich das auch installieren und konfigurieren lassen. Mit Workshop zur Einführung bis zum ersten Programm braucht man dafür 2 Tage.

[Malte]

Danke für die Schnellen Antworten

Ich habe mir das grade mal runtergeladen und werde mir das mal morgen in Ruhe angucken.

[Fuerchau]

Du brauchst natürlich auch noch einen passenden JDBC-Treiber für deinen SQL-Server.
Da man sich nicht mit allem herumschlagen muss, habe ich mir da auch Dieters persönliche Hilfe gegönnt. Dies ist meist effektiver als sich selber damit rumzuschlagen.
Aber wenn es dann installiert ist und läuft, dann läufts und läufts und läufts...

[KM]

Was Deine Aufgabe betrifft, geht es natürlich am einfachsten mit einem kleinen Java-Programm. Für beide Datenbanken existieren ja entsprechende JDBC-Treiber. Hängt halt von Deiner genauen Anforderung ab.

Gruß,
KM

[BenderD]

Was Deine Aufgabe betrifft, geht es natürlich am einfachsten mit einem kleinen Java-Programm. Für beide Datenbanken existieren ja entsprechende JDBC-Treiber. Hängt halt von Deiner genauen Anforderung ab.

Gruß,
KM

... nur solange das nicht in vorhandene Anwendungen eingebunden werden muss.

[Fuerchau]

Und man natürlich auch Java kann.

[Malte]

Ich hab mir das und auch den JDBC Treiber mal angesehen und habe mir jetzt ein kleines Java Programm geschrieben welches mir die Daten vom Select als XML zurück gibt und eine 2. Funktion für Update und ähnliches hat.

Ich muss das Programm jetzt nur noch auf die AS400 übertragen und in ein RPG einbinden.

Wieso sollte es denn ein Problem geben dieses in die bestehende Anwendung einzubinden ?
Also bei mir würde das von einem Batchprogramm aus aufgerufen werden um Daten in einen MS-Sql-Server zu schreiben.

[BenderD]

... du kriegst halt miese Antwortzeiten beim ersten Aufruf des Java Teils, musst dich mit der JNI Implementierung von RPG rumärgern und wenn Du das aus mehreren Jobs aufrufst, skaliert das nicht (zur Freude von IBM).

D*B

[Fuerchau]

Weil durch das Einbinden von Java in RPG eine unglückliche Kombination verwendet wird. Es läuft zwar, aber du erstellst einen parallelen Java-Job (JVM), der dir über die Gesamtlaufzeit deines Jobs erhalten bleibt.
Zugegeben ist das jetzt nicht so das Problem. Bedenke aber, dass dies ja durchaus mehrfach in verschiedenen Jobs passieren kann. Machst du den Java-Aufruf auch noch über QSH erstellst du sogar 2 Zusatzjobs, da auch QSH in einem separaten Job läuft.
Bei Ardgate hast du das Problem nicht.
1. Du brauchst keine Java-Kenntnisse.
2. Du arbeitest mit embedded SQL.
Das verstehen dann ggf. auch andere.

[andreaspr@aon.at]

Wie D*B so schön zu sagen pflegt: da geht wieder alles drunter und drüber ...

Bei Ardgate steht auch nur ein Java PGM dahinter.
Der einzige Grund warum es die von Fuerchau und D*B beschriebenen Probleme gibt, ist einfach nur das Resultat einer falschen Implementierung mit Java.

Du kannst Java auf der IBM i genauso Performant und skalierbar einsetzen wenn du:
* Das Java in RPG in einem eigenen Job laufen lässt.
* Die Kommunikation (den Aufruf) via DataQ steuerst.
* Dadurch hast du mit der Skalierung keine Probleme, da du an die DataQ soviele Jobs anhängen kannst wie du halt benötigst.
Somit vermeidest du alle oben genannten Probleme.

lg Andreas