View Full Version : QjoRetrieveJournalEntries ... und wie weiter?
ebschubert
01-09-08, 12:46
Hallo Kollegen :)
Habe das Problem, eine eigene HA-Lösung zu bauen.
Bin jetzt bei QjoRetrieveJournalEntries
angekommen und kan auch die Einträge lesen.
ABER:
Wie bekomme ich jetzt mit diesen Einträgen meine BackUp-Daten auf der Zweitmaschine aktualisiert????
Nur per APYJRNCHG????
Oder gibt es auch einen anderen - programmtechnischen - Weg?
Wie verkette ich das Ganze, so dass automatisch das Update ausgelöst wird, sobald neue Einträge im RemoteJournal kommen?
Für Hinweise und Tipps wäre ich sehr dankbar
Viele Grüße
Andreas
... so einfach ist das nicht, mit RCVJRNE kannst du ein Exit Programm an ein Journal hängen, das automatisch aufgerufen wird, sobald ein Eintrag geschrieben wird. Wenn du das auf einem remote Journal machst, dann hast du die Informationen bereits auf dem Backup System. Den Apply Job musst du selber schreiben und die Fortschreibungen per insert, delete update vornehmen.
Ich würde die Finger davon lassen, das funktioniert schon bei den käuflichen HA Lösungen mehr schlecht als recht, und auf Hardware Alternativen setzen.
D*B
Hallo Kollegen :)
Habe das Problem, eine eigene HA-Lösung zu bauen.
Bin jetzt bei QjoRetrieveJournalEntries
angekommen und kan auch die Einträge lesen.
ABER:
Wie bekomme ich jetzt mit diesen Einträgen meine BackUp-Daten auf der Zweitmaschine aktualisiert????
Nur per APYJRNCHG????
Oder gibt es auch einen anderen - programmtechnischen - Weg?
Wie verkette ich das Ganze, so dass automatisch das Update ausgelöst wird, sobald neue Einträge im RemoteJournal kommen?
Für Hinweise und Tipps wäre ich sehr dankbar
Viele Grüße
Andreas
ebschubert
01-09-08, 14:29
... so einfach ist das nicht, mit RCVJRNE kannst du ein Exit Programm an ein Journal hängen, das automatisch aufgerufen wird, sobald ein Eintrag geschrieben wird. Wenn du das auf einem remote Journal machst, dann hast du die Informationen bereits auf dem Backup System. Den Apply Job musst du selber schreiben und die Fortschreibungen per insert, delete update vornehmen........
D*B
Hallo und Dankeschön :)
.... aber genau das ist meine Aufgabe!!!!
Und ich brauche wenigstens einen Tipp oder ein Gerüst wie das Programm für insert, delete update etc. aussehen sollte.
Viele Grüße
Andreas
... zu /38er Zeiten gab es da mal ein Redbook von so ca. 200 Seiten zu, das aber schon seit Jahren nicht mehr zu bekommen sein dürfte, aber die Grundidee ist wohl immer noch gültig.
Im Journaleintrag stehen die Daten als Image drin (analog zumn Trigger Buffer), da du die Key Felder brauchst, landest du letztlich beim generieren von Dateizugriffsprogrammen (als einfachere Variante), pro Datei eins. Ein Kollege von mir, ein absoluter Crack (F*Z weiß wer gemeint ist), hat sich daran vor langer Zeit mal etliche Monate versucht und hat die Ziele nur fast erreicht; ich habe das dann geerbt und war froh als das Projekt erfolgreich abgebrochen wurde.
Wenn dir jetzt schon die Luft knapp wird, dann lass die Finger davon, da kommt nämlich noch auf dich zu:
- Änderung von Dateien
- desynchronisation von Dateien
- Verbindungsprobleme
- Lock Konflikte
- hinterherhinkende Apply Jobs
- Perfromance und Durchsatz Probleme
D*B
Hallo und Dankeschön :)
.... aber genau das ist meine Aufgabe!!!!
Und ich brauche wenigstens einen Tipp oder ein Gerüst wie das Programm für insert, delete update etc. aussehen sollte.
Viele Grüße
Andreas
ebschubert
01-09-08, 15:19
... zu /38er Zeiten gab es da mal ein Redbook von so ca. 200 Seiten zu, das aber schon seit Jahren nicht mehr zu bekommen sein dürfte, aber die Grundidee ist wohl immer noch gültig.
D*B
Hallo D*B
Hab da was ganz brauchbares für den Einstieg gefunden:
Retrieve Journal Entry Exit Program | System iNetwork (http://systeminetwork.com/node/61262)
Vielleicht hilft das ja erst einmal weiter ....
Grüße
Andreas
also... mal abgesehen davon, das ich Dieter weitestgehend recht gebe ...
Wir haben soetwas schon einmal realisiert (erfolgreich) !
Allerdings arbeiten wir schon seit Jahren mit Datenzugriffsprogrammen. Die fallen aus einem selber geschriebenen Generator. Damit war der 'apply'-Prozess nicht sonderlich aufregend.
ABER: Wir haben diese Programme je Datei sowieso.
Du kannst dir auch mit sqlda ne eierlegende Wollmilchsau bauen. Das ist aber extrem Langsam.
Wenn du weitere Infos Brauchst, solltest du mir eine PM schreiben.
Wie gesagt... es geht(praxiserpropt) aber heute ist in den meißten Fällen eine Hardwarelösung besser. In unserem Fall währe das nicht gegangen, daher die SW variante
Robert
holgerscherer
02-09-08, 03:07
Ich würde die Finger davon lassen, das funktioniert schon bei den käuflichen HA Lösungen mehr schlecht als recht, und auf Hardware Alternativen setzen.
Es gibt auch Software-Lösungen, die wirklich gut funktionieren. Und die sind inzwischen so günstig, dass ich zu faul wäre, da das Rad neu zu erfinden.
Ich habe hier auch Routinen zur Spiegelung von Bibliotheken via Journal, aber das ist ja noch lange nicht alles, wenn man wirklich HA braucht. Dann kommen ja noch die Systemobjekte dazu, Konfigurationen, und irgendwann hat man mal den Fall, dass man auf die andere Maschine wechseln muss, möglichst halb-automatisch.
Da kann es nicht schaden, wenn man auf getestete und bewährte Routinen zurückgreifen kann.
Oder andersrum: wer hat den schwarzen Peter, wenns mal nicht klappt?
-h
.. das sagt jeder von seiner Software und was bei meinem Auto dann kaputt geht, sind elektronische Bauteile, die nicht mal halb so lang funktionieren, wie die mechanischen Teile vorher funktioniert haben.
Das Problem mit der HA Software ist m.E.: je höher (und näher an der Applikation) man hiermit ansetzt, umso komplexer und anfälliger gegen die unterschiedlichsten Probleme (Durchsatz etc.) wird das. Was auf der Ebene Bit und Platte noch vergleichsweise überschaubar ist, bläst sich auf der Ebene Table und Record schon um einiges auf und der Faktor was an den Applikationen gemacht werden m ü s s t e, um sie erst mal Transaktions stabil zu machen, das fällt dann sowieso unter den Tisch.
Die meisten HA Lösungen auf der Basis von Journalen wirken in erster Linie politisch (und deshalb muss man sowas auch kaufen). Und zuguterletzt sollte man schon mal darüber nachdenken, warum es solche Systeme ausschließlich auf AS/400 gibt...
D*B
Es gibt auch Software-Lösungen, die wirklich gut funktionieren.