Migration d'un serveur d'applications autonome sur le système d'exploitation z/OS

Après avoir généré les travaux JCL nécessaires pour migrer un noeud de serveurs d'applications autonome vers WebSphere Application Server for z/OS Version 9.0, vous pouvez effectuer la migration à proprement parler en exécutant ces travaux. Lorsque vous avez généré les travaux de migration personnalisés, vous avez également créé des instructions personnalisées pour préparer et exécuter les travaux de migration dans les membres BBOMBINS du fichier CNTL utilisé pour la génération des travaux. Suivez ces instructions personnalisées pour exécuter le processus de migration de votre serveur d'applications autonome vers la Version 9.0.

Avant de commencer

Configurations prises en charge Configurations prises en charge:

Cet article traite de la migration de configuration de profil. Pour faire migrer vos applications vers la dernière version, utilisez le kit d'outils de migration de WebSphere Application Server. Pour plus d'informations, voir Migration Toolkit on WASdev.

sptcfg
  • Lisez les sections Présentation de la migration, de la coexistence et de l'interopérabilité et Considérations sur la migration.
  • Vous ne pourrez pas continuer si vous n'avez pas créé les travaux de migration JCL.
  • Les travaux BBOWMG1B, BBOWMG2B, BBOWMG3B, BBOWBPRO, BBOWBPRE et BBOWBPOS mentionnés dans les présentes instructions doivent être soumis par un ID administrateur WebSphere.

    Tous les autres travaux doivent être soumis par l'ID utilisateur qui contrôle le système de fichiers.

  • Vous devez veiller à ce que le nom du répertoire de base du profil ne soit pas un caractère alphabétique unique suivi du signe deux-points, comme par exemple a:. Les travaux de migration interprètent ce genre de noms comme "/", ce qui peut générer une boucle infinie.
  • Astuce : Avant de faire migrer un serveur d'applications autonome WebSphere Application Server Version 7.0 ou ultérieures, utilisez la commande backupConfig ou l'utilitaire de sauvegarde de votre choix pour effectuer une sauvegarde de votre configuration existante au cas où vous souhaiteriez la restaurer à son état antérieur après la migration. Pour plus d'informations, voir Commande backupConfig. N'oubliez pas de noter le nom et l'emplacement exacts de la sauvegarde de cette configuration.

Pour obtenir de l'aide, voir Résolution des incidents de migration.

Pourquoi et quand exécuter cette tâche

Pour les utilisateurs en transition Pour les utilisateurs en transition: Les produits suivants nécessitaient auparavant des outils de migration distincts ; à présent, ils sont migrés dans le cadre des procédures de migration standard :
  • WebSphere Extended Deployment Compute Grid ou Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise ou Intelligent Management
Pour plus d'informations sur ces changements, voir Nouveautés pour la migration.trns

Procédure

  1. Créez et montez un nouveau système de fichiers de configuration Version 9.0.

    Avant la migration, Version 9.0 requiert la présence d'un système de fichiers de configuration en vue de la nouvelle configuration. Vous pouvez exécuter les travaux BBOMBHFS ou BBOMBZFS pour créer et monter un nouveau système de fichiers de configuration ou vous pouvez en monter un manuellement. Quelle que soit la méthode employée, un système de fichiers de configuration doit être créé et monté pour votre configuration Version 9.0 avant que vous ne puissiez poursuivre. Ce système de fichiers de configuration est la cible de la migration, sa source étant votre système de fichiers de configuration Version 7.0 ou ultérieures.

    Le travail BBOMBHFS ou BBOMBZFS crée un répertoire de point de montage, attribue le système de fichiers de configuration et monte le système de fichiers au point de montage que vous avez indiqué lors de la génération de vos travaux de migration.

    Avant de poursuivre, assurez-vous que vous avez bien attribué, créé et monté vos fichiers système de configuration, soit manuellement, soit en utilisant le travail BBOMBHFS ou BBOMBZFS. Le point de montage doit appartenir à l'ID d'administrateur WebSphere et posséder les droits minimum de 755. Les nouvelles structures de système de fichiers de configuration doivent être incluses dans BPXPARM pour qu'elles soient montées au prochain IPL.

  2. Copiez les procédures JCL générées.

    L'utilitaire de migration BBOMBCP copie vers la bibliothèque de procédure spécifiée les procédures JCL générées pour démarrer les serveurs. Votre configuration Version 9.0 doit utiliser des procédures JCL différentes de celles qui étaient utilisées par votre configuration Version 7.0 ou ultérieures. Cet utilitaire met à jour la nouvelle configuration Version 9.0, en remplaçant les noms de la configuration d'origine Version 7.0 ou ultérieures par les nouveaux noms JCL.

    Attention : Cet utilitaire copie le JCL généré vers votre bibliothèque de procédures. Si vous avez spécifié les mêmes noms que ceux utilisés dans la configuration Version 7.0 ou ultérieures lorsque vous avez généré vos travaux de migration, l'utilitaire remplacera les procédures existantes. Par conséquent, si vous utilisez les mêmes noms, veillez à sauvegarder les procédures Version 7.0 ou ultérieures existantes avant d'exécuter cet utilitaire pour le cas où vous auriez besoin de procéder à une rétromigration.

    Soumettez le travail BBOMBCP et vérifiez si le code retour est 0.

  3. Si vous avez indiqué de nouveaux noms de procédure, mettez à jour les profils RACF STARTED du contrôleur et du démon.
    Le profil STARTED utilisé par les régions du contrôleur repose sur le nom de la procédure et JOBNAME. Vous devez vous assurer qu'un profil STARTED s'applique pour que la bonne identité soit affectée à la tâche démarrée. Par exemple, si le nom de procédure JCL du contrôleur de la Version 7.0 ou ultérieures est AZACR, et que vous avez indiqué AZ6ACR pour la version Version 9.0, vous devez créer un profil STARTED pour ce nouveau nom de procédure :
                  nom JCL du      même identité que dans
                     JCL name         V7.0 or later configuration
                        |                    |
     RDEFINE STARTED AZ6ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    Remarque :
    • N'utilisez pas un ID utilisateur différent pour démarrer. Certains éléments sont également liés à l'ID utilisateur ce qui nécessite des changements en cas de modification de l'ID utilisateur.
    • Si votre profil d'origine STARTED était générique, STARTED AZ*.* ... par exemple, vous n'avez pas besoin de créer un nouveau profil STARTED.
    • Les profils STARTED de région serviteur sont basés sur JOBNAME, pas sur le nom de la procédure. Ainsi, il n'y a pas de problème avec le serviteur lorsque vous utilisez un nom de procédure différent.
    • Les démons et les agents de noeud sont des contrôleurs ; l'utilisation de différents noms de procédure pour ceux-ci implique donc un nouveau profil STARTED.
  4. Soumettez les travaux BBOWMG1B et BBOWMG2B.
    Remarque : Si vous n'utilisez pas de connecteurs XA, la soumission des travaux BBOWMG1B et BBOWMG2B est facultative. Néanmoins, soumettez les deux tâches pour que vos journaux de transaction soient vides.

    Le travail BBOWMG1B permet de démarrer tous les serveurs situés sur le noeud du serveur d'applications migré en mode PRR (Peer Restart and Recovery). Le mode de traitement PRR résout les transactions en attente, vide les journaux de transaction et arrête le serveur. Le travail BBOWMG2B désactive le mode PRR et renvoie tous les serveurs à l'état de fonctionnement normal.

    Suivez ces étapes pour effacer les journaux de transaction XA :
    1. Soumettez le travail BBOWMG1B et vérifiez si le code retour est 0.
    2. Redémarrez le serveur d'applications et attendez qu'il exécute le traitement PRR et qu'il se termine automatiquement.
    3. Soumettez le travail BBOWMG2B et vérifiez si le code retour est 0.
  5. Arrêtez le serveur d'applications et le démon Version 7.0 ou ultérieures.

    Le démon doit être au niveau de version le plus élevé de tous les serveurs dont il assure la gestion dans la même partition LPAR. Il sera au niveau Version 9.0 lors du démarrage du serveur.

    Vous devez arrêter le serveur d'applications Version 7.0 ou ultérieures avant de poursuivre.

  6. Supprimez et redéfinissez le flot de journalisation.

    Exécutez ces étapes uniquement si vous avez configuré auparavant le journal du partenaire XA de transaction ou le journal de compensation dans le serveur Version 7.0 ou ultérieures pour utiliser le flot de journalisation.

    1. Assurez-vous que le noeud est fermé.
    2. Supprimez et redéfinissez le flot de journalisation.

      Vous pouvez utiliser les travaux BBOLOGSD et BBOLOGSA qui ont été créés pendant la personnalisation Version 7.0 ou ultérieures si vous avez initialement configuré le serveur de sorte qu'il utilise le flot de journalisation.

      L'échantillon suivant fournit un exemple de ce type de tâche :
      //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) /* Default to show output of job */
       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)
      /*
  7. Effectuez l'une des actions suivantes :
    1. Soumettez le travail BBOWMG3B.

      Le travail BBOWMG3B procède à la migration physique du noeud Version 7.0 ou ultérieures vers la version Version 9.0 en fonction des informations que vous avez fournies lorsque vous avez généré les travaux de migration. Soumettez le travail BBOWMG3B, vérifiez que les codes retour sont 0 et consultez les fichiers journaux dans le répertoire temporaire de migration du système de fichiers. Le répertoire temporaire de migration est emplacement_répertoire_temporaire/nnnnn, où emplacement_répertoire_temporaire est la valeur spécifiée pour l'emplacement du répertoire temporaire (/tmp/migrate par défaut) et nnnnn est la valeur numérique qui a été générée pour l'identificateur de migration lorsque vous avez généré vos travaux de migration.

    2. Soumettez les trois travaux suivants :
      1. Soumettez le travail BBOWBPRO.

        BBOWBPRO crée le profil de base et le profil par défaut de Websphere Application Server.

      2. Soumettez le travail BBOWBPRE.

        BBOWBPRE exécute le processus préalable à la migration.

      3. Soumettez le travail BBOWBPOS.

        BBOWBPOS exécute les processus postérieurs à la migration et les processus de finalisation (droits de modification des fichiers).

  8. Démarrez le nouveau noeud de serveur d'applications.

    Utilisez les commandes existantes que vous utiliseriez pour démarrer un serveur d'applications Version 7.0 ou ultérieures, mais remplacez le nom de procédure RACF STARTED par la valeur que vous avez entrée pour le nom de procédure du contrôleur lorsque vous avez généré vos travaux de migration. Cette commande démarre le serveur d'applications Version 9.0. Attendez que le serveur ait fini de s'initialiser avant de lancer le traitement.

    Le message suivant s'affiche dans la console et dans le journal des travaux BBOS001 :
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  9. Pour les applications Compute Grid ou Feature Pack for Modern Batch, vérifiez que le planificateur de tâches a été migré correctement et que vous pouvez envoyer des travaux aux serveurs qui hébergent vos applications de traitement par lots.

    Pour vérifier la migration du planificateur de travaux, après le redémarrage du serveur, accédez à la console de gestion de travaux par le biais d'un navigateur Web.

    Pour vérifier que les serveurs qui hébergent vos applications par lots fonctionnent correctement :
    1. Vérifiez que les applications de traitement par lots sur le serveur migré sont démarrées. Examinez les journaux du serveur pour rechercher les erreurs éventuelles.
    2. Vérifiez que vous pouvez envoyer des travaux par lots au serveur migré en soumettant un travail à partir du serveur du planificateur de travaux migré. Vous pouvez soumettre le travail à l'aide de la console de gestion des tâches, l'utilitaire WSGrid, l'interface EJB, ou l'interface de services Web.

Que faire ensuite

Après avoir vérifié que la migration vers la Version 9.0 s'est bien déroulée et que la configuration migrée fonctionne correctement, supprimez les éléments suivants :
  • Tout le contenu du système de fichiers de la configuration source
  • Tout dans le répertoire emplacement_répertoire_temporaire/nnnnn de la configuration cible, où emplacement_répertoire_temporaire est la valeur spécifiée pour l'emplacement du répertoire temporaire (/tmp/migrate par défaut) et nnnnn est la valeur numérique qui a été générée pour l'identificateur de migration lorsque vous avez créé vos travaux de migration.
  • Le fichier bbomigrt2.sh.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_sas
Nom du fichier : tmig_z_sas.html