PDA

View Full Version : BRMS-GO-SAVE-21-Migration V7R2 auf V7R3 ohne BRMS



Mida
18-10-18, 13:24
Hallo AS400-Experten,
ich versuche eine Migration von V7R1 GO SAVE 21 unter BRMS erstellt auf ein anderes System mit V7R3 zu laden
mit dem u. a. von IBM veröfentlichten Verfahren ohne BRMS:

Restore the License Internal Code and the operating system
RSTLIB SAVLIB(QBRM QMSE QUSRBRM)
RSTUSRPRF
RSTCFG
RSTLIB SAVLIB(QSYS2 QGPL QUSRSYS)
RSTLIB SAVLIB(*ANY) OMITLIB(QMSE QBRM QUSRBRM QSYS2 QGPL QUSRSYS)
RSTDLO
RST DEV('QSYS.LIB/media device name.DEVD') OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT)) ENDOPT(*LEAVE)
RSTAUT

Kurz vor Ende des RSTLIB SAVLIB(*ANY) OMITLIB QMSE ... bei der 10.letzen Bibliothek im Alphabet steigt der Prozess aus mit MCH1668, Tap0x Systemobjekt
teilweise beschädigt. Das Tape-Device wurde ausgetauscht und mit anderem Resource-Namen betrieben, RSTLIB ab 10.letzter Bibliothek gestartet, der Fehler bleibt, die Tape-Unit lässt sich nur schwer abhängen.
Wegen MCH1668 wurde ein RCLSTG *DBXREF gestartet, Anschließend die Aktion komplett nochmal durchgeführt, der Fehler bleibt.

Hat einer der Experten-innen eine Tipp für mich?
Danke vorab und Gruß an die Gemeinde
Mida

Fuerchau
18-10-18, 14:24
Wie alt auch immer das Verfahren ist, aber:
RSTLIB SAVLIB(QSYS2 QGPL QUSRSYS)
solltest du auf jeden Fall sein lassen!
QGPL könnte noch egal sein, aber QSYS2 und QUSRSYS gibt auf jeden Fall jede Menge Folgefehler, da mittlerweile gerade für SQL in diesen Libs Dateien releaseabhängig drinstehen.
Für einen Releasewechsel empfielt sich auch eher selten einen Save21 zurückzuladen sondern eher per SAVUSRLIB zu sichern damit keine Systemlibs mit einfließen.

holgerscherer
19-10-18, 21:05
Hat einer der Experten-innen eine Tipp für mich?


Hallo Mida,
als Experte sollte man sich 3 Dinge beherzigen:
- im Joblog eine Stelle finden, an der das TAPxx zerstört wird. Vielleicht ist das Band defekt, wenns immer die gleiche Stelle ist
- und übrigens: bei einer geplanten Migration *niemals* mit einem BRMS-Band arbeiten ;-)
- im Zweifel vorher jemanden fragen.

-h

hel400
20-10-18, 16:27
Hallo Mida,
Du schreibst, dass Du nach dem "von IBM veröffentlichten Verfahren" vorgehst.
Das ist aber mit Sicherheit NICHT für die Migration auf win anderes System gedacht (sondern ausschließlich für die Wiederherstellung des Originalsystems).

Wie achon geschrieben, zerstörst Du Dir mit diesem Ablauf das V7R3 Release.
Weiters werden durch den RSTCFG die kompletten HW-Ressourcen quasi "zerstört", weil der Parameter "SRM(*NONE)" fehlt (es handelt sich ja um einen Restore auf ein ANDERES System) usw..usw..

Das klappt so ohnehin nicht.

Mida
21-10-18, 06:49
Hallo Fuerchau, Holger Scherer und hel400,

vielen Dank für Eure Antworten.
Ich werde an das Thema Migration mit BRMS Sicherung so nie wieder einen Gedanken verschwenden ;-)

Ps. *SRM(*NONE) habe ich mit eingesetzt, o. a. Ablauf ist nur der grobe Plan.

Gruß Mida

hel400
21-10-18, 09:59
Ps. *SRM(*NONE) habe ich mit eingesetzt, o. a. Ablauf ist nur der grobe Plan.


Ah ok, dann passt das ja.
Wie gesagt, QGPL un d QUSRSYS nicht einfach so restoren, wenn unterschiedliche Releases.
Mit diesen Cmds kannst Du aber eine Vielzahl von Einstellungen übertragen:
RTVSYSINF und UPDSYSINF
RTVTCPINF und UPDTCPINF

Mida
06-11-18, 19:45
Der Abruch beim nativen RSTLIB Savlib bei großen Bibliotheken war doch ein Treiber-Problem im neuen LTO-Tape-Drive. Wahrscheinlich auch noch im Zusammenhang mit Update auf den neuen LIC im SV-Prozessor und Resave F.
DIe Banane wird langsam gelber :-)
Gruß Mida