Solución de problemas en Host Integration Server advertencias del evento 23

Este artículo presenta las advertencias del evento 23 en Microsoft Host Integration Server (HIS) 2010 y HIS 2009.

Versión del producto original:   Host Integration Server 2010, Adaptadores de BizTalk para sistemas host 2.0
Número KB original:   2824716

Resumen

Al configurar un HIS para conectarse a un sistema de ibm mainframe o iSeries (AS/400), se instalan y configuran uno o varios servicios de vínculo. Los servicios de vínculo proporcionan el vínculo de comunicación entre el servicio de servidor SNA y los controladores de dispositivo, para admitir la comunicación de SNA a través de los distintos tipos de vínculos.

Una vez instalados y configurados los servicios de vínculo, debe definir las conexiones de host reales a través de las cuales el servicio de servidor SNA se comunicará con los sistemas host de IBM para tener acceso a las aplicaciones empresariales. Las conexiones definidas en la configuración HIS proporcionan la conexión de nivel de vínculo SNA que se usa para comunicarse con el sistema host de IBM.

Si el servicio de vínculos subyacente detecta un problema con el vínculo físico al sistema host de IBM, se genera un código de interrupción. Este código de interrupción se devuelve al servicio de servidor SNA. Cuando se le notifica que se ha producido una interrupción en la conexión, el servicio de servidor SNA realiza las siguientes acciones:

  • Registra una advertencia de evento 23 en el registro de eventos de la aplicación
  • Limpia las sesiones de SNA activas en la conexión afectada.
  • Emite un mensaje de solicitud Close(LINK) al servicio de vínculos para cerrar la conexión

Cuando se produce una interrupción de la conexión, todas las sesiones de SNA (LUs) activas definidas en esta conexión se cierran, lo que significa que los usuarios finales pierden su conectividad con las aplicaciones IBM back-end con las que estaban interactuando.

Detalles de advertencia del evento 23

El evento 23 indica que se ha fallado una conexión de host. Los detalles incluidos en el mensaje de evento proporcionan más detalles sobre el motivo del error. El formato del mensaje de evento se muestra aquí:

Identificador de evento: 23
Origen: Servidor SNA
Descripción: Conexión de error de conexión = nombre de conexión
Link Service = link service name
Calificador = código de interrupción

Explicación
Un servicio de vínculos ha notificado un error de conexión al nodo. Vea a continuación para obtener más información sobre el código de interrupción que provocó un error en la conexión.

TOKEN RING, ETHERNET O FDDI

0029

El sistema remoto no responde al intento Host Integration Server equipo de activar una conexión SNA.

  • 00AE

    La conexión ha fallado debido a un tiempo de espera de conexión, debido a una respuesta lenta del sistema remoto, o el sistema remoto ha desactivado la conexión enviando Host Integration Server servicio SNA un marco DISC (connect) o DM.

    Si se sospecha que la respuesta del sistema remoto es lenta, Host Integration Server la conexión T1 y los temporizadores ti del SNA deben aumentarse.

    Si se conecta a un AS/400 y no hay sesiones de usuario activas, el AS/400 quitará la conexión si la configuración Desconexión conmutada del controlador AS/400 APPC está establecida en .

    Para aislar el problema, se debe usar un seguimiento de Monitor de red (o una utilidad similar) para capturar una aparición del error.

  • 00AF

    Se ha perdido la conexión al sistema remoto. Esto puede ocurrir debido a un error multimedia en la LAN, un error de un puente intermedio o enrutador, o si el sistema remoto ha dejado de responder.

  • 00AC

    El Windows DLC de NT ha detectado un error de protocolo DLC en un fotograma recibido por el sistema remoto y ha enviado un rechazo de fotogramas (FRMR) que hace que la conexión finalice. El evento 228 debe registrarse cuando se produzca este error. Vea el código FRMR en el evento 228 para obtener más información que describa por qué se produjo el FRMR.

  • 00AD

    El sistema remoto ha detectado un error de protocolo DLC en un marco enviado por Windows NT y ha enviado un FRMR que hace que la conexión finalice. El evento 227 debe registrarse cuando se produzca este error.

Nota

Relacionados con los servicios de vínculos IP-DLC: las conexiones que usan un servicio de vínculos IP-DLC también registra advertencias de eventos cuando se produce un error en la conexión. En estos casos, los dos códigos de interrupción que se pueden registrar son 0029 y 00AE que tienen básicamente el mismo significado que para las conexiones que usan un servicio de vínculo DLC 802.2. En el caso de una interrupción de 00AE para IP-DLC, la información relativa a los temporizadores t1 y TI DLC no se aplica, ya que se trata de configuraciones específicas de DLC.

El mensaje Evento 23 cuando se ve en el registro de eventos de aplicación también incluye códigos de interrupción para los servicios de vínculo SDLC. Aquí no se analizan las interrupciones de SDLC porque el uso de los servicios de vínculo SDLC es poco común.

Solución de problemas de conexión del evento 23

En general, Host Integration Server errores de conexión que dan como resultado el registro de advertencias del evento 23 se producen debido a condiciones externas al sistema HIS Server. Por lo tanto, los pasos de solución de problemas normalmente requieren acciones que se deben realizar de forma externa al HIS server.

Las interrupciones de conexión del evento 23 son más comunes en entornos Host Integration Server que usan el servicio de vínculo DLC 802.2 para conectarse a sistemas host de IBM a través del protocolo DLC. Antes había un número razonable de interrupciones de conexión de Eventos 23 con entornos de servidor SNA y Host Integration Server con servicios de vínculos SDLC o X.25, pero el uso de los protocolos SDLC y X.25 es poco frecuente en estos días. El uso de los servicios de vínculos IP-DLC está creciendo rápidamente, pero no vemos que las advertencias del evento 23 se registran con tanta frecuencia en estos entornos. El servicio de vínculos IP-DLC registra varios de sus propios mensajes de evento específicos cuando tiene problemas con las conexiones TCP/IP subyacentes que usa para la comunicación. Es probable que se produzca un evento 23 para una interrupción extendida que impida que el servicio de vínculos IP-DLC establezca sus sesiones TCP/IP necesarias en el servidor de nodos de red (NNS).

Para entornos de Host Integration Server que usan servicios de vínculos DLC e IP-DLC de 802.2, se requieren los siguientes seguimientos para ayudar a determinar la causa raíz de los errores de conexión que provocan el registro de advertencias del evento 23:

  • Host Integration Server seguimientos

    Estos seguimientos se capturan mediante la Utilidad de seguimiento de SNA (snatrace.exe).

  • Seguimientos de red

    Las utilidades de captura de red como Network Monitor, Wireshark, Ethereal son comunes.

La idea básica es habilitar el HIS y los seguimientos de red antes de un error de conexión. Una vez que se produce un error de conexión, deberá detener los seguimientos lo antes posible para evitar que se sobrescriban los datos de seguimiento que contiene el error.

Host Integration Server seguimientos

Los siguientes pasos describen los Host Integration Server seguimientos que se capturarán para una interrupción de la conexión:

  1. Ejecute snatrace.exe.

  2. Seleccione la pestaña Propiedades globales de seguimiento.

  3. Cambie el valor de longitud de giro de archivo de seguimiento (bytes) de 20000000 a 200000000 (agregue un 0 a la longitud predeterminada).

  4. Habilite la opción Permitir HIS administradores para realizar el seguimiento.

  5. Seleccione Aplicar.

  6. Seleccione la pestaña Elementos de seguimiento.

  7. Resalte el nombre del servicio de vínculo (SNAIP1, SNADLC1, etc.) especificado en la advertencia del evento 23 y, a continuación, seleccione Propiedades.

  8. Seleccione la pestaña Seguimiento de mensajes.

  9. Habilitar mensajes de nivel 2 y, a continuación, seleccionar Aceptar.

  10. Resalte el servidor SNA en la lista de elementos de seguimiento y seleccione Propiedades.

  11. Seleccione la pestaña Seguimiento de mensajes.

  12. Habilitar control de vínculo de datos y, a continuación, seleccione Aceptar.

  13. Puede minimizar la Utilidad de seguimiento de SNA en este momento a medida que se habilitan los seguimientos.

    Nota

    Si cierra la Utilidad de seguimiento de SNA, se le pedirá un cuadro de diálogo de advertencia que indica que dejar los seguimientos habilitados puede afectar al rendimiento del servidor. Puede seleccionar Aceptar y cerrar la ventana si lo desea.

  14. Una vez que se produzca el error de conexión, restaure (o vuelva a abrir) la ventana utilidad de seguimiento SNA y seleccione el botón Borrar todos los seguimientos para desactivar el seguimiento. Desea hacerlo lo antes posible porque los HIS se escriben en archivos de seguimiento circulares. Los datos se sobrescribirán si los seguimientos siguen en ejecución. En los servidores ocupados, los seguimientos se pueden ajustar rápidamente.

Seguimientos de red

Los pasos para habilitar un seguimiento de red dependen de la utilidad de captura de red que elija usar. Por lo tanto, los pasos de captura de red específicos no se incluyen aquí. En su lugar, se proporciona una introducción a lo que deben ser capturas:

  1. La captura de red debe incluir los datos que fluyen entre el sistema Host Integration Server y el sistema host de IBM (mainframe o iSeries). Si usas el servicio de vínculos DLC 802.2, quieres capturar el tráfico de red DLC. Si hay varios adaptadores de red en el sistema Host Integration Server, debe asegurarse de que la utilidad de captura de red esté rastreando el adaptador de red correcto si el seguimiento de red se está capturando en el sistema Host Integration Server red.

    Puede configurar un filtro para limitar la cantidad de tráfico que se captura. Si usa un filtro, una opción es capturar todo el tráfico de red a/desde la dirección MAC (si usa DLC) o la dirección TCP/IP (si usa IP-DLC) del sistema host remoto de IBM.

    El riesgo con el uso de filtros es que es posible que el filtro no capture algún tráfico que sea relevante para los problemas de conexión. Esto es más probable que se produzca con conexiones TCP/IP. Un filtro puede perderse los fotogramas de redireccionamiento ICMP o destino inaccesibles. Estos tipos de fotogramas pueden producirse cuando la ruta de acceso de red entre el servidor HIS y el sistema host de IBM tiene un problema o cuando un enrutador entre no tiene la configuración correcta o ha perdido conectividad.

    Estos tipos de fotogramas se envían desde una dirección TCP/IP diferente (por ejemplo, la dirección del enrutador) y pueden perderse al usar una configuración de filtro con una dirección TCP/IP de HIS y una dirección TCP/IP del sistema host de IBM.

  2. Si el sistema Host Integration Server y el sistema host de IBM están separados entre una WAN (por ejemplo, enrutadores, conmutadores, puentes entre los sistemas), la recomendación es realizar seguimientos simultáneos de red al menos en el segmento de red de Host Integration Server y el segmento de red del sistema host de IBM. Esto proporciona visibilidad del tráfico de red en cada segmento de red. Esto le permite ver si los paquetes de red se están realizando a través de la WAN. Tener un seguimiento de red en un solo segmento de red no proporciona una imagen completa porque no se puede determinar con certeza si un paquete que falta llegó al otro segmento de red o si se perdió una respuesta al volver.

  3. Si los errores de conexión son aleatorios, es posible que los seguimientos deba ejecutarse durante un período prolongado. En estos casos, es posible que desee configurar la utilidad de captura de red para guardar los seguimientos de red a determinados intervalos en caso de que los seguimientos no se puedan detener inmediatamente cuando se produzca una interrupción. Esto ayuda a asegurarse de que se capturan los datos relevantes.

  4. Cuando se produce un error de conexión, desea detener y guardar el seguimiento de red tan pronto como sea posible.

Análisis de seguimiento

El Host Integration Server de soporte técnico usa los datos de seguimiento resultantes para aislar la causa raíz de los errores de conexión. En la mayoría de los casos, el problema se debe a una de las siguientes causas:

  • Problema de configuración

    • Direcciones de red incorrectas
    • Puntos de acceso de servicio (SAP) incorrectos
    • Configuración incorrecta del firewall (IP-DLC)
  • Problemas de red

    • Problemas transitorios de red
    • Problemas del router/Switch/Packet Shaper
  • Interrupciones del sistema host de IBM

    • Ventanas de mantenimiento normal
    • Interrupciones inesperadas en sistemas mainframe o iSeries

Por lo general, los seguimientos de red son las principales herramientas de solución de problemas para estos tipos de problemas, ya que normalmente son externos a Host Integration Server. Los HIS de datos son útiles para ver el flujo de datos previo a la interrupción. Los seguimientos de mensajes de nivel 2 del servicio de vínculo también incluyen códigos de devolución de DLC (para servicios de vínculos DLC 802.2) que también pueden ser útiles.

  • Para los errores de conexión DLC 802.2, el código de interrupción del evento 23 te indica por qué se ha eliminado la conexión. Si hace referencia a las descripciones de interrupción específicas anteriores, verá una idea sobre qué buscar en los seguimientos.

    Los seguimientos ayudan a comprobar o probar la causa subyacente como se indica en el código de interrupción.

    Por ejemplo, un código de interrupción de 0029 (sistema remoto que no responde) suele indicar que el servicio de vínculo DLC 802.2 no está obteniendo una respuesta a los comandos DLC TEST o XID que envía al sistema remoto para establecer la conexión DLC. En estos casos, también debería ver una advertencia de evento 230 registrada en el registro de eventos de aplicación que indica si el problema se produce debido a un comando TEST o XID. Los seguimientos de red en este caso se usan para comprobar que el servicio de vínculo DLC 802.2 envía el comando TEST o XID en el cable. Si se capturaron seguimientos de red simultáneos, puede ver si los comandos TEST o XID alcanzaron el segmento de red remota. Si es así, debería ver una respuesta TEST o XID que se envía de vuelta. Si ve la respuesta en el seguimiento de red remoto, pero no en el otro seguimiento de red, los paquetes se descartaron o se perdieron al atravesar la WAN. En este momento, la solución de problemas continúa con el equipo de soporte técnico de red.

  • Para los códigos de interrupción que indican un rechazo de fotograma (FRMR) que se envía o recibe, buscaría a través del seguimiento de red el FRMR y, a continuación, trabajaría hacia atrás para ver la secuencia que llevó al rechazo de fotogramas que se envió. En estos casos, las causas típicas son los fotogramas DLC que se envían fuera de secuencia, números de secuencia incorrectos, tamaño de fotograma DLC incorrecto. Los detalles adicionales se incluirán en una advertencia de evento 227 correspondiente, que incluye un código de rechazo de fotograma que especifica el motivo por el que se envió el rechazo del marco.