Migración de un nodo federado z/OS
Después de migrar y reiniciar el gestor de despliegue, podrá realizar la migración real de los nodos de servidor de aplicaciones federados ejecutando los trabajos JCL (Lenguaje de control de trabajos) que se han generado. 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 BBOMMINS del conjunto de datos CNTL que se ha utilizado para generar los trabajos. Siga estas instrucciones personalizadas para completar el proceso de migración de los nodos federados a la Versión 9.0.
Antes de empezar

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.
- Los trabajos BBOWMG1F, BBOWMG2F y BBOWMG3F a los que se hace referencia
en estas instrucciones deben ser sometidos por un ID de usuario de administrador
de WebSphere.
Todos los demás trabajos deben someterse mediante un ID de usuario que tenga control sobre el sistema de archivos.
- Para migrar un nodo federado a otra imagen MVS, asegúrese de ejecutar los trabajos en el mismo sistema en el que reside el propio nodo.
- Sugerencia: cuando se migra un nodo federado de WebSphere Application Server Versión 7.0 o posterior, debe realizar las acciones
siguientes si desea poder retrotraerlo a su estado anterior después de la migración:
- Haga una copia de seguridad de la configuración existente utilizando el mandato backupConfig o el programa de utilidad de copia de seguridad que desee.
- Ejecute el mandato backupConfig o el programa de utilidad que desee para hacer la copia de seguridad de la configuración del gestor de despliegue de la Versión 9.0.
- Ejecute el mandato backupConfig o el programa de utilidad que prefiera para hacer una copia de seguridad de la configuración del nodo federado de la Versión 7.0 o posterior.
Importante: Asegúrese de anotar el nombre y la ubicación exactos de esta configuración de copia de seguridad.Lea el artículo Mandato backupConfig en la documentación para obtener más información.
- Migre el nodo federado.
Si es necesario, ahora puede retrotraer el nodo federado que acaba de migrar. Lea Cómo retrotraer un nodo federado para obtener más información.
- Haga una copia de seguridad de la configuración existente utilizando el mandato backupConfig o el programa de utilidad de copia de seguridad que desee.
Para obtener ayuda, lea Resolución de problemas de migración.
Acerca de esta tarea

- WebSphere Extended Deployment Compute Grid o Feature Pack for Modern Batch
- WebSphere Virtual Enterprise o Intelligent Management
Procedimiento
- Asegúrese de que los servidores de aplicaciones y el agente de nodo se han detenido para el nodo federado que se está migrando.
Debe detener el nodo federado antes de continuar.
- Asegúrese de que el gestor de despliegue que se acaba de migrar está en ejecución.
Para que el nodo de servidor de aplicaciones se migre correctamente, el gestor de despliegue debe estar en ejecución. Para que esta migración funcione, el gestor de despliegue debe estar activo y a la escucha en su puerto SOAP.
Tabla 1. El gestor de despliegue se está ejecutando. Comprobar cuando se haya completado Marcar Elemento Acceda a la consola de administración del gestor de despliegue de WebSphere Application Server Versión 9.0. Esto valida que se está ejecutando el gestor de despliegue. Tabla 2. El servidor de aplicaciones se está ejecutando. Comprobar cuando se haya completado Marcar Elemento Asegúrese de que está en ejecución la copia de WebSphere Application Server Versión 9.0 del código. La versión que aparece en el panel Bienvenido de la consola administrativa. - 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 de configuración para la nueva configuración. Puede ejecutar BBOMMHFS o BBOMMZFS para crear y montar un nuevo sistema de archivos de configuración, o bien, montarlo 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.
BBOMMHFS o BBOMMZFS 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 haya 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 bien utilizando BBOMMHFS o BBOMMZFS. El ID de usuario 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.
- Someta BBOWMG1F y BBOWMG2F. Nota: Si no utiliza conectores XA, someter BBOWMG1F y BBOWMG2F 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.
BBOWMG1F permite que todos los servidores del nodo servidor de aplicaciones federado que se está migrando se inicien en modalidad 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. BBOWMG2F 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:- Detenga el servidor de aplicaciones.
- Someta el trabajo BBOWMG1F y verifique un código de retorno 0.
- Reinicie el servidor de aplicaciones federado y espere a que realice el proceso PRR
y se detenga automáticamente.Consejo: Tras resolver las transacciones y una vez detenido el servidor, se prevé un código de retorno distinto de cero y es normal. A continuación encontrará un ejemplo de un código de resultado aceptable del proceso del servidor:
BBOO0035W TERMINATING THE CURRENT PROCESS, REASON=C9C218D5
- Someta el trabajo BBOWMG2F y verifique un código de retorno 0.
- Copie los procedimientos JCL generados.
El programa de utilidad de migración BBOMMCP copia los procedimientos JCL generados 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 actualizará 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 BBOMMCP y verifique que el código de retorno es 0.
- 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 AZ1ACR para la 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 AZ1ACR.* 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 así como otros cambios que es necesario realizar si cambia el ID de usuario.
- 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.
- Si es necesario, suprima y vuelva a definir la corriente de anotaciones cronológicas. 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.
- Asegúrese de que el nodo se ha detenido.
- 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) /*
Si está migrando nodos en un sysplex, siga este procedimiento para cada nodo federado que se migra.
- Efectúe una de las acciones siguientes:
- Someta el trabajo BBOWMG3F. Atención: Cuando se ejecuta en un entorno z/OS y se configura con varias pilas TCP/IP, es posible que tenga que añadir la variable de entorno _BPXK_SETIBMOPT_TRANSPORT para dirigir el trabajo de migración a la pila TCP/IP correcta que se debe utilizar. Si utiliza la pila incorrecta, el resultado genera java.net.UnknownHostException, lo que hace que el inicio de sesión wsadmin posterior falle.Es necesaria una sentencia export _BPXK_SETIBMOPT_TRANSPORT=<nombre.pila> en el JCL para identificar la pila correcta. El JCL puede ser similar al siguiente:
//*************************************************************** //* //* UPGRADE: Realizar la migración al nuevo perfil //* //*************************************************************** //* //* //UPGRADE EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE) //SYSTSPRT DD SYSOUT=* //STDENV DD * // _CEE_RUNOPTS=TRAP(ON,NOSPIE) //* //SYSTSIN DD * BPXBATCH SH + export _BPXK_SETIBMOPT_TRANSPORT=TCP; + /tmp/migrate/bbomigrt2.sh WASPostUpgrade + /tmp/migrate/28133744/_ + 1>> /tmp/migrate/28133744/BBOWMG3F.out + 2>> /tmp/migrate/28133744/BBOWMG3F.err; /*
BBOWMG3F es el trabajo que realiza la migración física del nodo de la Versión 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 BBOWMG3F, verifique que obtiene códigos de retorno 0 y revise los archivos de anotaciones cronológicas en el directorio temporal de migración del sistema de archivos de configuración. 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.
- Someta los tres trabajos siguientes:
- Someta el trabajo BBOWMPRO.
BBOWMPRO crea el perfil por omisión e inicial de Websphere Application Server.
- Someta el trabajo BBOWMPRE.
BBOWMPRE ejecuta el proceso previo a la actualización de la migración.
- Someta el trabajo BBOWMPOS.
BBOWMPOS ejecuta los procesos posteriores a la actualización y de finalización (cambiar permiso de archivo) de la migración.
- Someta el trabajo BBOWMPRO.
- Someta el trabajo BBOWMG3F.
- Asegúrese de que el daemon antiguo se ha detenido.
Asegúrese de que todos los nodos federados de la misma célula en esta LPAR se han detenido.
- Si es necesario, actualice el procedimiento JCL de daemon.
WebSphere Application Server para z/OS Versión 9.0 necesita que el proceso de daemon esté en el nivel más alto de código de cualquiera de los servidores que gestiona en la misma LPAR. Tendrá el nivel de la Versión 9.0 cuando se inicie el nodo federado.
Después de migrar todos los nodos a la Versión 9.0 ya antes de eliminar las bibliotecas de la versión anterior del sistema, debe actualizar el procedimiento JCL del daemon. Si no lo hace, el daemon no podrá iniciarse.
Nota:- Si está migrando de la Versión 6.1 a la Versión 9.0, el daemon necesita tener una STEPLIB que incluya los conjuntos de datos SBBOLD2 y SBBOLPA de la Versión 6.1.
- Si una célula de la Versión 9.0 tiene un servidor de la Versión 9.0 que se comunica con un servidor de la Versión 6.1 en una célula de la Versión 6.1 que está en el mismo sistema que la célula de la Versión 9.0, también es necesario añadir los conjuntos de datos SBBOLD2 y SBBOLPA de la Versión 6.1 a la STEPLIB del daemon de la Versión 9.0.
- Inicie el nuevo nodo de servidor de aplicaciones federado.
- Inicie el agente de nodo. Aparecerá el mensaje siguiente en la consola y en las anotaciones de trabajo de BBON001:
BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBON001
- Iniciar el servidor de aplicaciones federado.
Utilice el mandato existente 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 especificado en el panel de nodo federado para el nombre de procedimiento de controlador al generar los trabajos de migración. Este mandato inicia el servidor de aplicaciones federado 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 el registro de trabajo de BBOS001:BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
- Inicie el agente de nodo.
- Verifique que la configuración y las aplicaciones se hayan migrado correctamente.
Para Compute Grid o Feature Pack for Modern Batch, verifique también 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 gestor de despliegue, 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:- Verifique que se hayan iniciado las aplicaciones por lotes en el servidor migrado. Examine los registros del servidor en busca de errores.
- 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
- 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 especificado para el identificador de migración durante la creación de los trabajos de migración.
- El archivo bbomigrt2.sh


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