Migración de un gestor de despliegue z/OS
Después de generar trabajos JCL para migrar un gestor de despliegue a WebSphere Application Server para z/OS Versión 9.0, puede realizar la migración real ejecutando esos trabajos. Cuando ha generado los trabajos de migración personalizados, también ha creado instrucciones personalizadas para preparar y ejecutar los trabajos de migración en los miembros BBOMDINS 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 gestor de despliegue a 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 (lenguaje de control de trabajos).
- Cree siempre primero el nodo del gestor de despliegue.
- Revise los requisitos de coexistencia aplicables del sistema.
- El ID de usuario de administrador de WebSphere
debe someter el trabajo BBOWMG3D al 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.
- Nota sobre el mantenimiento de la alta disponibilidad durante la migración de la
Versión 7.0 o posterior a la Versión 9.0:
la migración de un gestor de despliegue de la Versión 7.0 o posterior a la Versión 9.0 vuelve a desplegar todos los binarios de aplicación cuando se reinicia el gestor de despliegue. Esta acción hace que el gestor de despliegue recicle todas las aplicaciones del sysplex. Esto puede provocar una caída en un sysplex que está configurado para alta disponibilidad si los valores de sincronización no están inhabilitados.
Para mantener la alta disponibilidad durante la migración, desactive todas las opciones de sincronización para todos los agentes de nodo en el sysplex antes de reiniciar el gestor de despliegue.- Abra la consola administrativa.
- Vaya a Administración del sistema > Agentes de nodo.
- Para cada agente de nodo del sysplex, vaya a nombre_servidor_agente_nodo > Servicio de sincronización de archivos e inhabilite todos los procesos de sincronización.
- Sugerencia: antes de migrar un gestor de despliegue 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

- WebSphere Extended Deployment Compute Grid o Feature Pack for Modern Batch
- WebSphere Virtual Enterprise o Intelligent Management
Procedimiento
- 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 BBOMDHFS o BBOMDZFS 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 antes de continuar. 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.
BBOMDHFS o BBOMDZFS 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 l os 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 BBOMDHFS o BBOMDZFS. 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.
- Copie los procedimientos JCL generados.
El programa de utilidad de migración BBOMDCP 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 BBOMDCP 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 del controlador de gestor de despliegue de la Versión 7.0 o posterior es AZDCR y ha especificado AZ1DCR para la Versión 9.0, deberá 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 AZ1DCR.* STDATA(USER(AZDCRU) 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.
- Efectúe una de las acciones siguientes:
- Someta el trabajo BBOWMG3D.
Una migración de gestor de despliegue no requiere que el nodo entre o salga de la modalidad PRR (Reinicio y recuperación por igual) como lo hacen las migraciones de nodo federado y de servidor de aplicaciones autónomo. Hay dos trabajos menos que someter para una migración del gestor de despliegue, por lo tanto, está listo para realizar la migración física.
BBOWMG3D es el trabajo que realiza la migración física del gestor de despliegue de la Versión 7.0 o posterior a la Versión 9.0 basándose en la información que se ha proporcionado al generar los trabajos de migración. Someta BBOWMG3D. Verifique que obtiene códigos de retorno 0 y revise los archivos de registro del directorio temporal de migración en el 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 de directorio temporal y nnnnn es el valor numérico generado para el identificador de la migración durante al creación de los trabajos de migración. La ubicación de directorio temporal predeterminada es /tmp/migrate.
- Someta los tres trabajos siguientes:
- Someta el trabajo BBOWDPRO.
BBOWDPRO crea el perfil inicial y predeterminado de WebSphere Application Server.
- Someta el trabajo BBOWDPRE.
BBOWDPRE ejecuta el proceso previo a la actualización de la migración.
- Someta el trabajo BBOWDPOS.
BBOWDPOS ejecuta los procesos posteriores a la actualización y de finalización (cambiar permiso de archivo) de la migración.
- Someta el trabajo BBOWDPRO.
- Someta el trabajo BBOWMG3D.
- Examine sus valores de control de rastreo antes
de la migración.
Existen valores de configuración específicos que requieren cambios manuales para migrar WebSphere Application Server. Utilice la consola de administración para examinar la lista de variables de entorno como se indica a continuación:
- Pulse Entorno > Gestionar variables de WebSphere.
- En la pestaña Configuración, busque la variable ras_trace_outputlocation y anote su valor si está presente.
Si ras_trace_outputlocation se ha establecido en TRCFILE, deberá modificar manualmente el procedimiento de inicio para el nuevo WebSphere Application Server para incluir una sentencia TRCFILE DD.
Avoid trouble: La modificación manual del procedimiento de inicio debe realizarse antes de iniciar el nuevo WebSphere Application Server y los daemons asociados.gotcha
- Concluya los servidores de aplicaciones y el daemon antiguos.
Asegúrese de que todos los nodos de la LPAR del gestor de despliegue se hayan concluido.
- Si es necesario, actualice el procedimiento JCL del 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 gestor de despliegue.
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 7.0 o posterior 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 más reciente.
- 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 7.0 o posterior en una célula de la Versión 7.0 o posterior 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 7.0 a la STEPLIB del daemon de la Versión 9.0.
- Inicie el nuevo gestor de despliegue.
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 especificado en el panel de gestor de despliegue para el nombre de procedimiento de controlador al generar los trabajos de migración. Este mandato inicia el gestor de despliegue 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 BBODMGR:BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
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 generado para el identificador de la migración cuando se han creado 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_adm
File name: tmig_z_adm.html