korrupte Remotejournalreceiver

[stef2]

Hallo,

wir haben ein eigenes kleines Backup-System, wo u.a. auf einem Target-System abgehängte Journal-Receiver von einem Remote-Journal gesichert werden. Das sichern erfolgt immer sehr zeitnah nach Abhängen des Receivers. Zu einem Zeitpunkt wo im Source-System auf den journalisierten Files einige "Insert"und "Update" -intensive Batch-Prozesse laufen und das System stark ausgelastet ist, enstehen auf dem Target-System Receiver mit korrupten Journal-Einträgen (bei DSPJRN kommt MCH3203, Funktionsfehler 1716). Wenn der gleiche abgehängte Journal-Receiver mit korrupten Einträgen zu einem späteren Zeitpunkt nochmals gesichert wird, sind alle Journaleinträge korrekt. Es sieht so aus als wäre die Replik der Receiver noch nicht abgeschlossen wenn gesichert wird. Vor der Sicherung eines Journalreceivers erfolgt folgendes auf der Source:
- abhängen des aktuellen Receivers mit CHGJRN JRNRCV(*GEN)
- Löschen des aktuellen Receivers mit DLTJRNRCV DLTOPT(*IGNINQMSG)
(...hier kommt eine Abbruchnachricht, wenn der Receiver nicht komplett repliziert ist)
Dann wird auf Empfehlung der schnellen Hilfe von IBM noch auf dem Target 1 min gewartet und anschliessend der Receiver gesichert.
Wir haben schon jede Menge PTFs von IBM eingespielt. OS ist 520 mit TL04244.
Gibt es eine Möglichkeit den Replikationsstatus eines Remotejournal-Receivers zu ermitteln?
Hat jemand eine Idee ob am Ablauf etwas falsch ist?
Danke für jeden Tip.Stefan

[Fuerchau]

Journalreceiver können nie korrekt gesichert werden solange noch Commit's offen sind.
Offene Transaktionen werden auch nach einem CHGJRN noch in dem vorherigen JRNRCV fortgeschrieben (daher schlägt das Löschen fehl).
Ich kenne im Moment keine Funktion (WRKOBJLCK ? ggf. auch per API) die mir mitteilt, ob der JRNRCV noch verwendet wird.
Ein Sicherung/Replizierung sollte also erst erfolgen, wenn der JRNRCV nicht mehr verwendet wird.

[stef2]

Danke für die Antwort. Es wird auf dem Source in einem Loop der DLTJRNRCV + MONMSG versucht den Receiver zu löschen. Es kommt dann mehrmals CPF705F (nicht vollständig repliziert). Erst wenn das Delete funktioniert, läuft der Sicherungsprozess auf dem Target (inkl. 1 Min DLYJOB). Der Receiver kann jetzt auf dem Source nicht mehr in Verwendung sein, weil er gelöscht ist. Lt. IBM ist der Receiver komplett repliziert wenn er auf dem Source löschbar ist. Das Source-Journal ist *TYPE1 und es sollte mit dem Remotereceiver ein DSPJRN möglich sein (SAVOBJ auf Target + RSTOBJ auf Source) - das funktioniert nicht. Aber der Ansatz ist gut, man könnte auf dem Target mit WRKOBJLCK auf den Remotereceiver prüfen, ob das OS noch Prozesse am laufen hat. Sobald ich es getestet habe meld ich mich. Gruß Stefan

[stef2]

habe eine Log-Funktion eingebaut, die mit API "QjoRtvReceiverInformation" den Receiver_Status auf Target direkt vor Sicherung ermittelt. Der Status ist immer "2" (detached). Das SAVOBJ erfolgt mit SAVACT(*NO), es kann eigentlich auch der Remote-Receiver nicht mehr in Verwendung sein. Da gesicherte Receiver normalerweise immer komplett lesbar sein solten, deutet die Nachricht MCH3203 eher auf einen Bug im Journaling hin. Ist jetzt zur Analyse bei IBM.

Kennt jemand einen workaround um abgehängte Remote-Journalreceiver zeitnah zu sichern?