Zellen mit den Befehlszeilentools migrieren

Vorbereitende Schritte

Unterstützte Konfigurationen Unterstützte Konfigurationen:

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

Lesen Sie die Informationen zur Migrationsplanung auf der Webseite Knowledge Collection: Migration planning for WebSphere Application Server.

Tipp: Anstatt einzelne Parameter in Migrationsbefehlen anzugeben, können Sie den Parameter -properties Dateiname.properties angeben, um eine Eigenschaftendatei einzugeben. Weitere Informationen hierzu finden Sie im Artikel Migration mit Eigenschaften migrieren.

Dieses Szenario beschreibt die Migration von Zellen auf demselben Host. Wenn Sie Zellen auf einen anderen Host migrieren möchten, lesen Sie die Anweisungen unter Zellen mit dem Befehlszeilentool auf neue Hostmaschinen migrieren.

Informationen zu diesem Vorgang

Sie können die Befehlszeilentools für die Migration einer Zelle von einer Vorgängerversion von WebSphere Application Server auf Version 9.0 verwenden. Die Zellenkonfiguration setzt sich aus einem Deployment Manager mit einem oder mehreren Knoten, einem Web-Server und einem Anwendungsclient zusammen. Alle Ports werden in die neue Konfiguration migriert. In dieser Prozedur wird davon ausgegangen, dass die vorherige Konfiguration aktiv ist.

Fehler vermeiden Fehler vermeiden: Stellen Sie sicher, dass der Wert für die maximale Anzahl geöffneter Dateien 10000 oder höher ist. Wenn die Anzahl der geöffneten Dateien zu niedrig ist, kann dies zu einer Reihe von Migrationsfehlern führen. gotcha
Hinweis zur Umstellung Hinweis zur Umstellung: Die folgenden Produkte haben zuvor unterschiedliche Migrationstools erfordert, sie werden jetzt jedoch im Rahmen der Standardmigrationsprozeduren migriert.
  • WebSphere Extended Deployment Compute Grid oder Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise oder Intelligent Management
Weitere Informationen zu diesen Änderungen finden Sie unter Neuerungen für die Migration.trns

Vorgehensweise

  1. Sichern Sie den Deployment Manager und alle alten Knoten.

    Sollte während der Migration ein Fehler auftreten, speichern Sie die Konfiguration des Deployment Manager und der Knoten mit dem Befehl backupConfig in einer Datei, die Sie später für Wiederherstellungszwecke verwenden können. Weitere Informationen hierzu finden Sie im Artikel Befehl backupConfig.

    1. Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
    2. Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus, und speichern Sie die aktuelle Profilkonfiguration in einer Datei. Beispiel:
      /opt/WebSphereV70/profiles/v70dmgr01/bin/backupConfig.sh /mybackupdir/v70dmgr01backupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
    3. Wechseln Sie für jeden Knoten in der Konfiguration in das Verzeichnis Stammverzeichnis_des_Knotenprofils/bin.
    4. Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus, um die aktuelle Profilkonfiguration in einer Datei zu sichern. Beispiel:
      /opt/WebSphereV70/profiles/v70node01/bin/backupConfig.sh /mybackupdir/
      v70node01backupBeforeV90migration.zip -username myuser -password mypass -nostop
  2. Installieren Sie WebSphere Application Server Version 9.0 auf jeder Zielmaschine in einem neuen Verzeichnis.

    Weitere Informationen finden Sie in der Installationsdokumentation.

  3. Führen Sie den Befehl manageprofiles mit den entsprechenden Parametern aus, um das Deployment-Manager-Zielprofil zu erstellen.

    Das Deployment-Manager-Zielprofil ist ein neues Deployment-Manager-Profil, das als Ziel für die Migration verwendet wird.

    Fehler vermeiden Fehler vermeiden: Der Knotenname und der Zellenname des Profils von Version 9.0 muss mit dem Knotennamen und dem Zellennamen von Version 7.0 oder höher übereinstimmen. Wenn der Knotenname oder Zellenname des Deployment Manager von Version 9.0 nicht übereinstimmen, schlägt die Migration fehl.gotcha
    Beispiel:
    /opt/WebSphereV90/bin/manageprofiles.sh -create -profileName v70toV90dmgr01 
    -templatePath /opt/WebSphereV90/profileTemplates/management -serverType 
    DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName 
    -hostName mydmgrhost.company.com
  4. Speichern Sie die aktuelle Deployment-Manager-Konfiguration im Migrationssicherungsverzeichnis, indem Sie den Befehl WASPreUpgrade im Verzeichnis bin des neuen Deployment-Manager-Profils ausführen.

    Der Befehl WASPreUpgrade ändert die Konfiguration von Version 7.0 oder höher nicht. Weitere Informationen hierzu finden Sie im Artikel Befehl "WASPreUpgrade".

    Anmerkung: Wenn Sie eine Migration von Version 8.0 oder höher auf Version 9.0 durchführen und als Profil einen Deployment Manager verwenden, wird das Profil von Version 8.0 während der Ausführung des Befehls WASPreUpgrade gestoppt. Der Deployment Manager wird nur dann vor Ausführung von WASPreUpgrade gestartet, wenn Sie in der Befehlszeile -keepDmgrEnabled true festlegen oder wenn Sie die entsprechende Option im Migrationsassistenten angeben.
    1. Führen Sie den Befehl WASPreUpgrade aus. Beispiel:
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile 70dmgr01
    2. Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den Protokollen von WASPreUpgrade.

      Nach Ausführung des Befehls WASPreUpgrade suchen Sie in der Konsolenausgabe nach Nachrichten des Typs Failed with errors oder Completed with warnings. Anschließend überprüfen Sie die Protokolldateien WASPreUpgrade.altes_Profil.Zeitmarke.log und WASPreUpgrade.trace auf Warnungen und Fehler.

      Falls Fehler vorhanden sind, beheben Sie diese und führen Sie den Befehl WASPreUpgrade erneut aus. Prüfen Sie, ob sich die Warnungen auf Migrations- oder Laufzeitaktivitäten in Version 9.0 auswirken.

      Wurde der Befehl erfolgreich ausgeführt, ist es nicht erforderlich, in den Protokollen nach Fehlern oder Warnungen zu suchen.

  5. Führen Sie den Befehl WASPostUpgrade aus, um die frühere Deployment-Manager-Konfiguration wiederherzustellen, die Sie im Migrationssicherungsverzeichnis gespeichert haben.

    Wenn Sie die im folgenden Beispiel gezeigten Optionen verwenden, werden alle Ports migriert, der alte Deployment Manager wird beendet und inaktiviert und alle Anwendungen werden installiert.

    Weitere Informationen finden Sie unter Befehl "WASPostUpgrade".

    1. Führen Sie den Befehl WASPostUpgrade aus. Beispiel:
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90dmgr01 -profileName 
      v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE 
      -includeApps TRUE -keepDmgrEnabled FALSE 
      -username myuser -password mypass
      Beim Erstellen von Profilen gilt nur ein Profil als Standardprofil pro Installation.

      Die Standardprofile finden Sie in der Datei profileRegistry.xml im Verzeichnis WAS_HOME/properties. Die Quelle profileRegistry.xml wird als Teil des Befehls WASPreUpgrade in das Migrationssicherungsverzeichnis kopiert.

      Wenn Sie das alte Profil nach der Migration weiterhin verwenden möchten, geben Sie den Parameter -clone TRUE an. Wenn Sie für den Deployment Manager eine Klonmigration angeben, müssen Sie alle zugehörigen eingebundenen Knoten ebenfalls klonen. Durch Angabe einer Klonmigration wird -keepDmgrEnabled automatisch auf "true" gesetzt.

      Fehler vermeiden Fehler vermeiden: Bei Ausführung des Befehls WASPostUpgrade sollten die Parameter -oldProfile und -profileName immer angegeben werden.gotcha
    2. Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den Protokollen von WASPostUpgrade. Nach Ausführung des Befehls WASPostUpgrade suchen Sie in der Konsolenausgabe nach Nachrichten des Typs Failed with errors oder Completed with warnings. Anschließend überprüfen Sie die Protokolldateien Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zielprofilname.Zeitmarke.log und Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zielprofilname.trace auf Warnungen und Fehler. Falls Fehler vorhanden sind, beheben Sie diese und führen Sie den Befehl WASPostUpgrade erneut aus. Prüfen Sie, ob sich die Warnungen auf Migrations- oder Laufzeitaktivitäten in Version 9.0 auswirken.

      Wenn die Konfiguration ordnungsgemäß migriert wurde, aber keine Anwendungen installiert wurden, können Sie den Befehl WASMigrationAppInstaller ausführen, damit nur die Anwendungen installiert werden, die nicht migriert wurden. Weitere Informationen hierzu finden Sie im Artikel Befehl "WASMigrationAppInstaller".

      Wurde der Befehl erfolgreich ausgeführt, ist es nicht erforderlich, in den Protokollen nach Fehlern oder Warnungen zu suchen.

  6. Sichern Sie die Version 9.0-Deployment-Manager-Konfiguration in einer Datei, indem Sie den Befehl backupConfig für den Deployment Manager von Version 9.0 ausführen.
    Fehler vermeiden Fehler vermeiden: Dies ist ein wichtiger Schritt im Plan für die Zellenmigration. Im Fall von Knotenmigrationsfehlern können Sie die Zellenkonfiguration in dem Zustand wiederherstellen, den sie vor dem Auftreten des Fehlers hatte, Sie können Fehlerbehebungsmaßnahmen ergreifen und die Knotenmigration wiederholen.gotcha
    1. Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
    2. Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus. Beispiel:
      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh /mybackupdir/
      v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
  7. Starten Sie den Deployment Manager von Version 9.0.

    Stellen Sie sicher, dass die frühere Version des Deployment Manager nicht aktiv ist.

    1. Wechseln Sie in das Verzeichnis bin des neuen Deployment-Manager-Profils von Version 9.0.
    2. Führen Sie den Befehl startManager aus.
    3. Suchen Sie in der Datei SystemOut.log nach Warnungen und Fehlern, während der Deployment Manager aktiv ist.
      Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
    4. Durchsuchen Sie alle Node-Agent- und Anwendungsserverprotokolle des Knotens nach neuen Warnungen oder Fehlern. Wenn die automatische Synchronisation aktiviert ist, lassen Sie die Synchronisation des Knotens und den Neustart der Anwendungen zu, und prüfen Sie anschließend die Protokolle auf neue Warnungen oder Fehler.
  8. 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 der Vorgängerversion zuteilen können, die Ihre Stapelanwendungen hosten.

    Greifen Sie nach dem Neustart des Deployment Manager ü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 der Vorgängerversion, die Ihre Stapelanwendungen hosten, ordnungsgemäß funktionieren:
    1. Vergewissern Sie sich, dass die Stapelanwendungen im migrierten Server oder Cluster gestartet sind. Durchsuchen Sie die Server- bzw. Clusterprotokolle nach Fehlern.
    2. 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.
  9. Migrieren Sie Plug-ins für Web-Server.
    1. Stellen Sie sicher, dass der Deployment Manager von Version 9.0 aktiv ist.
    2. Führen Sie ein Upgrade der Version des Web-Server-Plug-ins durch, das in der Zelle verwendet wird.
    3. Sehen Sie sich die unterstützenden Informationen zu Typ und Version Ihres Web-Servers an.
  10. Migrieren Sie Anwendungsclientinstallationen.

    Migrieren Sie Clientressourcen auf Ressourcen von Version 9.0.

    1. Installieren Sie den Anwendungsclient der WebSphere Version 9.0.

      Weitere Informationen finden Sie in der Installationsdokumentation.

    2. Führen Sie den Befehl Version 9.0 WASPreUpgrade aus, um die Sicherheitseinstellungen des Anwendungsclients in einem Migrationssicherungsverzeichnis zu speichern. Beispiel:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup/v70clientToV90 /opt/AppClientV70
    3. Führen Sie den Befehl Version 9.0 WASPostUpgrade aus, um die Sicherheitseinstellungen des Anwendungsclients im neuen Version 9.0-Client wiederherzustellen. Beispiel:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup/v70clientToV90 
  11. Migrieren Sie Knoten.

    Verwenden Sie die Migrationstools, um die früheren Versionen der Knoten in der Konfiguration auf Version 9.0 zu migrieren. Führen Sie für jeden Knoten, der auf Version 9.0 migriert werden soll, die folgenden Schritte aus:

    Fehler vermeiden Fehler vermeiden: Sie müssen denselben Knotennamen, aber einen anderen temporären Zellennamen für alle Knoten verwenden, die Sie auf Version 9.0 migrieren. gotcha
    1. Stellen Sie sicher, dass der Deployment Manager von Version 9.0 aktiv ist.
    2. Erstellen Sie das Zielknotenprofil. Führen Sie den Befehl manageprofiles mit den entsprechenden Parametern aus, um ein neues verwaltetes Profil zu erstellen. Beispiel:
      /opt/WebSphereV90/manageprofiles.sh -create -profileName node1 
      -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. Führen Sie den Befehl WASPreUpgrade aus, um die aktuellen Knotenkonfigurationsdaten in einem Migrationssicherungsverzeichnis zu speichern. Wählen Sie ein neues Verzeichnis für die Sicherungsdateien aus. Beispiel:
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90node1 /opt/WebSphereV70 
      -oldProfile 70node1
    4. Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den Protokollen von WASPreUpgrade.

      Suchen Sie in der Konsolenausgabe des Befehls WASPreUpgrade nach Nachrichten des Typs Failed with errors oder Completed with warnings.

      Suchen Sie in den folgenden Protokollen nach Warnungen oder Fehlern:
      • Migrationssicherungsverzeichnis/logs/WASPreUpgrade.altes_Profil.Zeitmarke.log
      • Migrationssicherungsverzeichnis/logs/WASPreUpgrade.trace

      Wenn der Befehl WASPreUpgrade erfolgreich ausgeführt wurde, müssen Sie nicht nach Fehlern und Warnungen in den Protokollen suchen.

    5. Stoppen Sie den Node Agent. Wenn Knoten mit Version 7.0 oder höher während einer Migration auf Version 9.0 aktiv sind, müssen Sie den Node Agent auf dem Knoten, der migriert wird, stoppen. Wenn Sie den Node Agent nicht stoppen, können Fehler auftreten.
    6. Führen Sie den Befehl WASPostUpgrade aus, um die gesicherte Knotenkonfiguration im neuen verwalteten Profil von Version 9.0 wiederherzustellen. Beispiel:
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 
      -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -username myuser -password mypass
      Wenn Sie den Deployment Manager geklont haben, müssen Sie alle eingebundenen Knoten ebenfalls klonen. Geben Sie den Parameter -clone TRUE und den neuen Hostnamen und SOAP- bzw. RMI-Port des Deployment Manager an. Klonen Sie eingebundene Knoten nur, wenn der Deployment Manager ebenfalls geklont wurde.
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 
      -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
    7. Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den Protokollen von WASPostUpgrade.

      Suchen Sie in der Konsolenausgabe des Befehls WASPostUpgrade nach Nachrichten des Typs Failed with errors oder Completed with warnings.

      Suchen Sie in den folgenden Protokollen nach Warnungen oder Fehlern:
      • Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zielprofil.Zeitmarke.log
      • Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zielprofil.trace
      Anmerkung: Wenn die Ausführung des Befehls WASPostUpgrade fehlschlägt, müssen Sie den Deployment Manager von Version 9.0 aus der Datei "backupConfig" wiederherstellen. Wurde während der Verarbeitung von WASPostUpgrade der Befehl syncNode ausgeführt, erkennt der Deployment Manager, dass der Knoten migriert wurde. Der Knoten kann erst dann erneut migriert werden, wenn der Deployment Manager in dem Zustand vor der Migration des Knotens wiederhergestellt wurde.

      Wenn die Konfiguration ordnungsgemäß migriert wurde, aber keine Anwendungen installiert wurden, können Sie den Befehl WASMigrationAppInstaller ausführen, damit nur die Anwendungen installiert werden, die nicht migriert wurden. Weitere Informationen hierzu finden Sie im Artikel Befehl "WASMigrationAppInstaller".

      Wenn der Befehl erfolgreich ausgeführt wurde, müssen Sie nicht nach Fehlern und Warnungen in den Protokollen suchen.

    8. Suchen Sie in der Datei SystemOut.log des Deployment Manager von Version 9.0 nach Warnungen und Fehlern.
      Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
    9. Starten Sie den migrierten Node Agent mit Version 9.0.
    10. Suchen Sie in der Datei SystemOut.log des Deployment Manager und des Knotens mit Version 9.0 nach Warnungen oder Fehlern.
    11. Synchronisieren Sie die Zelle.
    12. Stoppen Sie alle Anwendungsserver auf dem migrierten Knoten von Version 9.0.
    13. Starten Sie die entsprechenden Anwendungsserver auf dem migrierten Knoten von Version 9.0.
    14. 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 migrierten Servern zuteilen können, die Ihre Stapelanwendungen hosten.

      Greifen Sie nach dem Neustart der migrierten Anwendungsserver bzw. Cluster ü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 von Version 9.0, die Ihre Stapelanwendungen hosten, ordnungsgemäß funktionieren:
      1. Vergewissern Sie sich, dass die Stapelanwendungen im migrierten Server oder Cluster gestartet sind. Durchsuchen Sie die Server- bzw. Clusterprotokolle nach Fehlern.
      2. 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.
    15. Speichern Sie die Profilkonfiguration der Version 9.0 in einer Datei, indem Sie den Befehl backupConfig mit den entsprechenden Parametern ausführen. Beispiel:
      /opt/WebSphereV90/profiles/v70toV90node1/bin/backupConfig.sh /mybackupdir/
      v70toV90node1.zip -username myuser -password mypass -nostop
      Verwenden Sie jedes Mal, wenn Sie den Befehl backupConfig ausführen, einen neuen Sicherungsdateinamen.
    16. Speichern Sie die Deployment-Manager-Konfiguration in einer Datei, indem Sie den Befehl backupConfig mit den entsprechenden Parametern ausführen. Bevor Sie den Befehl ausführen, wechseln Sie auf dem Deployment-Manager-Host von Version 9.0 in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
      Anmerkung: Sichern Sie für jeden migrierten Knoten die Deployment-Manager-Konfiguration von Version 9.0 in einer neuen Sicherungsdatei.
      Beispiel:
      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh /mybackupdir/
      v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
      Anmerkung: Wenn Sie einen Knoten auf einen anderen Host migrieren möchten, folgen Sie den Anweisungen zur Migration von Knoten unter Zellen mit dem Befehlszeilentool auf neue Hostmaschinen migrieren aus.

Ergebnisse

Sie haben eine frühere Version mit den Migrationstools auf WebSphere Application Server Version 9.0 migriert.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_migrate_cells_commandline
Dateiname:tmig_migrate_cells_commandline.html