Consideraciones sobre la migración

Antes de empezar el proceso de migración a WebSphere Application Server Versión 9.0, hay algunas consideraciones que deberá tener en cuenta.

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

Consideraciones para z/OS

Tenga en cuenta la información siguiente antes de migrar Application Server para z/OS:
  • El progreso de migración normalmente incluye los valores de las variables definidas por el usuario o de las variables que se han definido mediante Application Server. Sin embargo, hay algunas variables especiales cuyos valores no se incluyen. Estos valores son:
    • WAS_INSTALL_ROOT
    • USER_INSTALL_ROOT
    • WAS_PRODUCT_ROOT
    • WAS_LIBS_DIR
    • WAS_PROPS_DIR
    • WAS_TEMP_DIR
    • APP_INSTALL_ROOT
    • DRIVER_PATH
    • WAS_INSTALL_LIBRARY
    • JAVA_HOME
    • DEPLOY_TOOL_ROOT
    • CONNECTOR_INSTALL_ROOT
    • TRANLOG_ROOT
    • MQJMS_LIB_ROOT
    • WAS_ETC_DIR
    • WEMPS_USER_ROOT
    • MQ_INSTALL_ROOT
    • WAS_DAEMON_ONLY_ICU_DATA
    • WAS_DAEMON_ONLY_CONFIG_ROOT
    • WAS_DAEMON_primordial_root
    • WAS_DAEMON_daemon_was_env_file
    Los valores de estas variables se toman de la plantilla de perfiles cuando la migración crea los perfiles. Si ha definido valores personalizado para estas variables, no se conservarán en el release de Application Server al cual está realizando la migración. Estas variables no se migrarán porque son las propiedades de Application Server que son atributos de perfiles. Si tiene que sustituir sus valores por entradas que no sean los valores predeterminados, tendrá que cambiar el valor fuera de los procesos de instalación del producto, creación de perfiles y migración.
    Avoid trouble Avoid trouble: Preste especial atención a la variable APP_INSTALL_ROOT. Aunque APP_INSTALL_ROOT tenga una ubicación personalizada que haya definido el usuario, el proceso de migración, de forma predeterminada, instalará aplicaciones en la ubicación siguiente:
    ${USER_INSTALL_ROOT}/installedApps
    gotcha
    Para disponer del proceso de migración debe atenerse a una ubicación de instalación de aplicaciones que no sea el valor predeterminado:
    • Especifique la ubicación en el campo Directorio de instalación de aplicación de zMMT.
    • Seleccione la opción Migrar aplicaciones y utilizar el directorio de instalación de la aplicación anterior durante la migración para utilizar la vía de acceso de instalación sin tener que volverla a escribir. Si la vía de acceso de la instalación del release anterior contiene referencias a variables, Application Server no resolverá estas variables con los valores migrados.
  • Después de instalar WebSphere Application Server Versión 9.0 en el sistema operativo z/OS, es posible que desee crear una configuración de célula completa de WebSphere Application Server, Network Deployment y verificar que funciona correctamente antes de intentar migrar una célula o un nodo existente.

    Este proceso asegura que el sistema tenga todos los requisitos previos necesarios y soporte el nuevo nivel del producto.

  • Antes de realizar la migración, evalúe los elementos en desuso en WebSphere Application Server Versión 9.0.

    Para obtener más información, consulte Características en desuso, estabilizadas, reemplazadas y eliminadas.

  • Antes de migrar de WebSphere Application Server Versión 7.0 o posterior a la Versión 9.0, conecte el ID de región de servicio de aplicaciones a un conjunto de claves y verifique que el conjunto de claves tenga asociado el certificado WebSphereCA. De lo contrario, se producirán errores de seguridad si tiene activada la seguridad global.
  • En WebSphere Application Server Versión 7.0 o posterior se incluye el gestor de alta disponibilidad y las funciones del grupo principal.

    Consulte Consideraciones sobre la migración de grupos principales para ver las consideraciones sobre la topología y configuración de grupos principales que pueden afectar en la migración desde Versión 7.0 o posterior a la Versión 9.0.

  • Si piensa ejecutar un cliente IIOP (Internet Inter-ORB Protocol - Protocolo Inter-ORB de Internet) anterior a la versión 6.1 y dicho cliente va a interactuar con un servidor de la Versión 9.0 en la misma partición lógica (LPAR), la biblioteca de procedimientos de daemon para el daemon de la Versión 9.0 debe incluir en STEPLIB las bibliotecas SBBOLD2 y SBBOLPA del release anterior.
  • El soporte de migración necesita que las configuraciones de WebSphere Application Server de origen y de destino estén en la misma LPAR.

    Por consiguiente, no puede migrar una configuración existente a una LPAR de z/OS diferente. Tampoco puede migrar a o desde un sistema operativo que no sea z/OS utilizando los programas de utilidad de WebSphere Application Server Versión 9.0.

  • La migración de las células que abarcan sistemas operativos o entornos sysplex no debe presentar ningún problema de migración exclusivo. La migración se efectúa a nivel de nodo y se utilizan las herramientas proporcionadas basándose en la plataforma del nodo que está migrando.

    Para obtener información sobre cómo configurar una célula de plataformas combinadas, consulte el documento técnico WebSphere para z/OS -- Células heterogéneas.

  • WebSphere Application Server en el sistema operativo z/OS no da soporte a las herramientas de línea de mandatos WASPreUpgrade, WASPostUpgrade y manageprofiles soportadas por las versiones distribuidas y de i5/OS del producto.

    Debe generar los trabajos de migración utilizando la Herramienta de gestión de migración de z/OS o el mandato zmmt y, a continuación, someterlos de acuerdo con las instrucciones generadas.

  • La cantidad de almacenamiento que requiere el sistema durante la migración a la Versión 9.0 depende del entorno.
    • El tamaño del sistema de archivos se proporciona mediante el valor de la asignación principal en cilindros especificada en la Herramienta de gestión de migración de z/OS o en el mandato zmmt al generar una definición de migración. Además, este sistema de archivos puede expandirse automáticamente en la asignación secundaria especificada. Generalmente, los valores que las herramientas de migración proporcionan para estas asignaciones son suficientes para los datos de configuración.
    • El directorio de copias de seguridad de migración necesita mucho espacio temporal. La cantidad de espacio exacta depende de varios factores, pero 100 cilindros son suficientes en la mayoría de los casos (incluso para rastreo, si es necesario). Si tiene dudas sobre el espacio que hay disponible en su directorio temporal, utilice la opción de la Herramienta de gestión de migración de z/OS o el mandato zmmt para pasar el directorio temporal a una ubicación personalizada que tenga más espacio y monte allí su sistema de archivos temporal. Si no tiene espacio temporal suficiente, es posible que el proceso de migración termine antes de tiempo.
  • IBM® SDK, Java™ Technology Edition, Versión 8 es la versión de SDK predeterminada para WebSphere Application Server Versión 9.0. .
    Avoid trouble Avoid trouble: No habilite SDK, Java Technology Edition, Versión 8 a menos que todos los nodos se migren a la Versión 9.0.gotcha

    Consulte Migración de las API y especificaciones para obtener más información.

  • Cuando se migra una célula con varios nodos, las aplicaciones deben permanecer en el nivel de Java SDK más bajo hasta que se hayan migrado todos los nodos.
  • En los artículos relacionados con la migración se supone que WebSphere Application Server Versión 9.0 se está instalando en un entorno en el que debe coexistir con las versiones anteriores de WebSphere Application Server.
    Tenga en cuenta los siguientes elementos si tiene previsto habilitar la coexistencia:
    • Actualice los requisitos previos a los niveles necesarios para WebSphere Application Server Versión 9.0.

      Las versiones anteriores de WebSphere Application Server siguen ejecutándose con los niveles de requisitos previos más altos.

    • Repase los puertos que se han definido para comprobar que la instalación de WebSphere Application Server Versión 9.0 no entra en conflicto.

      En especial, tenga en cuenta que la definición del puerto de daemon predeterminado para ambas versiones es la misma cuando se realiza la instalación para que coexista con WebSphere Application Server Versión 7.0 o posterior.

      Consulte Asignaciones de puertos determinados para obtener información del puerto predeterminado.

    Consulte Ejecución de servidores de aplicaciones coexistentes para obtener más información.

  • Tenga en cuenta lo siguiente si piensa tener células de releases combinados:
    • Puede actualizar una parte de los nodos de una célula a WebSphere Application Server Versión 9.0 dejando los otros en el nivel de release anterior. Esto significa que durante un determinado período de tiempo, es posible que tenga que administrar en la misma célula servidores que están en el release anterior y servidores que ejecutan el release más reciente.

      En este entorno de releases combinados, pueden existir algunas restricciones en cuanto a las operaciones que se pueden realizar con los servidores del nivel de release anterior. Para obtener información detallada, consulte Creación de servidores de aplicaciones. También pueden existir restricciones para la creación de clústeres y miembros de los clústeres. Para obtener información detallada, consulte Creación de clústeres.

  • La migración de WebSphere Application Server Versión 9.0 convierte los transportes HTTP en cadenas de trasporte de contenedor web de la infraestructura de canales.
    Para obtener más información sobre el soporte de transporte de WebSphere Application Server Versión 9.0, consulte la información:
    • Configuración de cadenas de transporte
    • Valores de canal de transporte HTTP
    • Cadenas de transporte
  • Incluya las consideraciones de mantenimiento cuando desarrolle la estrategia de configuración del sistema de archivos.

    Si configura el entorno de WebSphere Application Server, Network Deployment utilizando el valor predeterminado para la vía de acceso del sistema de archivos del producto en la Herramienta de gestión de migración de z/OS, todos los nodos apuntarán directamente al punto de mensaje del sistema de archivos del producto. Esta configuración hace que sea casi imposible el desarrollo del mantenimiento sin interrupciones. Si se configura una célula de este modo, al dar servicio al sistema de archivos del producto todos los nodos resultan afectados al mismo tiempo. Si se configuran varias células de este modo, al dar servicio al sistema de archivos del producto todas las células resultan afectadas al mismo tiempo.

    Es posible que desee especificar lo que se denomina "un enlace simbólico intermedio" entre el sistema de archivos de configuración de cada nodo y el punto de montaje real del sistema de archivos del producto. Esta estrategia se describe en el documento técnico WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance.

    Consulte el documento técnico Washington Systems Center Sample WebSphere for z/OS ND Configuration para obtener más información sobre este problema y su relación con la aplicación de mantenimiento. Consulte las instrucciones de WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links si desea información sobre cómo obtener y utilizar un programa de utilidad que puede emplear para actualizar un HFS (Sistema de archivo jerárquico) de configuración existente a fin de utilizar enlaces simbólicos intermedios.

  • Las herramientas de migración crean un directorio de copia de seguridad que contiene una copia de seguridad de la configuración de la versión anterior. El espacio disponible para este directorio debe ser al menos el tamaño del directorio de configuración de la versión anterior y las aplicaciones más el tamaño de la salida de los trabajos por lotes de la migración.

    Habitualmente, la salida de trabajos por lotes de la migración es muy pequeña a menos que habilite el rastreo. El tamaño de la salida de rastreo varía dependiendo de las partes de la migración para las que se ha habilitado el rastreo. La fase de migración WASPostUpgrade es la que genera el rastreo de mayor tamaño. Generalmente, verá una salida de rastreo de aproximadamente 30 MB para esta fase.

  • WebSphere Application Server Versión 9.0 no da soporte al proveedor JDBC local de DB2 para zOS (RRS).

    Si utiliza el Proveedor JDBC local de DB2 para zOS (RRS) en la configuración de Versión 7.0 o posterior que va a migrar, debe cambiar la configuración para utilizar el Proveedor de controlador JDBC de DB2 Universal antes o inmediatamente después de migrar a la Versión 9.0. Las herramientas de migración de la Versión 9.0 no migran el proveedor automáticamente.

    Si utiliza el proveedor JDBC local de DB2 para zOS (RRS) en la versión que se debe migrar y no cambia la configuración para utilizar el proveedor de controlador JDBC de DB2 Universal antes de migrar a la Versión 9.0, se producen los sucesos siguientes:
    • Cuando ejecute las herramientas de migración, recibirá el mensaje siguiente:
      MIGR0442W: No se está realizando la migración del proveedor de JDBC local de DB2 para zOS (RRS). 
      Cree manualmente un proveedor de controlador de DB2 Universal como sustitución. Consulte la documentación de DB2 para obtener detalles adicionales. 
    • Después de la migración, se interrumpirá el acceso a DB2 y recibirá el mensaje de tiempo de ejecución siguiente:
      DSRA8213W: El proveedor JDBC local de DB2 para zOS (RRS) ya no está 
      soportado por WebSphere Application Server. Las aplicaciones deben utilizar 
      el proveedor de controlador JDBC de DB2 Universal de tipo 2.
    Si determina que debe cambiar la configuración para utilizar el proveedor de controlador JDBC de DB2 Universal, puede hacerlo realizando una de las tareas siguientes:
    • Antes de migrar a Versión 9.0, cambie la configuración de Versión 7.0 o posterior para utilizar el proveedor de controlador JDBC de DB2 Universal.

      Si realiza esta acción, las herramientas de migración de la Versión 9.0 manejarán la migración al proveedor de controlador JDBC de DB2 Universal y no será necesario ningún ID de actividad posterior a la migración.

      Efectúe una de las acciones siguientes:
      • Cambie manualmente la configuración para utilizar el proveedor de controlador JDBC de DB2 Universal.
      • Si está migrando de Versión 7.0 o posterior, utilice el programa de utilidad de migración de JDBC para DB2 en z/OS para migrar del proveedor JDBC local de DB2 para zOS (RRS) al proveedor de controlador JDBC de DB2 Universal.

        Esta herramienta es un script que migra proveedores JDBC locales de DB2 para zOS (RRS) a proveedores de controlador JDBC de DB2 Universal individualmente para cada nodo. Un documento técnico que acompaña a la herramienta explica cómo instalar y configurar el controlador JDBC de DB2 Universal antes de ejecutar la herramienta para migrar la configuración.

    • Después de la migración a la Versión 9.0, efectúe una de las acciones siguientes:
      • Cambie manualmente la configuración para utilizar el proveedor de controlador JDBC de DB2 Universal.
      • Utilice el Programa de utilidad de migración JDBC para DB2 en z/OS para migrar del proveedor JDBC local de DB2 para zOS (RRS) al proveedor de controlador JDBC de DB2 Universal.

        Esta herramienta es un script que migra proveedores JDBC locales de DB2 para zOS (RRS) a proveedores de controlador JDBC de DB2 Universal individualmente para cada nodo.

  • Después de migrar un servidor de aplicaciones base a WebSphere Application Server Versión 9.0 que se ejecuta en el sistema operativo z/OS, las aplicaciones administrativas y de usuario siguen definiéndose bajo el host virtual default_host como lo hacían en el release anterior. No obstante, un gestor de despliegue migrado se define bajo el host virtual, admin_host, que se ha introducido en la versión 6.1.
  • Si utiliza repositorios de datos aislados, concretamente repositorios de datos no compartidos tales como registros de transacciones para bases de datos SIB y Apache Derby, y realiza la migración desde un release anterior, las bases de datos y registros de transacción existentes se guardan. Si tiene información de vital importancia almacenada en estos repositorios de datos locales, debe apagar todos los servidores que interaccionen con los mismos antes de llevar a cabo la migración. Dichos servidores deben permanecer fuera de línea hasta que la migración haya finalizado por completo o se haya retrotraído correctamente.

    Una vez que haya finalizado la migración o tras haber llevado a cabo la retrotracción a la versión anterior, podrá reiniciar los servidores que interaccionan con dichos repositorios de datos aislados.

  • Antes de migrar una base de datos Apache Derby, asegúrese de que se han cerrado los servidores de aplicaciones que alojan aplicaciones que utilizan la base de datos Apache Derby. De lo contrario, es posible que la migración de Apache Derby dé errores.
  • Debe tener en cuenta las reglas siguientes relacionadas con la migración de dominios de seguridad:
    • Si realiza la migración de un gestor de despliegue que tiene un dominio de seguridad con un ámbito de nivel de célula, las herramientas de migración llevan a cabo estas acciones:
      • La migración crea un dominio en la nueva configuración denominado PassThroughToGlobalSecurity, si todavía no existe.
      • La migración añade una correlación de clústeres a la nueva configuración para todos los clústeres existentes en la configuración anterior.
        • Las correlaciones con PassThroughToGlobalSecurity de los clústeres que antes de la migración sólo existían en la configuración del gestor de despliegue de la Versión 9.0 no presentan cambios.
          • Si las correlaciones de los clústeres de la Versión 9.0 ya existían antes de la migración, seguirán existiendo después de ésta.
          • Si antes de la migración no había ninguna correlación para los clústeres de la Versión 9.0, no habrá ninguna tras finalizar la migración.
        • Si antes de llevar a cabo la migración un clúster existe tanto en la configuración anterior como en la configuración de la Versión 9.0, el clúster de la nueva configuración se añade al dominio PassThroughToGlobalSecurity y se comporta como el clúster del release anterior.
      • La migración añade una correlación de buses para los buses existentes en una configuración migrada de la versión 6.1.x.

        Las correlaciones de buses se actualizan siguiendo las mismas reglas que se utilizan para las correlaciones de clústeres.

      • Los servidores administrativos (gestor de despliegue) no se añaden al dominio PassThroughToGlobalSecurity.
    • Si realiza la migración de un nodo federado que tiene un dominio de seguridad con un ámbito de nivel de célula, las herramientas de migración llevan a cabo estas acciones:
      • La migración crea un dominio en la nueva configuración denominado PassThroughToGlobalSecurity, si todavía no existe.
      • La migración añade una correlación de nivel de servidor al dominio PassThroughToGlobalSecurity para todos los servidores que no tienen clústeres de la configuración del nodo anterior.
        • Los servidores del nodo que se migran que forman parte de un clúster no reciben las entradas en el dominio PassThroughToGlobalSecurity porque esto se lleva a cabo a través de una correlación de clústeres durante la migración del gestor de despliegue.

          Si ha eliminado dicha correlación, la migración mantiene el comportamiento.

        • Los servidores administrativos (agentes de nodo) no se añaden al dominio PassThroughToGlobalSecurity.

    Para obtener más información, consulte la sección "Dominios de seguridad en un entorno de versiones mixtas" de Varios dominios de seguridad.

  • Si ha actualizado el archivo java.security en la versión anterior de WebSphere Application Server, asegúrese de que las actualizaciones estén ubicadas en el archivo java.security migrado, que se encuentra en V8WAS_HOME/properties/java.security.
  • Después de utilizar las herramientas de migración para realizar la migración a la WebSphere Application Server Versión 9.0, es posible que tenga que llevar a cabo algunas acciones que las herramientas de migración no efectúan automáticamente.
    • Examine los valores de seguridad LTPA (Lightweight Third-Party Authentication) que pueda haber utilizado en WebSphere Application Server Versión 7.0 o posterior y asegúrese de que la seguridad de la Versión 9.0 se haya establecido correctamente.

      Consulte Lightweight Third Party Authentication para obtener más información.

    • Si es necesario, cree nuevos perfiles SAF (System Authorization Facility) antes de iniciar los servidores migrados en WebSphere Application Server Versión 9.0.
      A partir de la versión 6.1, determinadas características de seguridad se controlan mediante perfiles SAF.
      • En Versión 7.0 o posterior, el valor Habilitación de aplicaciones de confianza se controla con un perfil de seguridad SAF en lugar de controlarse con una variable de WebSphere interna como en los releases anteriores.

        La opción Habilitación de aplicaciones de confianza, que permite que el tiempo de ejecución de WebSphere Application Server realice determinadas operaciones privilegiadas en nombre del código de la aplicación, es necesaria para todos los servidores que utilizan el registro de sistema operativo local (LocalOS) o la autorización SAF.

      • En Versión 7.0 o posterior, la función de Permiso de sincronización con la hebra del sistema operativo (que permite que una aplicación acceda a los recursos utilizando una identidad del sistema operativo que no sea la identidad del servidor) se controla mediante un perfil de seguridad SAF y la variable com.ibm.websphere.security.SyncToOSThread.

        Esta implementación permite tanto al administrador como al administrador de seguridad del sistema determinar si se utiliza o no la característica. Esta implementación permite también restringir las identidades que puede asumir la aplicación.

      Si realiza la migración desde una versión anterior de WebSphere Application Server y necesita estas características, debe crear los perfiles SAF necesarios. Si estos perfiles no existen o no se han configurado correctamente, una célula que utilice el registro de usuario LocalOS o la autorización SAF fallará cuando se inicie en la Versión 9.0.

      Si utiliza RACF (Resource Access Control Facility) para el sistema de seguridad, siga las instrucciones siguientes. Si utiliza otro sistema de seguridad compatible con SAF, póngase en contacto con el proveedor del sistema de seguridad para obtener la información adecuada.
      • Compruebe las anotaciones cronológicas del sistema MVS (Multiple Virtual Storage) o utilice la consola administrativa para determinar si se ha habilitado Habilitar aplicaciones de confianza para el servidor.
        Busque control_region_security_enable_trusted_applications en las anotaciones cronológicas de inicio. Si este valor se establece en 1, Habilitación de aplicaciones de confianza se habilita. Si esta opción está habilitada, cree el siguiente perfil SAF y conceda acceso READ al ID de usuario de la región de control del servidor de aplicaciones:
        BBO.TRUSTEDAPPS.nombre_corto_célula.nombre_transición_clúster 
        Utilice los siguientes mandatos RACF para completar esta acción:
        RDEFINE FACILITY
          BBO.TRUSTEDAPPS.nombre_corto_célula.nombre_transición_clúster 
          UACC(NONE)
        PERMIT FACILITY
          BBO.TRUSTEDAPPS.nombre_corto_célula.nombre_transición_clúster 
          ID(ID_usuario_controlador) ACCESS(READ)
        SETROPTS RACLIST(FACILITY) REFRESH

        El perfil del recurso SAF nombre_clúster se sustituye por el nombre de transición de clúster para los servidores que no están agrupados en clúster. Si desea que todos los servidores de la célula tengan activada la opción Habilitación de aplicaciones de confianza, sustituya el nombre del clúster por un comodín (*).

        Para obtener más información, consulte Clases y perfiles de System Authorization Facility.

      • Compruebe las anotaciones cronológicas del sistema MVS (Multiple Virtual Storage) o utilice la consola administrativa para determinar si se ha habilitado Sincronización con la hebra del sistema operativo permitida para el servidor.
        Si esta opción está habilitada, cree el siguiente perfil SAF y conceda acceso READ o acceso CONTROL al ID de usuario de la región de control del servidor de aplicaciones:
        BBO.SYNC.nombre_corto_célula.nombre_transición_clúster
        El ejemplo siguiente contiene mandatos RACF que puede utilizar para realizar esta acción:
        RDEFINE FACILITY
          BBO.SYNC.nombre_corto_célula.nombre_transición_clúster
          UACC(NONE) 
        PERMIT FACILITY 
        BBO.SYNC.nombre_corto_célula.nombre_transición_clúster
          ID(ID_usuario_controlador) ACCESS(CONTROL)
        SETROPTS RACLIST(FACILITY) REFRESH

        El nombre del clúster se sustituye por el nombre de transición del clúster para servidores que no están agrupados en clúster. Si desea que todos los servidores de la célula tengan habilitada la opción Sincronización con la hebra del sistema operativo permitida, sustituya el nombre del clúster por un comodín (*).

        Importante:
        • Al conceder acceso READ a la región de control al ID de usuario de la región de control del servidor de aplicaciones se limitan los ID de usuario en los que puede modificarse la identidad de la hebra basándose en los perfiles SURROGAT de SAF.

          Si el ID de usuario del controlador tiene acceso READ al perfil BBO.SYNC y se ha establecido la variable com.ibm.websphere.security.SyncToOSThread en true, una aplicación puede solicitar la sincronización con la hebra del sistema operativo. Es posible que la aplicación tome la identidad de quien realiza la llamada o un ID de usuario relacionado con el rol para acceder a los recursos. Sin embargo, para que el servant se ejecute con un ID de aplicación diferente, el servant necesita acceso de lectura (READ) al perfil de SURROGAT BBO.SYNC.id_usuario_aplicación.

        • Si se concede acceso CONTROL a la región de control al ID de usuario de la región de control del servidor de aplicaciones, se puede cambiar la identidad de la hebra a cualquier ID de usuario que solicite la sincronización con la hebra del sistema operativo.

          Si el ID de usuario del controlador tiene acceso CONTROL al perfil BBO.SYNC y se establece la variable com.ibm.websphere.security.SyncToOSThread en true, una aplicación puede solicitar la sincronización con la hebra del sistema operativo. La aplicación puede asumir la identidad del ID de usuario que realiza la llamada o de ID de usuario de un rol relacionado para acceder a los recursos. Los perfiles SURROGAT no se comprueban.

        Para obtener más información, consulte Permiso de sincronización con la hebra de OS de la aplicación.

    • Si utiliza perfiles EJBROLE de SAF para la autorización basada en roles, cree perfiles EJBROLE para los dos roles administrativos, el rol de desplegador y el rol de gestor de seguridad de admin, que se han introducido en la Versión 6.1.
    • Revise los valores de la máquina virtual Java (JVM) para comprobar que está utilizando un tamaño de almacenamiento dinámico de 50 como mínimo para mejorar el rendimiento de arranque.

      Si desea más información, consulte el artículo "Valores de la máquina virtual Java" en la documentación.

      Si ha utilizado un tamaño de almacenamiento dinámico anteriormente, puede utilizar el tamaño de almacenamiento dinámico predeterminado, que es 50.

    • Verifique el resultado de la migración de la base de datos Apache Derby y migrar manualmente todas las bases de datos Apache Derby que las herramientas no han migrado de forma automática.

      Consulte Migración de bases de datos de Apache Derby para obtener más información.

    • Si dispone de diversos agentes de nodo en la misma partición lógica (LPAR), pueden producirse conflictos de puerto IPC_CONNECTOR_ADDRESS después de ejecutar los trabajos de migración. Vuelva a configurar los puertos en conflicto.
    • Si tiene aplicaciones que intentan enviar una solicitud a un URI (Uniform Resource Identifier - identificador universal de recursos) de SIP (Protocolo de iniciación de sesión) a través de TLS (Transport Layer Security - seguridad de la capa de transporte), debería fijarse en una diferencia en cuanto al comportamiento entre la versión 6.1 y la Versión 9.0de WebSphere Application Server.

      Cuando una aplicación SIP envía una solicitud a un URI de SIP a través de TLS en la versión 6.1, el esquema del URI de la solicitud cambia de "sip" a "sips". En Versión 9.0, el esquema se mantiene sin cambios.

      Esta diferencia se observa cuando las aplicaciones intentan enviar una solicitud SIP en la que el URI de la solicitud contiene un esquema "sip" y un parámetro de transporte "tls". Por ejemplo, si una aplicación de la versión 6.1 crea una solicitud con el URI de solicitud siguiente:
      sip:alice@atlanta.com;transport=tls
      y lo envía a la red, el contenedor SIP cambia tanto el esquema como el parámetro de transporte para generar el siguiente URI de solicitud:
      sips:alice@atlanta.com;transport=tcp
      En la Versión 9.0, el contenedor SIP no cambia el esquema.

      Si desea conservar el comportamiento anterior después de realizar una migración del servidor de aplicaciones de la versión 6.1 a la Versión 9.0, cambie el código de la aplicación. Si la aplicación pretende enviar un URI "sips", deberá crear el URI de esa forma antes de enviar el mensaje. Con un URI "'sips", el comportamiento sigue siendo el mismo que en la versión 6.1.


Icon that indicates the type of topic Concept topic



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