Migration eines Deployment Manager unter z/OS
Nachdem Sie die JCL-Jobs für die Migration eines Deployment Manager auf WebSphere Application Server for z/OS Version 9.0 generiert haben, können Sie die eigentliche Migration durchführen, indem Sie diese Jobs ausführen. Mit dem Generieren der angepassten Migrationsjobs haben Sie auch angepasste Anweisungen für die Vorbereitung und Ausführung der Migrationsjobs in den BBOMDINS-Membern der CNTL-Datei erstellt, die zum Generieren der Jobs verwendet wurde. Folgen Sie diesen angepassten Anweisungen, um die Migration des Deployment-Manger auf Version 9.0 durchzuführen.
Vorbereitende Schritte

Dieser Artikel beschreibt die Migration von Profilkonfigurationen. Wenn Sie Ihre Anwendungen auf die aktuellste Version migrieren möchten, verwenden Sie WebSphere Application Server Migration Toolkit. Weitere Informationen finden Sie unter Migration Toolkit on WASdev.
sptcfg- Nähere Informationen hierzu finden Sie in den Artikeln Übersicht über Migration, Koexistenz und Interoperabilität und Hinweise zur Migration.
- Sie können die Verarbeitung nicht fortsetzen, wenn Sie keine JCL-Migrationsjobs generiert haben.
- Migrieren Sie den Deployment-Manager-Knoten immer zuerst.
- Prüfen Sie die erforderlichen Voraussetzungen für die Koexistenz für Ihr System.
- Der in diesen Anweisungen referenzierte Job BBOWMG3D muss unter Verwendung einer
WebSphere-Administrator-ID übergeben werden.
Alle anderen Jobs müssen von einer Benutzer-ID übergeben werden, die das Dateisystem steuert.
- Hinweis zur Gewährleistung der hohen Verfügbarkeit während der Migration von Version 7.0 oder höher auf Version 9.0:
Wenn Sie einen Deployment Manager von Version 7.0 oder höher auf Version 9.0 migrieren, werden alle Binärdateien der Anwendungen beim Neustart des Deployment Manager erneut implementiert. Als Ergebnis dieser Aktion werden alle Anwendungen im Systemkomplex vom Deployment Manager gestoppt und erneut gestartet. In einem Systemkomplex, der für Hochverfügbarkeit definiert ist, kann dies eine Betriebsunterbrechung verursachen, falls die Synchronisationseinstellungen nicht inaktiviert werden.
Damit die Hochverfügbarkeit während der Migration erhalten bleibt, inaktivieren Sie alle Synchronisationseinstellungen für alle Node Agents im Systemkomplex, bevor Sie den Deployment Manager erneut starten.- Öffnen Sie die Administrationskonsole.
- Klicken Sie auf Systemverwaltung > Node Agents.
- Klicken Sie für jeden Node Agent auf Name_des_Node-Agent-Servers > File Synchronization Service und aktivieren Sie alle Synchronisationsoperationen.
- Tipp: Verwenden Sie vor der Migration eines Deployment Manager von WebSphere Application Server Version 7.0 oder höher den Befehl backupConfig oder ein von Ihnen bevorzugtes Sicherungsdienstprogramm, um die vorhandene Konfiguration zu sichern, wenn Sie in der Lage sein möchten, die Konfiguration nach der Migration in ihrem vorherigen Zustand wiederherzustellen. Weitere Informationen finden Sie im Artikel Befehl "backupConfig". Notieren Sie unbedingt den genauen Namen und die Position der gesicherten Konfiguration.
Hilfe finden Sie im Artikel Fehlerbehebung bei der Migration.
Informationen zu diesem Vorgang

- WebSphere Extended Deployment Compute Grid oder Feature Pack for Modern Batch
- WebSphere Virtual Enterprise oder Intelligent Management
Vorgehensweise
- Erstellen Sie ein neues Konfigurationsdateisystem für Version 9.0 und hängen Sie dieses an.
Für die Durchführung der Migration setzt Version 9.0 voraus, dass ein Konfigurationsdateisystem für die neue Konfiguration vorhanden ist. Sie können ein neues Konfigurationsdateisystem entweder durch Ausführung von BBOMDHFS oder BBOMDZFS anhängen oder Sie können es manuell anhängen. In jedem Fall müssen Sie ein Dateisystem für die Konfiguration von Version 9.0 erstellen und anhängen, um mit der Migration fortfahren zu können. Dieses Konfigurationsdateisystem ist das Ziel der Migration und Ihr Konfigurationsdateisystem für Version 7.0 oder höher ist die Quelle.
BBOMDHFS und BBOMDZFS erstellen ein Mountpunktverzeichnis, ordnen das Dateisystem der Konfiguration zu und hängen das Dateisystem an dem Mountpunkt an, den Sie beim Generieren der Migrationsjobs angegeben haben.
Vergewissern Sie sich, dass Sie die Dateien des Konfigurationsdateisystems manuell oder mithilfe von BBOMDHFS oder BBOMDZFS angelegt, erstellt und angehängt haben, bevor Sie fortfahren. Eigner des Mountpunkts muss der WebSphere-Administrator sein, und der Mountpunkt muss mindestens die Berechtigungen 755 haben. Die neuen Dateisystemstrukturen sollten in BPXPARM eingefügt werden, sodass sie beim nächsten IPL angehängt werden.
- Kopieren Sie die generierten JCL-Prozeduren.
Das Migrationsdienstprogramm BBOMDCP kopiert die generierten JCL-Prozeduren, um die Server für die angegebene Prozedurenbibliothek zu starten. Die Konfiguration von Version 9.0 muss andere JCL-Prozeduren verwenden als diejenigen, die von der Konfiguration der Version 7.0 oder höher verwendet werden. Dieses Dienstprogramm aktualisiert die neue Konfiguration von Version 9.0, indem es die Namen in der ursprünglichen Konfiguration von Version 7.0 oder höher durch die neuen JCL-Namen ersetzt.
Vorsicht: Dieses Dienstprogramm kopiert die generierte JCL in Ihre Prozedurenbibliothek. Wenn Sie beim Generieren der Migrationsjobs dieselben Namen wie in der Konfiguration der Version 7.0 oder höher verwendet wurden, überschreibt dieses Dienstprogramm die vorhandenen Prozeduren. Falls Sie dieselben Namen verwenden, sollten Sie die vorhandenen Prozeduren von Version 7.0 oder höher vor Ausführung dieses Dienstprogramms sichern, falls Sie die neue Konfiguration später rückgängig machen müssen.Übergeben Sie das Dienstprogramm BBOMDCP und prüfen Sie, ob der Rückkehrcode 0 zurückgegeben wird.
- Wenn Sie neue Prozedurnamen angegeben haben, aktualisieren Sie Ihre RACF-Profile des Typs STARTED
für den Controller und Dämon. Das von den Controllerregionen verwendete Profil STARTED basiert auf dem Prozedurnamen und JOBNAME. Sie müssen sicherstellen, dass ein gültiges Profil STARTED vorhanden ist, sodass der gestarteten Task die richtige ID zugeordnet wird. Falls der Contoller-JCL-Prozedurname Ihre Deployment Manager von Version 7.0 oder höher AZDCR ist und Sie für Version 9.0 den Namen AZ1DCR festgelegt haben, müssen Sie ein STARTED-Profil für diesen neuen Prozedurnamen erstellen:
neuer Controller - dieselbe Identität in der Konfiguration des JCL-Namens der Version 7.0 oder höher | | RDEFINE STARTED AZ1DCR.* STDATA(USER(AZDCRU) GROUP(AZCFG) TRACE(YES))
Anmerkung:- Verwenden Sie keine andere Benutzer-ID zum Starten. An die Benutzer-ID sind weitere Angaben geknüpft, sodass bei einer Änderung der Benutzer-ID noch weitere Änderungen erforderlich wären.
- Wenn das ursprüngliche Profil STARTED ein generisches Profil war, z. B. STARTED AZ*.* ..., müssen Sie kein neues Profil STARTED erstellen.
- Die STARTED-Profile der Servantregion basieren auf JOBNAME und nicht auf dem Prozedurnamen. Es gibt also kein Problem mit dem Servant, wenn Sie einen anderen Prozedurnamen verwenden.
- Dämonprozesse und Node Agents sind Controller. Wenn Sie also andere Prozedurnamen für diese Controller verwenden, müssen Sie ein neues Profil STARTED erstellen.
- Führen Sie eine der folgenden Aktionen aus:
- Übergeben Sie den Job BBOWIVT.
Bei einer Deployment-Manager-Migration muss der PRR-Modus für den Knoten nicht wie bei Migrationen von eigenständigen Servern und eingebundenen Knoten aktiviert und anschließend wieder inaktiviert werden. Daher sind für die Migration eines Deployment Manager zwei Jobs weniger zu übergeben, und die physische Migration kann jetzt durchgeführt werden.
BBOWMG3D ist der Job, der die physische Migration des Deployment Manager von Version 7.0 oder höher auf Version 9.0 basierend auf den Informationen, die Sie beim Generieren der Migrationsjobs angegeben haben, durchführt. Übergeben Sie BBOWMG3D. Prüfen Sie, ob die Rückkehrcodes 0 zurückgegeben werden, und überprüfen Sie die Protokolldateien im temporären Migrationsverzeichnis des Konfigurationsdateisystems. Das temporäre Migrationsverzeichnis ist temporäre_Verzeichnisposition/nnnnn. Dabei ist temporäre_Verzeichnisposition das für die temporäre Verzeichnisposition angegebene Verzeichnis und nnnnn ist der numerische Wert, der bei der Generierung Ihrer Migrationsjobs für die Migrations-ID generiert wird. Die Standardeinstellung für das temporäre Verzeichnis ist /tmp/migrate.
- Übergeben Sie die folgenden drei Jobs:
- Übergeben Sie den Job BBOWDPRO.
BBOWDPRO erstellt das Ausgangs- und Standardprofil von WebSphere Application Server.
- Übergeben Sie den Job BBOWDPRE.
BBOWDPRE führt den upgradevorbereitenden Prozess für die Migration aus.
- Übergeben Sie den Job BBOWDPOS.
BBOWDPOS führt lediglich die upgradenachbereitenden und Abschlussprozesse (Änderung der Dateiberechtigung) für die Migration aus.
- Übergeben Sie den Job BBOWDPRO.
- Übergeben Sie den Job BBOWIVT.
- Prüfen Sie vor der Migration die Einstellungen der Tracesteuerung.
Bestimmte Konfigurationseinstellungen müssen manuell geändert werden, damit eine Migration auf WebSphere Application Server durchgeführt werden kann. Verwenden Sie wie folgt die Administrationskonsole, um die Liste der Umgebungsvariablen zu prüfen:
- Klicken Sie auf Umgebung > WebSphere-Variablen verwalten.
- Suchen Sie auf der Registerkarte "Konfiguration" nach der
Variablen ras_trace_outputlocation. Prüfen Sie die Einstellung dieser Variablen, falls vorhanden.
Ist ras_trace_outputlocation auf TRCFILE gesetzt, müssen Sie die DD-Anweisung TRCFILE manuell in die Startprozedur für die neue WebSphere Application Server-Version einfügen.
Fehler vermeiden: Diese manuelle Änderung der Startprozedur muss ausgeführt werden, bevor die neue WebSphere Application Server-Version und die zugehörigen Dämonprozesse gestartet werden. gotcha
- Beenden Sie die alten Anwendungsserver und Dämonprozesse.
Vergewissern Sie sich, dass alle Knoten in der LPAR des Deployment Manager in derselben Zelle heruntergefahren wurden.
- Aktualisieren Sie gegebenenfalls die JCL-Prozedur für den Dämon.
WebSphere Application Server for z/OS Version 9.0 erfordert, dass der Dämonprozess den höchsten Codestand aller Server hat, die in derselben LPAR verwaltet werden. Beim Start des Deployment Manager hat er den Stand von Version 9.0.
Nachdem Sie alle Knoten auf Version 9.0 migriert haben und bevor Sie die Bibliotheken der früheren Version vom System entfernen, müssen Sie die JCL-Prozedur des Dämonprozesses aktualisieren. Andernfalls schlägt der Start des Dämonprozesses fehl.
Anmerkung:- Wenn Sie eine Migration von Version 7.0 oder höher auf Version 9.0, durchführen, muss der Dämon eine STEPLIB haben, die die SBBOLD2- und SBBOLPA-Dateien der letzten Version enthält.
- Wenn eine Zelle mit Version 9.0 einen Server von Version 9.0 enthält, der mit einem Server von Version 7.0 oder höher in einer Zelle mit Version 7.0 oder höher auf demselben System wie die Zelle mit Version 9.0 kommuniziert, müssen Sie außerdem die SBBOLD2- und SBBOLPA-Dateien der Version 7.0 der STEPLIB des Dämons von Version 9.0 hinzufügen.
- Starten Sie den neuen Deployment Manager.
Verwenden Sie den vorhandenen Befehl, den Sie zum Starten eines Anwendungsservers von Version 7.0 oder höher verwenden würden, aber ersetzen Sie den Prozedurnamen RACF STARTED durch den Wert, den Sie beim Generieren der Migrationsjobs als Namen für die Controllerprozedur in der Deployment-Manager-Anzeige eingegeben haben. Dieser Befehl startet den Deployment Manager von Version 9.0. Warten Sie, bis die Initialisierung des Servers abgeschlossen ist.
Im Jobprotokoll von BBODMGR wird die folgende Nachricht in der Konsole angezeigt:BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
Nächste Schritte
- Alle Einträge im Dateisystem der Quellenkonfiguration
- Alle Einträge im Verzeichnis temporäre_Verzeichnisposition/nnnnn der Zielkonfiguration, wobei temporäre_Verzeichnisposition für das Verzeichnis steht, das als temporäre Verzeichnisposition angegeben wurde (standardmäßig /tmp/migrate), und nnnnn für den numerischen Wert steht, der als Migrationskennung beim Erstellen der Migrationsjobs generiert wurde.
- Datei bbomigrt2.sh


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_adm
Dateiname:tmig_z_adm.html