Eigenständigen Anwendungsserver unter dem Betriebssystem z/OS migrieren
Nachdem Sie die JCL-Jobs für die Migration eines eigenständigen Anwendungsserverknotens 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 BBOMBINS-Membern der CNTL-Datei erstellt, die zum Generieren der Jobs verwendet wurde. Folgen Sie diesen angepassten Anweisungen, um die Migration Ihres eigenständigen Anwendungsservers auf Version 9.0 abzuschließen.
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.
- Die Jobs BBOWMG1B, BBOWMG2B, BBOWMG3B, BBOWBPRO, BBOWBPRE und BBOWBPOS, auf die in diesen Anweisungen verwiesen
wird, müssen von einer WebSphere-Administrator-ID übergeben werden.
Alle anderen Jobs müssen von einer Benutzer-ID übergeben werden, die das Dateisystem steuert.
- Sie müssen sicherstellen, dass für den Namen des Profilausgangsverzeichnisses kein einzelnes alphabetisches Zeichen, gefolgt von einem Doppelpunkt, verwendet wird, z. B. a:. Der Migrationsjob interpretiert ein einzelnes alphabetisches Zeichen als "/", wodurch eine Endlosschleife in Gang gesetzt wird.
- Tipp: Verwenden Sie vor der Migration eines eigenständigen Anwendungsservers 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 Dateisystem für die neue Konfiguration vorhanden ist. Sie können den Job BBOMBHFS oder BBOMBZFS ausführen, um ein neues Konfigurationsdateisystem zu erstellen und anzuhängen. Das Dateisystem kann aber auch manuell angehängt werden. 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.
Der Job BBOMBHFS bzw. BBOMBZFS erstellt 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.
Stellen Sie sicher, dass die Dateien für das Konfigurationsdateisystem manuell oder über den Job BBOMBHFS bzw. BOMBZFS zugeordnet, erstellt und angehängt wurden, 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 BBOMBCP kopiert die generierten JCL-Prozeduren, damit die Server in der angegebenen Prozedurenbibliothek gestartet werden können. Die Konfiguration von Version 9.0 muss andere JCL-Prozeduren verwenden als diejenigen, die von der Konfiguration von 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 den Job BBOMBCP, und stellen Sie sicher, dass der Rückkehrcode 0 lautet.
- 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. Wenn Ihre JCL-Prozedur für den Controller der Version 7.0 oder höher beispielsweise den Namen AZACR hat und Sie für Version Version 9.0 AZ6ACR angegeben haben, müssen Sie ein Profil STARTED 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 AZ6ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
Anmerkung:- Verwenden Sie keine andere Benutzer-ID zum Starten. Es sind andere Elemente an die Benutzer-ID gebunden. Wenn Sie die Benutzer-ID ändern, müssen weitere Änderungen vorgenommen werden.
- 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.
- Übergeben Sie die Jobs BBOWMG1B und BBOWMG2B. Anmerkung: Wenn Sie keine XA-Connector verwenden, ist die Übergabe der Jobs BBOWMG1B und BBOWMG2B optional. Sie sollten jedoch beide Jobs übergeben, um sicherzustellen, dass Ihre Transaktionsprotokolle bereinigt werden.
Der Job BBOWMG1B bewirkt, dass alle Server auf dem zu migrierenden Anwendungsserverknoten im PRR-Verarbeitungsmodus (Peer Restart and Recovery) gestartet werden. Der PRR-Verarbeitungsmodus löst alle ausstehenden Transaktionen auf, löscht die Transaktionsprotokolle und stoppt den Server. Der Job BBOWMG2B inaktiviert den PRR-Modus und versetzt alle Server wieder in den normalen Betriebsmodus.
Führen Sie die folgenden Schritte aus, um die XA-Transaktionsprotokolle zu löschen:- Übergeben Sie den Job BBOWMG1B, und stellen Sie sicher, dass der Rückkehrcode 0 lautet.
- Starten Sie den Anwendungsserver erneut und warten Sie, bis er die PRR-Verarbeitung automatisch durchführt und gestoppt wird.
- Übergeben Sie den Job BBOWMG2B, und stellen Sie sicher, dass der Rückkehrcode 0 lautet.
- Stoppen Sie den Dämon und Anwendungsserver von Version 7.0 oder höher.
Der Dämon muss den höchsten Versionsstand aller Server haben, die er in derselben LPAR verwaltet. Beim Start des Servers hat er den Stand von Version 9.0.
sie müssen den Anwendungsserver von Version 7.0 oder höher stoppen, bevor Sie fortfahren.
- Löschen Sie den Protokolldatenstrom und definieren Sie ihn anschließend erneut.
Führen Sie diesen Schritt nur aus, wenn Sie zuvor das XA-Partnerprotokoll für Transaktionen oder das Kompensationsprotokoll im Server von Version 7.0 oder höher so konfiguriert haben, dass ein Protokolldatenstrom verwendet wird.
- Stellen Sie sicher, dass der Knoten gestoppt wurde.
- Löschen Sie den Protokolldatenstrom und definieren Sie ihn anschließend erneut.
Sie können die während der Anpassung von Version 7.0 oder höher erstellten Jobs BBOLOGSD und BBOLOGSA verwenden, wenn im Server die Verwendung des Protokolldatenstroms konfiguriert war.
Das folgende Beispiel zeigt einen solchen Job://RLSP1A JOB 'xxxx,yyy,?','USERID',MSGCLASS=H, // CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID //STEP1 EXEC PGM=IXCMIAPU //STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * DATA TYPE(LOGR) REPORT(YES) /* Standardeinstellung, damit Ausgabe des Jobs angezeigt wird */ DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D) DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D) LOWOFFLOAD(20) HIGHOFFLOAD(79) STG_DUPLEX(YES) DUPLEXMODE(UNCOND) STG_DATACLAS(OPERLOG) STG_SIZE(5000) HLQ(Q10RRS) LS_SIZE(5000) LS_DATACLAS(OPERLOG) STRUCTNAME(WAS_LOGRLS) /*
- Führen Sie eine der folgenden Aktionen aus:
- Übergeben Sie den Job BBOWMG3B.
BBOWMG3B ist der Job, der die physische Migration des Knotens der 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 den Job BBOWMG3B, vergewissern Sie sich, dass der Rückkehrcode 0 ist, und überprüfen Sie die Protokolldateien im temporären Migrationsverzeichnis im Dateisystem. Das temporäre Migrationsverzeichnis ist temporäre_Verzeichnisposition/nnnnn, 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 Generieren der Migrationsjobs generiert wurde.
- Übergeben Sie die folgenden drei Jobs:
- Übergeben Sie den Job BBOWBPRO.
Der Job BBOWBPRO erstellt das Ausgangs- und Standardprofil von WebSphere Application Server.
- Übergeben Sie den Job BBOWBPRE.
Der Job BBOWBPRE führt den upgradevorbereitenden Prozess für die Migration aus.
- Übergeben Sie den Job BBOWBPOS.
Der JOb BBOWBPOS führt lediglich die upgradenachbereitenden und Abschlussprozesse (Änderung der Dateiberechtigung) für die Migration aus.
- Übergeben Sie den Job BBOWBPRO.
- Übergeben Sie den Job BBOWMG3B.
- Starten Sie den neuen Anwendungsserverknoten.
Verwenden Sie die vorhandenen Befehle, die 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 eingegeben haben. Dieser Befehl startet den eingebundenen Anwendungsserver von Version 9.0. Warten Sie, bis die Initialisierung des Servers abgeschlossen ist.
Die folgende Nachricht wird in der Konsole und im Jobprotokoll von BBOS001 angezeigt:BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
- Vergewissern Sie sich für Compute Grid oder Feature Pack for Modern Batch, dass der Job-Scheduler ordnungsgemäß migriert wurde und
dass Sie Jobs den Servern zuteilen können, die Ihre Stapelanwendungen hosten.
Greifen Sie nach dem Neustart des Servers über einen Web-Browser auf die Job-Management-Konsole zu, um die Job-Scheduler-Migration zu überprüfen.
Gehen Sie wie folgt vor, um sicherzustellen, dass die Server, die Ihre Stapelanwendungen hosten, ordnungsgemäß funktionieren:- Vergewissern Sie sich, dass die Stapelanwendungen im migrierten Server gestartet sind. Durchsuchen Sie die Serverprotokolle nach Fehlern.
- Vergewissern Sie sich, dass Sie dem migrierten Server Stapeljobs zuteilen können. Übergeben Sie hierzu einen Job über den migrierten Job-Scheduler-Server. Sie können den Job über die Job-Management-Konsole, das WSGrid-Dienstprogramm, die EJB-Schnittstelle oder die Web-Service-Schnittstelle übergeben.
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_sas
Dateiname:tmig_z_sas.html