Migración de un servidor de aplicaciones autónomo en el sistema operativo z/OS

Después de generar trabajos JCL (Lenguaje de control de trabajos) para migrar un nodo de servidor de aplicaciones autónomo a WebSphere Application Server para z/OS Versión 9.0, puede realizar la migración real ejecutando esos trabajos. Al generar los trabajos de migración personalizados, también ha creado instrucciones personalizadas para preparar y ejecutar los trabajos de migración en los miembros BBOMBINS del conjunto de datos CNTL que se ha utilizado para generar los trabajos. Siga estas instrucciones personalizadas para completar el proceso de migración del servidor de aplicaciones autónomo a la Versión 9.0.

Antes de empezar

Supported configurations Supported configurations:

En este artículo se describe la migración de la configuración de perfil. Para migrar sus aplicaciones a la versión más reciente, utilice WebSphere Application Server Migration Toolkit. Para obtener más información, consulte Migration Toolkit en WASdev.

sptcfg
  • Consulte Visión general de la migración, la coexistencia y la interoperatividad y Consideraciones sobre la migración.
  • No puede continuar si no ha generado los trabajos de migración JCL.
  • Un ID de usuario de administrador de WebSphere debe someter los trabajos BBOWMG1B, BBOWMG2B, BBOWMG3B, BBOWBPRO, BBOWBPRE y BBOWBPOS a los que se hace referencia en estas instrucciones.

    Todos los demás trabajos deben someterse mediante un ID de usuario que tenga control sobre el sistema de archivos.

  • Debe asegurarse de que el nombre del directorio inicial del perfil no es un único carácter alfabético seguido de dos puntos, como por ejemplo a:. Los trabajos de migración interpretan un nombre con un único carácter alfabético como "/", lo que provoca que se produzca un bucle infinito.
  • Sugerencia: antes de migrar un servidor de aplicaciones autónomo de WebSphere Application Server Versión 7.0 o posterior, utilice el mandato backupConfig o el programa de utilidad de copia de seguridad que prefiera para hacer una copia de seguridad de la configuración existente si desea poder restaurarlo a su estado anterior después de la migración. Consulte Mandato backupConfig para obtener más información. Asegúrese de anotar el nombre y la ubicación exactos de esta configuración de copia de seguridad.

Para obtener ayuda, lea Resolución de problemas de migración.

Acerca de esta tarea

For transitioning users For transitioning users: Los siguientes productos antes requerían herramientas de migración independientes, pero ahora se migran como parte de los procedimientos de migración estándar:
  • WebSphere Extended Deployment Compute Grid o Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise o Intelligent Management
Para obtener más información sobre estos cambios, consulte Novedades para la migración.trns

Procedimiento

  1. Cree y monte un nuevo sistema de archivos de configuración de la Versión 9.0.

    Antes de realizar la migración, la Versión 9.0 necesita que exista un sistema de archivos para la nueva configuración. Puede ejecutar el trabajo BBOMBHFS o BBOMBZFS para crear y montar un nuevo sistema de archivos de configuración o puede montar uno manualmente. De cualquiera de los modos, debe haber creado y montado un sistema de archivos para la configuración de la Versión 9.0. Este sistema de archivos de configuración es el destino de la migración; el sistema de archivos de configuración de la Versión 7.0 o posterior es el origen.

    El trabajo BBOMBHFS o BBOMBZFS crea un directorio de punto de montaje, asigna el sistema de archivos de la configuración y monta el sistema de archivos en el valor que se ha especificado para el punto de montaje en el momento de generar los trabajos de migración.

    Antes de continuar, asegúrese de haber asignado, creado y montado los conjuntos de datos del sistema de archivos de configuración manualmente o utilizando el trabajo BBOMBHFS o BBOMBZFS. El ID de administrador de WebSphere debe ser el propietario del punto de montaje y éste debe tener permisos de 755 como mínimo. Las nuevas estructuras del sistema de archivos de configuración deberían incluirse en BPXPARM para que se monten en la IPL siguiente.

  2. Copie los procedimientos JCL generados.

    El programa de utilidad de migración BBOMBCP copia los procedimientos JCL generados utilizados para iniciar los servidores en la biblioteca de procedimientos especificada. La configuración de la Versión 9.0 debe utilizar procedimientos JCL diferentes de los utilizados en la configuración de la Versión 7.0 o posterior. Este programa de utilidad actualiza la nueva configuración de la Versión 9.0, sustituyendo con los nuevos nombres de JCL los nombres que existían en la configuración original de la Versión 7.0 o posterior.

    Precaución: Este programa de utilidad copia el JCL generado en la biblioteca de procedimientos. Si ha especificado los mismos nombres que ha utilizado en la configuración de la Versión 7.0 o posterior cuando generó los trabajos de migración, este programa de utilidad sobrescribirá los procedimientos existentes. Si utiliza los mismos nombres, asegúrese de hacer una copia de seguridad de los procedimientos de la Versión 7.0 o posterior antes de ejecutar este programa de utilidad por si fuera necesario retrotraerlos más adelante.

    Someta el trabajo BBOMBCP y verifique un código de retorno de 0.

  3. Si ha especificado nuevos nombres de procedimiento, actualice los perfiles RACF STARTED para el controlador y el daemon.
    El perfil STARTED utilizado por las regiones de controlador se basa en el nombre de procedimiento y JOBNAME. Debe asegurarse de que se aplicará el perfil STARTED, de modo que se asignará la identidad correcta a la tarea iniciada. Por ejemplo, si el nombre de procedimiento JCL de controlador de la Versión 7.0 o posterior es AZACR y ha especificado AZ6ACR para la Versión Versión 9.0, será necesario crear un perfil STARTED para ese nuevo nombre de procedimiento:
                  nuevo nombre        misma identidad usada en
                     nombre JCL         configuración V7.0 o posterior
                        |                    |
     RDEFINE STARTED AZ6ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    Nota:
    • No utilice otro ID de usuario para el inicio. Existen otros aspectos ligados al ID de usuario; si cambia el ID de usuario, también se requerirán otros cambios.
    • Si el perfil STARTED original era genérico, por ejemplo, STARTED AZ*.* ... , tendría que crear un nuevo perfil STARTED.
    • Los perfiles STARTED de regiones de servant se basan en JOBNAME, no en nombres de procedimiento. Por este motivo, no existe ningún problema cuando se utiliza otro nombre de procedimiento.
    • Los daemons y agentes de nodo son controladores, por lo que el uso de otros nombres de procedimiento para éstos implica un nuevo perfil STARTED.
  4. Someta los trabajos BBOWMG1B y BBOWMG2B.
    Nota: Si no utiliza conectores XA, el sometimiento de los trabajos BBOWMG1B y BBOWMG2B es opcional. No obstante, debería someter los dos trabajos para asegurarse de que los archivos de anotaciones cronológicas de transacción están limpios.

    El trabajo BBOWMG1B permite que todos los servidores del nodo servidor de aplicaciones que se está migrando se inicien en modalidad de proceso PRR (Reinicio y recuperación por igual). La modalidad de proceso PRR resuelve las transacciones pendientes, borra las anotaciones cronológicas de transacción y detiene el servidor. El trabajo BBOWMG2B inhabilita la modalidad PRR y devuelve todos los servidores al estado de operación normal.

    Siga estos pasos para borrar el contenido de las anotaciones cronológicas de transacciones XA:
    1. Someta el trabajo BBOWMG1B y verifique un código de retorno de 0.
    2. Reinicie el servidor de aplicaciones y espere a que éste realice el proceso PRR y se detenga automáticamente.
    3. Someta el trabajo BBOWMG2B y verifique un código de retorno de 0.
  5. Detenga el daemon y el servidor de aplicaciones de la Versión 7.0 o posterior.

    El daemon debe tener el nivel máximo de versión de todos los servidores que gestiona en la misma LPAR. Tendrá el nivel de la Versión 9.0 cuando se inicie el servidor.

    Debe detener el servidor de aplicaciones de la Versión 7.0 o posterior antes de continuar.

  6. Suprima y vuelva a definir la corriente de registro.

    Realice este paso sólo si ha configurado previamente el registro de asociados XA de transacciones o el registro de compensación en el servidor de la Versión 7.0 o posterior para utilizar una corriente de registro.

    1. Asegúrese de que el nodo se ha detenido.
    2. Suprima y vuelva a definir la corriente de registro.

      Puede utilizar los trabajos BBOLOGSD y BBOLOGSA que se han creado durante la personalización de la Versión 7.0 o posterior si ha configurado el servidor inicialmente para que utilice la corriente de registro.

      En el siguiente ejemplo se muestra un ejemplo de dicho trabajo:
      //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) /* Por omisión mostrar salida de trabajo */
       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. Efectúe una de las acciones siguientes:
    1. Someta el trabajo BBOWMG3B.

      El trabajo BBOWMG3B realiza la migración física del nodo de la Versión 7.0 o posterior a la Versión 9.0 basándose en la información proporcionada al generar los trabajos de migración. Someta el trabajo BBOWMG3B, verifique que obtiene códigos de retorno de 0 y revise los archivos de registro en el directorio temporal de migración del sistema de archivos. El directorio temporal de migración es ubicación_directorio_temporal/nnnnn, donde ubicación_directorio_temporal es el directorio especificado para la ubicación del directorio temporal (/tmp/migrate por omisión) y nnnnn es el valor numérico generado para el identificador de la migración durante la creación de los trabajos de migración.

    2. Someta los tres trabajos siguientes:
      1. Someta el trabajo BBOWBPRO.

        BBOWBPRO crea el perfil por omisión e inicial de Websphere Application Server.

      2. Someta el trabajo BBOWBPRE.

        BBOWBPRE ejecuta el proceso previo a la actualización de la migración.

      3. Someta el trabajo BBOWBPOS.

        BBOWBPOS ejecuta los procesos posteriores a la actualización y de finalización (cambiar permiso de archivo) de la migración.

  8. Inicie el nuevo nodo de servidor de aplicaciones.

    Utilice los mandatos existentes que utilizaría para iniciar un servidor de aplicaciones de la Versión 7.0 o posterior, pero sustituya el nombre de procedimiento RACF STARTED por el valor que ha entrado para el nombre de procedimiento de controlador al generar los trabajos de migración. Este mandato inicia el servidor de aplicaciones de la Versión 9.0. Espere a que el servidor termine la inicialización antes de continuar.

    Aparecerá el mensaje siguiente en la consola y en las anotaciones de trabajo de BBOS001:
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  9. Para Compute Grid o Feature Pack for Modern Batch, verifique que el planificador de trabajos se haya migrado correctamente y que puede asignar trabajos a los servidores que alojan las aplicaciones por lotes.

    Para verificar la migración del planificador de trabajos, después de que se reinicie el servidor, acceda a la consola de gestión de trabajos a través de un navegador web.

    Para verificar que los servidores que alojan las aplicaciones por lotes funcionan correctamente:
    1. Verifique que se hayan iniciado las aplicaciones por lotes en el servidor migrado. Examine los registros del servidor en busca de errores.
    2. Verifique que puede asignar trabajos por lotes al servidor migrado enviando un trabajo desde el servidor del planificador de trabajos migrado. Puede enviar el trabajo utilizando la consola de gestión de trabajos, el programa de utilidad WSGrid, la interfaz EJB o la interfaz de servicios web.

Qué hacer a continuación

Después de verificar que se ha realizado una migración correcta a la Versión 9.0 y que se está ejecutando correctamente una configuración migrada, suprima los elementos siguientes:
  • Todo lo incluido en el sistema de archivos de la configuración de origen
  • Todo lo que contiene el directorio de la configuración de destino ubicación_directorio_temporal/nnnnn, donde ubicación_directorio_temporal es el directorio especificado para la ubicación del directorio temporal (/tmp/migrate por omisión) y nnnnn es el valor numérico generado para el identificador de la migración cuando se han creado los trabajos de migración.
  • El archivo bbomigrt2.sh

Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_sas
File name: tmig_z_sas.html