Zwischen 2 AS/400 FTP Datenübertragung

[csantner]

Hallo

habe mal eine Frage wir planen unsere alte AS400 V4R5 MOD 170 durch eine Neue zu ersetzen mit V5R1 die alte Maschine bleibt im Betrieb so das ohne größeren Ausfällen gearbeitet werden kann, nun kommen wir zu dem Punkt alle verfügbaren Daten Profile Programme per FTP zu übertragen hat jemand das schon mal gemacht bzw auf was muß besonders geachtet werden oder ist es sinnvoller das komplette System zu sichern über Datenträger oder kann die Sicherung auf die neue Maschine übertragen werden also direkt eingespielt werden bin leider nicht so tief in der AS400 involviert. Bin für alle Ratschläge und Anregungen dankbar.

MfG

csantner

[weidenhammer]

Hallo....

Ich habe das gerade vor 2 Wochen gemacht...
Aber mittels Band.
Das lief einwandfrei...

Bei Fragen, meld Dich einfach bei mir.

Gruss

Alexander May

[BenderD]

das Problem sind hier weniger die Daten, als die Einstellungen, Benutzerprofile und Berechtigungen, das ist durchaus nicht trivial und erfordert gründliche Vorbereitungen...

D*B

Hallo

habe mal eine Frage wir planen unsere alte AS400 V4R5 MOD 170 durch eine Neue zu ersetzen mit V5R1 die alte Maschine bleibt im Betrieb so das ohne größeren Ausfällen gearbeitet werden kann, nun kommen wir zu dem Punkt alle verfügbaren Daten Profile Programme per FTP zu übertragen hat jemand das schon mal gemacht bzw auf was muß besonders geachtet werden oder ist es sinnvoller das komplette System zu sichern über Datenträger oder kann die Sicherung auf die neue Maschine übertragen werden also direkt eingespielt werden bin leider nicht so tief in der AS400 involviert. Bin für alle Ratschläge und Anregungen dankbar.

MfG

csantner

[Fuerchau]

Insbesonders spezielle Berechtigungen wie *ALLOBJ o.ä. können NICHT übernommen werden sondern müssen hinterher wieder gesondert erteilt werden.

Mittels SAVSECDTA werden Profile und Berechtigungen gesichert.
Mittels RSTUSRPRF können die Profile zurückgeladen werden.
Anschließend müssen sämtliche Lib's und IFS-Objekte zurückgeladen werden.

Anschließend kann mittels RSTAUT die Objektberechtigung/-eignerschaft wiederhergestellt werden.

Zwar ist das Ganze per SAVF auch möglich aber ungleich aufwändiger.
Pro SAVF kann nur ein Sicherungsbefehl verwendet werden und beim SAVLIB nur eine Lib benannt werden.

Diese kann dann per FTP / SNDF (SNADS) / CPY (QFileSvr.400) oder Windowsfreigabe (Netserver) auf das andere System gebracht und dann wiederhergestellt werden.

Problematisch wird es mit abhängigen Dateien (LF's) über mehrere Lib's oder Journalen in anderen Lib's als der Datenlib.

Sicherer geht es immer über eine Bandsicherung, die alles enthält.

[csantner]

erstmal vielen Dank für die Unterstützung, werde das koomplette System auf Bänder Sichern und dann auf das neue System einspielen. Eine Frage wäre noch zu klären wie kann ich am besten Spoolfiles auf das neue System übertragen(Altes System wird erst abgeschalten wenn neues System einsatzbereit ist) Danke.

[BenderD]

ich würde dir da schon dringend die Lektüre des Backup and Recovery Guide empfehlen!!!
Die Spools sind da noch ein geringes Problem, die könnte man auch noch per Remote Outq, oder sndnetsplf rüber schaffen.

D*B

erstmal vielen Dank für die Unterstützung, werde das koomplette System auf Bänder Sichern und dann auf das neue System einspielen. Eine Frage wäre noch zu klären wie kann ich am besten Spoolfiles auf das neue System übertragen(Altes System wird erst abgeschalten wenn neues System einsatzbereit ist) Danke.

[Fuerchau]

Spools geht am einfachsten per SNDTCPSPLF.

Das Schwierigste ist eigentlich der Recovery auf dem Ziel.
Hier wird ggf. die QUSRSYS gerne zerstört, da es in vielen Systemdateien (in der QUSRSYS!) Änderungen von Release zu Release gibt.

Wichtig ist also, die QUSRSYS nie mit ALWOBJDIF(*ALL) zurückzuspeichern.

Dies heißt dann allerdings auch, dass einige Konfigurationsarbeiten (WRKDIRE's, TCP, Routing, usw.) manuelle nachgezogen werden müssen.

[csantner]

das hört sich ja recht kompliziert an habe aber alles soweit verstanden nur das mit der Qusrsys wenn ich bei der Sicherung accpth *yes angebe gibt es da auch probleme beim wiederherstellen?

[Fuerchau]

Wenn beim Wiederherstellen Lib's nicht vorhanden sind, gibts auch keine Probleme.

Die QUSRSYS wird aber mit dem OS installiert und enthält eine Menge Systemdateien.

Erstellt man nun Drucker-DEVD's werden die zugehörigen OUTQ's automatisch in der QUSRSYS erstellt.
Ausserdem stehen die WRKDIRE's sowie einige TCP-Einstellungen in der QUSRSYS.

Man könnte nun denken, dass durch Kopie der QUSRSYS von System A nach System B alles beim Alten ist.

Solange die Releases beider Maschinen identisch ist, klappt das ja auch.
Aber wehe, die sind unterschiedlich.

In einer der vielen Dateien stehen z.B. die verfübaren TCP-/Host-Dienste.
Wird beim Wiederherstellen ALWOBJDIF(*ALL) gewählt, sowie OPTION(*ALL) werden auch Systemdateien überschrieben.
Dies wird manchmal sogar fatal !
LF-Beziehungen stimmen nicht mehr, man hat alte Stände, neue Dienste fehlen usw.
Wenn man Glück hat, wird die QUSRSYS nocht mit *ERROR in den installierten Lizenzprogrammen angezeigt.
Aber selbst das Nachinstallieren der QUSRSYS klappt nicht immer, da dieses nur bestimmte Prüfungen durchführt und nur fehlende oder falsche Obejkte ersetzt.

Die Format-ID der TCP-Dienstdatei hat sich aber z.B. seit V5R1 nicht mehr geändert. Somit wird diese nicht neu installiert.

Desweiteren:
Bei ALWOBJDIF(*ALL) werden die alten Objekte umbenannt, abhängige LF's verweisen nun auf die umbenannten Objekte.
Je nach Release gibts aber schon mal neue LF's, die natürlich nicht rückgesichert werden können (sind ja bei der Sicherung nicht bekannt).
Somit kommt es zu dem Zustand, dass die "alten" LF's korrekt auf die "alte" PF zeigt, die neuen LF's aber leider auf die umbenannte, eigentlich "neue" PF.

Das System scheint zwar zu laufen, vieles funktioniert ja auch.
Aber irgendwann sehr viel später, z.B. beim verwenden neuer Dienste oder dem Aufruf von z.B. CHGNTPA stürzen diese Befehle ab oder können die Ursprungswerte nicht abrufen.

Dies ist bei einem Kunden von mir passiert !!!
Aussage von IBM:
- System platt machen
- neue Installation von Anfang an
- Wiederherstellen der Anwendungs-Lib's
- Wiederherstellen USRPRF's und RSTAUT
- Konfiguration ggf. an Hand von Scripten durchführen

Der kürzere Weg war dann:
- abgleich der QUSRSYS auf umbenannte Dateien
- "alte" Datei umbenennen und umbenannte wieder in Original
- Per CPYF teilweise die Config zurückkopieren

Der Aufwand betrug ca. 3 Tage im laufenden Betrieb.
Die Wiederherstellung laut IBM hätte Produktionsausfall bedeutet.

[Pikachu]

Nach dem Wechsel von V4R5 auf V5R1 den STROBJCVN nicht vergessen!

[Fuerchau]

Kann bereits beim RSTxxx angegeben werden.

[csantner]

Guten Morgen zusammen,

möchte mich nochmals für die schnelle Unterstützung bedanken werde all die genannten Ratschläge berücksichtigen und umsetzen; Danke.