[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2020
    Beiträge
    4

    Abbruch beim Zurückspeichern der QUSRBRM beim Wiederherstellen des Systems mit BRMS

    Hallo,

    als IBM i Neuling lese ich schon länger hier im Forum, habe nun in der Firma aber ein Problem für das mir keine weiteren Lösungsansätze mehr einfallen und hoffe, dass hier vielleicht noch jemand einen Ansätze wüsste.


    Wir versuchen mittels einer BRMS erstellen Offlinesicherung das kompletten System einer LPAR (IBM i 7.1) auf einer LPAR einer anderen Maschine (Power 520 Express - 8203-E4D) zu migrieren.

    Gemäß "BRMS Wiederherstellungsreport" und "IBM Sicherung und Wiederherstellungs 7.1" Dokumentation haben wir zunächst die LPAR auf der Zielmaschine mit einem IPL DM von der LIC 7.1 DVD gebootet, den LIC installiert und das IBM i OS wiederhergestellt.

    Bei Punkt 4 des BRMS Wiederherstellungsreport gelingt es uns die ersten vier Bibliotheken mittels RSTLIB zurück zu spielen, die letzte Bibliothek (QUSRBRMS) kann aber nie komplett zurückgespielt werden. Der Vorgang bricht immer bei ca der Hälfte ab, so dass nur die Hälfte der Objekte zurück gespielt werden. Im Joblog sieht man dass der Abbruch stets bei der Datei QA1ADI2 mit dem CPF3734 erfolgt (Objekte konnte nicht zurückgespeichert werden, da es während des Rückschreiben möglicherweise beschädigt wurde). Für alle nachfolgenden Datein wird dann der Fehler CPF3755 aufgeworfen.
    Auch ein RSTOBJ nur der QA1ADI2 war erfolglos.


    Wir haben schon den RSTLIB mit unterschieldichen Werten für ALWOBJDIF (*COMPATIBLE, *ALL) versucht, ohne Erfolg. Diese QUSRBRM Bibliothek konnten wir auf einer anderen Maschine und auch auf einer anderen LPAR der selben Maschine und mit derselben LIbrary allerdings einwandfrei wiederherstellen, so dass wir einen Defekt des Bandes oder der Library ausschliessen können.

    Hätte hier vielleicht noch jemsand einen Hinweis für uns, in welcher Richtung wir hier noch schauen könnten ?

    Danke und Gruß
    Andre

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    18.760
    Kannst du auf der Ursprungsmaschine den Typ des Objekts prüfen?
    Ggf. ist es ja nur ein Index (xxxI2), den du dann neu erstellen könntest.
    Somit kannst du das Objekt dann umgehen.
    Auch wenn ein Objekt ggf. auf eine andere Lib verweist und diese dann (noch) nicht da ist, scheitert der Restore.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Aug 2020
    Beiträge
    4
    Danke für die Rückmeldung.

    Wir haben stichprobenartig nachgeschaut: Die Objekte, die nicht wieder hergestellt werden können, sind jeweils physische Datein (wobei einige andere physische Datei wiederhergestellt werden). Wir können hier nicht erkennen was an diesen Dateien anders ist als an den anderen. Wir haben auch mal die entsprechende Datei aus dem RSTLIB mittel OMITOBJ herausgenommen, aber auch dann bricht das Wiederherstellen bei der nächsten Datei ab.

    Einige der Datein, die nicht wiederhergestellt werden könne, sind tatsächlich Indexdatein, die meisten aber nicht.

    Wir sind (schon allein aus Neugier) für weitere Hinweise dankbar. Aktuell haben wir die Vermutung dass unsere Tape-Library im Zusammenhang mit einem frischen 7.1 LIC und dem wiederhergstellten Betriebssystem irgendeinen Fehler aufweist. Wir haben auch tatsächlich ein PTF für 7.1 mit genau diesem Fehlerverhalten gefunden (RSTLIB bricht u.U. ab wenn SEQNBR angegeben wird) und den SEQNBR Parameter daraufhin mal weggelassen, auch ohne Erfolg.

    Als workaround werden wir nun als nächstes versuchen, LIC und IBM i 7.1 mitsamt Cum-PTF auf die neue LPAR zu installieren und dann nur die Einstellungen und Benutzerdaten der "alten" Maschine vom Band wiederherzustellen.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    18.760
    Wie sicher bist du denn, dass der SAVE funktioniert hat?
    Probier einfach mal ein Restore in eine andere Lib. Ggf. ist das bereits die Ursache.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    4.934
    ... ich tippe mal eher auf einen Bug in dem Brumms-Gelums.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Jul 2001
    Beiträge
    2.428
    Zitat Zitat von fedcba Beitrag anzeigen
    Wir versuchen mittels einer BRMS erstellen Offlinesicherung das kompletten System einer LPAR (IBM i 7.1) auf einer LPAR einer anderen Maschine (Power 520 Express - 8203-E4D) zu migrieren.
    Hallo Andre,

    nur um Dir das Leben zu vereinfachen: Welcher Spassvogel hat Dir diese Vorgehensweise empfohlen?

    GO SAVE,21 - und Restore 21 auf dem Ziel ist viel schmerzloser.
    www.RZKH.de -- wir bunkern Ihre IBM i - Daten!
    IBM i Community Advocate https://www.youracclaim.com/badges/6...c-7ad4ba147af6
    Common / CEAC
    Besuchen Sie http://ipublic.online - die öffentliche IBM i mit V7R4 für alle!

  7. #7
    Registriert seit
    Aug 2020
    Beiträge
    4
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Wie sicher bist du denn, dass der SAVE funktioniert hat?
    Probier einfach mal ein Restore in eine andere Lib. Ggf. ist das bereits die Ursache.
    Das war auch unsere Vermutung. Auf anderen LPARs konnten wir diese Library mittels RSTLIB aber ohne Probleme zurück spielen. Einer der Test war dabei sogar auf einer anderen LPAR auf der gleichen Maschine mit demselben Archivsystem erfolgreich, so dass wir auch einen Fehler im Archivsystem ausschliessen können.

  8. #8
    Registriert seit
    Aug 2020
    Beiträge
    4
    Zitat Zitat von holgerscherer Beitrag anzeigen
    Hallo Andre,

    nur um Dir das Leben zu vereinfachen: Welcher Spassvogel hat Dir diese Vorgehensweise empfohlen?

    GO SAVE,21 - und Restore 21 auf dem Ziel ist viel schmerzloser.
    Wir machen von der Quellmaschine regelmässig eine Offlinesicherung des gesamten Systems mittels BRMS und dachten, das es der beste Weg für eine Migration sein würde uns an den entsprechenden Wiederherstellungsreport von BRMS zu halten.

    Wir werden nun deinen Ansatz in den nächsten Tagen ausprobieren.

    Noch einmal Danke an Allen.

  9. #9
    Registriert seit
    Jul 2001
    Beiträge
    2.428
    Zitat Zitat von fedcba Beitrag anzeigen
    Wir machen von der Quellmaschine regelmässig eine Offlinesicherung des gesamten Systems mittels BRMS und dachten, das es der beste Weg für eine Migration sein würde uns an den entsprechenden Wiederherstellungsreport von BRMS zu halten.
    An sich ist das auch ein guter Weg - nur sehr fummelig, weil sich die BRMS-Routinen ins System einklinken. Daher ist die QUSRBRM notwendig, sonst weiss BRMS nicht, wo oben ist. Für eine reine Migration lieber den Weg des geringsten Widerstands gehen.

    Und nachher INZBRM nicht vergessen ;-)
    www.RZKH.de -- wir bunkern Ihre IBM i - Daten!
    IBM i Community Advocate https://www.youracclaim.com/badges/6...c-7ad4ba147af6
    Common / CEAC
    Besuchen Sie http://ipublic.online - die öffentliche IBM i mit V7R4 für alle!

Ähnliche Themen

  1. SQL-Fehler beim CAST
    Von Flappes im Forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 24-07-17, 14:41
  2. PUT Befehl beim FTP mit Laufwerksbuchstaben
    Von Paul_Hofmann im Forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 23-10-15, 11:20
  3. Fehler beim GET im FTP
    Von malzusrex im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 23-04-03, 17:15
  4. Dringendes Anmeldeproblem beim APD
    Von hs im Forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 23-09-02, 14:51
  5. Probleme beim Hochfahren !!!
    Von Markus im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 31-01-01, 13:51

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •