Compartir a través de

Encadenamiento de entrada

  • Artículo

La división de los datos de la aplicación en mensajes Data 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 de la sesión es un parámetro de la solicitud BIND del host y está disponible en el bloque de control de información de enlace (BICB) del mensaje Open(PLU) OK Confirm. La aplicación debe asegurarse de que cada mensaje de datos de entrada se corresponda con una sola unidad de solicitud. No contiene más datos que el tamaño máximo de la unidad de solicitud especificado en el bloque BICB.

La aplicación debe usar las marcas de aplicación del indicador de cadena de inicio (BCI) y del indicador de cadena final (ECI) de 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 maneras siguientes:

  • La cadena completa se envía sin errores. Todos los mensajes Data de la cadena se han pasado al host. Si la sesión permite que el secundario envíe cadenas de respuesta definitiva y la aplicación establece el campo ACKRQD en el último mensaje Data de la cadena, la aplicación recibirá un mensaje 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 mensaje Status-Acknowledge(Nack-2) que contiene un código de error y cierra la conexión PLU. Tenga en cuenta que el nodo local generará una solicitud CANCEL antes de cerrar la conexión PLU. El nodo local enviará una solicitud TERM-SELF al host para obtener una solicitud UNBIND.

  • El host envía una respuesta negativa a una solicitud de la cadena. El nodo local envía un mensaje Status-Acknowledge(Nack-1) a la aplicación con los códigos de detección 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 bloque CICB de PLU, el nodo local también generará 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 de entrada posteriores se rechazan con un mensaje Status-Acknowledge(Nack-2) no crítico, o bien con un código 0x2002 o 0x2004 (encadenamiento o dirección). Cuando la aplicación recibe el mensaje Status-Acknowledge(Nack-1) , esta debe dejar de enviar datos después de esta cadena para las sesiones de dirección de biestable de dúplex medio, ya que la dirección ha pasado al host. (Para obtener más información, consulte Dirección).

  • La aplicación cancela la cadena durante el envío, mediante el envío de un mensaje Status-Control(CANCEL) al nodo local. El nodo local envía una solicitud CANCEL al host y 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 para la aplicación si los mensajes Data originales tenían establecido el campo ACKRQD.

  • La aplicación cierra la conexión PLU mientras se envía la cadena. El nodo local envía una solicitud Close(PLU) Response a la aplicación. Las respuestas del host a las solicitudes enviadas antes del mensaje Close(PLU) no generarán mensajes Status-Acknowledge para la aplicación. Tenga en cuenta que el nodo local también generará una solicitud CANCEL entrante y una solicitud TERM-SELF para generar un mensaje 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 cerrará la conexión PLU. En su lugar, rechaza el mensaje Data del error con una confirmación 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 use protocolos semidúplex, la aplicación deberá asumir un estado de recepción. (Para obtener más información, consulte Recuperación).

    Las seis imágenes siguientes ilustran 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 imagen, 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 la dirección al host.

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

    En la imagen 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 una solicitud 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 la solicitud CANCEL si el perfil de administración de funciones (FM) de la sesión admite CANCEL.

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

    En la imagen siguiente, se envía una cadena de entrada completa sin errores, pero el host la rechaza. Después de la respuesta negativa, la aplicación debe entrar en estado de recepción, a la espera de recuperarse del error. (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 la rechaza.

    En la imagen siguiente, la aplicación cancela la cadena enviando Status-Control(CANCEL) . Tenga en cuenta que la aplicación todavía tiene direcció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 mensaje Status-Control(CANCEL)

    En la siguiente imagen, la aplicación cierra la sesión PLU mientras se envía la cadena. El nodo local solo genera la solicitud 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 al enviar la cadena.

    En la imagen siguiente, el nodo local detecta un error no crítico en el formato del segundo mensaje Data de la cadena y envía un mensaje 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 mensaje Status-Acknowledge(Nack-2)

Consulte también

Apertura de la conexión de PLU
Sesión de PLU
Encadenamiento de salida
Entrega de segmentos
Brackets
Dirección
Velocidad y fragmentació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