Encadenamiento de entrada

La división de los datos de la aplicación en mensajes de datos y el control del encadenamiento de entrada son responsabilidad de la aplicación.

El tamaño máximo de la unidad de solicitud de envío secundario para la sesión es un parámetro en el BIND desde el host y está disponible en el bloque de control de información de enlace (BICB) en el mensaje Open(PLU) OK Confirm. La aplicación debe asegurarse de que cada mensaje de datos entrante corresponde a una sola unidad de solicitud. No contiene más datos que el tamaño máximo de la unidad de solicitud dado en el BICB.

La aplicación debe usar las marcas de aplicación del indicador de cadena inicial (BCI) y del indicador de cadena final (ECI) en los encabezados de mensaje de datos para controlar el encadenamiento. (Para obtener más información, consulte Marcas de aplicación). La cadena es la unidad de recuperación y, si se producen errores recuperables en la cadena, la aplicación debe asumir la responsabilidad de la recuperación. (Para obtener más información, consulte Recuperación).

Una cadena de entrada puede finalizar de las siguientes maneras:

  • La cadena completa se envía sin errores. Todos los mensajes de datos de la cadena se han pasado al host. Si la sesión permite que la secundaria envíe cadenas de respuesta definitiva y la aplicación establece el campo ACKRQD en el último mensaje De datos de la cadena, la aplicación recibe un Status-Acknowledge(Ack) del nodo local cuando el host proporciona una respuesta.

  • El nodo local detecta un error crítico en el formato de un mensaje Data de la aplicación o en el estado de la sesión. El nodo local rechaza el mensaje Data con un Status-Acknowledge (Nack-2) que incluye un código de error y cierra la conexión de la PLU. Tenga en cuenta que el nodo local generará una solicitud CANCEL entrante antes de cerrar la conexión PLU. El nodo local enviará una solicitud TERM-SELF al host para provocar un UNBIND.

  • El host envía una respuesta negativa a una solicitud en la cadena. El nodo local envía un mensaje Status-Acknowledge(Nack-1) a la aplicación con los códigos de sentido y el número de secuencia de la respuesta negativa. Si el host rechaza una solicitud que no lleva la marca de aplicación ECI y la aplicación no especifica la opción de cancelación de la aplicación en el CICB de PLU, el nodo local también genera una solicitud CANCEL entrante. Cuando la aplicación especifica la cancelación de la aplicación, debe enviar EC o Status-Control(CANCEL) para finalizar la cadena. Las cadenas entrantes posteriores se rechazan con un Status-Acknowledge(Nack-2) no crítico, código de detección 0x2002 o 0x2004 (encadenamiento o dirección). Cuando la aplicación recibe el mensaje Status-Acknowledge(Nack-1), debe dejar de enviar datos después de esta cadena para sesiones de semidúplex flip-flop porque la dirección ha pasado al host. (Para obtener más información, vea Dirección).

  • La aplicación cancela la cadena mientras se envía mediante el envío de un mensaje Status-Control(CANCEL) al nodo local. El nodo local envía una solicitud CANCEL al host y envía una confirmación Status-Control(CANCEL) a la aplicación al recibir una respuesta positiva del host. Las respuestas del host a las solicitudes enviadas antes de CANCEL generarán los mensajes Status-Acknowledge adecuados a la aplicación si los mensajes Data originales tenían establecido el campo ACKRQD.

  • La aplicación cierra la conexión PLU mientras envía la cadena. El nodo local envía una respuesta Close(PLU) a la aplicación. Las respuestas del host a las solicitudes enviadas antes del mensaje Close(PLU) no generarán mensajes Status-Acknowledge a la aplicación. Tenga en cuenta que el nodo local también generará una solicitud CANCEL entrante y una solicitud TERM-SELF para elicir un UNBIND.

    Si el nodo local detecta un error no crítico en el formato de un mensaje data de la aplicación o el estado de la sesión, no cierra la conexión PLU. En su lugar, rechaza por error el mensaje Data mediante un Status-Acknowledge(Nack-2) que contiene un código de error adecuado. No se envía ningún dato al host.

    Si una cadena de entrada finaliza con un error, cuando la sesión usa protocolos dúplex medio, la aplicación debe asumir un estado de recepción. (Para obtener más información, consulte Recuperación).

    En las seis cifras siguientes se muestran los protocolos de encadenamiento de entrada entre el nodo local y la aplicación, y cómo se relacionan esos protocolos con los protocolos SNA subyacentes.

    En la primera ilustración, el host envía una cadena de entrada completa sin errores y la acepta. Tenga en cuenta que después de recibir Status-Acknowledge(Ack) la aplicación cede el control al host.

    Imagen que muestra una cadena de entrada se envía sin errores y el host lo acepta.
    La cadena de entrada se envía sin errores y el host lo acepta.

    En la ilustración siguiente, el nodo local detecta un error crítico en el formato del segundo mensaje Data de la cadena (ACKRQD sin la marca de aplicación ECI), envía un status-Acknowledge(Nack-2) a la aplicación con el código de error adecuado y cierra la conexión PLU. Tenga en cuenta que el nodo local solo genera el cancel si el perfil de administración de funciones de la sesión (FM) admite CANCEL.

    Imagen que muestra cómo un nodo local detecta errores, envía un mensaje de estado y cierra la conexión PLU.
    El nodo local detecta un error, envía un mensaje de estado y cierra la conexión PLU.

    En la figura siguiente, se envía una cadena de entrada completa sin errores, pero el anfitrión la rechaza. Después de la respuesta negativa, la aplicación debe entrar en el estado de recepción, mientras espera la recuperación de errores. (Para obtener más información, consulte Recuperación).

    Imagen que muestra cómo se envía una cadena de entrada sin errores, pero que el host rechaza.
    La cadena de entrada se envía sin errores, pero el host lo rechaza.

    En la ilustración siguiente, la aplicación cancela la cadena enviando Status-Control(CANCEL). Tenga en cuenta que la aplicación aún tiene orientación y puede iniciar una nueva cadena.

    Imagen que muestra cómo una aplicación cancela la cadena con un Status-Control(CANCEL).
    La aplicación cancela la cadena con un Status-Control(CANCEL)

    En la ilustración siguiente, la aplicación cierra la sesión de PLU mientras envía la cadena. El nodo local solo genera el CANCEL si el perfil FM de la sesión admite CANCEL.

    Imagen que muestra cómo una aplicación cierra la conexión PLU al enviar la cadena.
    La aplicación cierra la conexión PLU mientras se envía la cadena

    En la ilustración siguiente, el nodo local detecta un error no crítico en el formato del segundo mensaje Data de la cadena y envía un Status-Acknowledge(Nack-2) a la aplicación con el código de error adecuado.

    Imagen que muestra cómo un nodo local detecta un error no crítico y envía un status-Acknowledge(Nack-2).
    El nodo local detecta un error no crítico y envía un Status-Acknowledge(Nack-2)

Véase también

Apertura de la conexión PLU
Sesión de PLU
Encadenamiento saliente
Entrega de segmentos
Brackets
Direction
Ritmo y segmentación
Confirmación y rechazo de datos]
Apagado y modo inactivo
Recuperación
Terminación Iniciada por la Aplicación
LUSTATs]
Datos del monitor de tiempo de respuesta

  • Last updated on