View Full Version : Datenbankverbindung *Local
Hallo *all,
ich hab da seit heute ein echt kniffliges Problem. Die IBM hat auch noch keine Lösung, aber die Fragen im Zweifel ja eh uns - Also Frage an die Profis:
Ich habe 2 Power6 mit V7R1 und gerade aktuellstem PTF-Stand.
Diese haben unsere Spiegelungssoftware und bis zum Einspielen des aktuellen PTFs war auch alles fein.
Um ein spezielles Problem des Kunden zu lösen haben wir mehrere Datenbank Connections auf die Backupmaschine definiert, die auf die gleiche Datenbank zeigen. D.h. wir haben eine Verbindung auf die ferne Datenbank mit einem beliebigen Namen gemacht und als RMT die entsprechende DB Angegeben. Weitere haben wir als Name n+1 angegeben und als fernen Standort die IP konfiguriert.
Seit heute geht nur noch eine Datenbankverbindung, diese muss auf beiden Seiten gleich heißen und MUSS den fernen Standort *local haben. Damit geht nur noch eine DDM Verbindung auf die zweite Maschine.
Weiß jemand, ob IBM das jetzt wirklich so will? Denn bisher gingen immer 1 zu n Verbindungen auf die ferne Datenbank mit unterschiedlichsten Namen!?
IBM ist jetzt wohl dran mit Rochester, aber ich hab da keine Hoffnung.
Was sagt ihr?
Dann hattet ihr ggf. vorher ein Konfigurationsproblem dass nun durch PTF's behoben ist.
Ich kann eine Datenbank (egal ob Remote oder Lokal) leider nur einmal definieren.
Eine "Alias"-Verwaltung finde ich nicht.
Wie konntet ihr also mehr als einen Namen für die RDB definieren?
Und warum musstet ihr das überhaupt tun?
Das ergibt für mich keinen Sinn.
... wie äußert sich euer Problem denn genau? Sprich: was habt ihr denn nun für Einträge und was macht ihr dann und was pasiert dann?
D*B
Hi Fuerchau,
warum wir das machen mussten kam aus der Historie der Spieglung. In der Spiegelung gibt es die Möglichkeit, eine Bibliothek über ein RMTJRN zu spiegeln. Nun gibt es aber Software, die eigene Journale hat und die es nicht erlaubt, dass eine Spiegelung das managen übernimmt.
Also haben wir uns über die RDBDIREs von der Produktiv mit den Namen AS400_1, AS400_2 usw. beholfen. Diese zeigten immer auf die IP der Backupmaschine und so konnte ich mehrere RMTJRNs per DDM auf die Backup verwalten und diese dann auch über den APLYJOB der Spiegelung laufen lassen. Jetzt meldet der Verbindungsjob, dass er die Datenbank AS400_2 etc. nicht findet.
Es ging in allen Releasen von V4R5 an. Seit Einspielen des aktuellen PTF bei V7R1 und EINEM Kunden geht es nicht mehr. Die Lösung haben wir bei mehreren Kunden im Einsatz und diese funktioniert auch.
Hi Dieter,
ich hab Fuerchau schon geantwortet warum wir das machen. Reicht dir diese Erklärung, oder brauchst du nähere Angaben .....
Was haben die RDBDIRE's mit der Spiegelung zu tun?
Ich verstehe auch immer noch nicht, warum man mehrere DB-Namen benötigt um auf ein Zielsystem zu connecten.
DDM geht einen anderen Weg und benötigt RDBDIRE's überhaupt nicht.
Also was macht ihr hier wirklich und warum ist das so kompliziert?
... also noch mal für die Landbevölkerung:
- ihr macht ADDRDBDIRE und legt (warum auch immer) für eine remote Datenbank mehrere Einträge, die auf dieselbe MAschine verweisen unter Angabe von *IP an
- dann braucht diese Maschine erst mal einen (in Worten: einen) *LOCAL Eintrag (sonst lässt sich der Dämon nicht starten (warum auch immer - maybe just to fool the russians)
- dann startet ihr jedenfalls auf dem Zielsystem den Database Server
- außerdem habt ihr da noch ADDRMTJRN Einträge, die auf ein RDBDIRE Einträge verweisen
- der Apply Job müsste doch jetzt auf dem remote System laufen, wozu braucht der dann überhaupt irgend eine Verbindung? der "liest" doch das für ihn lokale Journal und schreibt in die für ihn lokale DB?
D*B
So, spannend, aber die IBM hat tatsächlich ein "Sicherheitsleck", welches wohl schon mindestens 3 Versionen besteht geschlossen.
Es war bis heute wohl möglich, von Maschine A auf Maschine B eine Datenbankverbindung herzustellen, indem man die Datenbank mit beliebigen Namen auf die IP der Zielmaschine B hat verzweigen lassen, unerheblich, ob die Datenbank auf dieser Maschine so heißt, oder nicht.
Ab heute geht dies nur noch über den sog. Aliasnamen.
Klingt blöd, ist aber so .........
Wobei der Alliasname auch nur 1 mal verwendbar ist.
Aber trotzdem besteht hier noch Klärungsbedarf:
Warum müsst ihr von einer AS/400 zu einer anderen AS/400 deren DB über unterschiedliche Namen ansprechen?
Der Grund hierfür ist immer noch nicht klar.
... der ADDRDBDIRE braucht mehrere Angaben:
- den Namen der Datenbank auf dem Zielsystem (da können nämlich mehrere auf demselben System installiert sein unter MVS oder Wíndows oder Linux z. B.:), der muss natürlich stimmen, sonst geht das nicht.
- den Namen der Datenbank, wie sie beim connect heißen soll (da könnte nämlich auf verschiedenen Systemen Datenbanken sein, die gleich heißen), der muss natürlich eindeutig sein, sonst geht das wieder nicht.
- dann noch Angaben, wie zu erreichen (IP, SNA oder ARDPGM) und eventuell wo (IP Adresse)
Wenn das irgendwann man anders funktioniert hat, dann war da ein Bug im Remote System!!!
Mit mehreren Einträgen für dieselbe Datenbank hat das alles nix zu tun. Freilich kann man folgendes machen:
ADDRDBDIRE RDB(DDD DDD3) RMTLOCNAME(hugo *IP)
ADDRDBDIRE RDB(DDD DDD1) RMTLOCNAME(hugo *IP)
die beiden Einträge zeigen beide auf die Datenbank namens DDD auf dem System, das über den IP-Namen hugo erreichbar ist. Mache ich
CONNECT TO DDD3 USER MYUSER USING 'denkste'
dann kriege ich einen Connect an die Datenbank namens DDD auf hugo.
mache ich dann
CONNECT TO DDD1 USER MYUSER USING 'denkste'
dann habe ich einen zweiten connect an dieselbe Datenbank namens DDD auf hugo.
Damit kann ich z.B.:: innerhalb derselben ACTGRP zweimal an dieselbe Datenbank connecten. Daran ist nichts verwerfliches und das muss auch unter alle Releases gehen.
D*B
So, spannend, aber die IBM hat tatsächlich ein "Sicherheitsleck", welches wohl schon mindestens 3 Versionen besteht geschlossen.
Es war bis heute wohl möglich, von Maschine A auf Maschine B eine Datenbankverbindung herzustellen, indem man die Datenbank mit beliebigen Namen auf die IP der Zielmaschine B hat verzweigen lassen, unerheblich, ob die Datenbank auf dieser Maschine so heißt, oder nicht.
Ab heute geht dies nur noch über den sog. Aliasnamen.
Klingt blöd, ist aber so .........