Datos de salida
En esta sección se describen los flujos de datos salientes desde el nodo local a la aplicación. La estructura general de los protocolos descritos se aplica a las conexiones del punto de control de servicios del sistema (SSCP) y de la unidad lógica principal (PLU), pero ciertas características (como el uso del modo de solicitud retrasada) solo son aplicables a la conexión PLU.
El nodo local presenta los datos que se originan en el host a la aplicación en diferentes conexiones, en función de la sesión de SNA en la que fluyen los datos, como se muestra a continuación:
Los datos de servicios de red de datos de administración de funciones (FMD NS) (servicios de sesión) y los datos de administración de funciones (FMD) que se originan en el SSCP del host y se dirigen a la unidad lógica (LU) de Host Integration Server se envían a la aplicación en la conexión SSCP.
Los datos de FMD que se originan en la PLU del host y se dirigen a una LU del servidor de SNA se envían a la aplicación en la conexión de la PLU.
Para todas las conexiones, solo las solicitudes de FMD se presentan a la aplicación como mensajes Data (con tipo de mensaje = DATAFMI). Las solicitudes de control de sesión y DFC se usan para generar mensajes Status-Control. (Para obtener más información, vea Mensaje Status-Control).
El nodo local realiza los cambios en el estado de control del flujo de datos requeridos por los indicadores del encabezado de respuesta (RH) en la solicitud, antes de enviar un mensaje Data a la aplicación.
Los indicadores del encabezado de transmisión (TH) y RH de la solicitud SNA no están disponibles en los mensajes Data de salida. En su lugar, el nodo local proporciona marcas de aplicación en el encabezado de mensaje Data que reflejan la configuración de un subconjunto de los indicadores RH, pero son interpretadas por el nodo local para blindar la aplicación ante los aspectos más oscuros del encadenamiento y el uso de corchetes. Para obtener una descripción de las marcas disponibles y la forma en que el nodo local las usa en los datos de salida, vea Marcas de aplicación.
En el caso de los datos salientes, el primer byte es RU[0] para la interfaz de administración de funciones (FMI) estándar y TH[0] para la variante de la aplicación de unidad lógica (LUA) de FMI.
Todos los mensajes Data del nodo local a una aplicación contienen una clave de mensaje. El nodo local mantiene una secuencia de claves de mensaje única para cada flujo de datos saliente a una aplicación. Cuando el nodo local envía un mensaje Data a una aplicación en una conexión determinada, coloca la siguiente clave de mensaje de la secuencia saliente en el encabezado del mensaje, establece las marcas de aplicación y envía el mensaje a la aplicación. Esto significa que la clave de mensaje identifica de forma única un mensaje Data en una conexión determinada entre el nodo local y la aplicación. Tenga en cuenta que el nodo local también coloca las claves de mensaje en los mensajes Status-Control Request de salida.
El protocolo de confirmación aplicado por Host Integration Server refleja el protocolo de respuesta de cadena y el modo de solicitud en uso en la sesión de SNA, como se muestra a continuación:
Las solicitudes RQD salientes generan mensajes Data con ACKRQD establecido en el encabezado del mensaje.
Las solicitudes RQE salientes generan mensajes Data sin el conjunto ACKRQD.
Las solicitudes RQN salientes generan mensajes Data sin un conjunto ACKRQD.
Si la sesión usa el modo de solicitud inmediata principal, la aplicación debe confirmar un mensaje Data con el conjunto ACKRQD antes de recibir más mensajes Data.
Si la sesión usa el modo de solicitud retrasada principal, la aplicación no debe confirmar inmediatamente un mensaje Data con un conjunto ACKRQD. Se seguirán recibiendo los mensajes Data.
Tenga en cuenta que Host Integration Server aplica el equivalente del modo de respuesta inmediata para el protocolo de confirmación de datos de salida para todas las conexiones. La aplicación debe enviar confirmaciones en orden.
Si el nodo local establece el campo ACKRQD en el encabezado del mensaje de un mensaje Data a la aplicación, indica que se requiere una confirmación para este mensaje Data. La aplicación confirma un mensaje Data saliente mediante el envío de un mensaje Status-Acknowledge al nodo local en la misma conexión, que contiene los mismos campos de clave de mensaje y número de secuencia que el mensaje Data.
Al recibir una confirmación Status-Acknowledge(Ack), el nodo local correlaciona la clave de mensaje con los mensajes salientes pendientes y genera una respuesta positiva de SNA a la solicitud de SNA adecuada.
La aplicación debe usar el mensaje Status-Acknowledge(Nack-1) como confirmación negativa. Al recibir una confirmación Status-Acknowledge(Nack-1) , el nodo local correlaciona el mensaje con los mensajes salientes pendientes y genera una respuesta negativa de SNA más datos de sentido a la solicitud de SNA adecuada. La aplicación proporciona los datos de sentido que deben acompañar a la respuesta negativa como parte del mensaje Status-Acknowledge(Nack-1) , que deben incluir la misma clave de mensaje, marcas de aplicación y campos de número de secuencia que el mensaje Data para el que es una confirmación negativa.
Los mensajes de Status-Control causados por solicitudes de flujo rápido se pueden enviar en cualquier momento y no afectan al envío de confirmaciones positivas o negativas a los mensajes Data salientes de flujo normal. El hecho de que se produzcan entre un mensaje Data saliente y el mensaje Status-Acknowledge correspondiente es pura coincidencia. Para obtener más información sobre qué mensajes Status-Control corresponden a las solicitudes de SNA, vea Mensaje Status-Control.
Si se detectan errores en el formato de una solicitud de flujo normal del host o la solicitud no es adecuada para el estado de la sesión, el nodo local genera un mensaje Data de error para la aplicación con las siguientes características:
Se establecen las marcas de aplicación SDI y ECI.
El código de sentido asociado al error ocupa los cuatro primeros bytes del mensaje Data. (Para obtener más información, vea Mensaje Status-Control).
Se establece ACKRQD.
La aplicación debe devolver Status-Acknowledge(Ack) y el nodo local genera una respuesta negativa que lleva el código de sentido adecuado para el error detectado. El mecanismo hace lo siguiente:
Informa a la aplicación del error detectado.
Permite que la aplicación responda a los datos recibidos previamente antes de que el nodo local envíe la respuesta negativa a este mensaje Data.
En las sesiones en las que la aplicación recibe una serie de cadenas RQE, el nodo local conservará la información de correlación para cada cadena (en caso de que la aplicación quiera enviar respuestas negativas a cualquiera de las cadenas). Si el nodo local se queda sin entradas de tabla de correlación, intentará asignar más entradas y (si se produce un error) se verá obligado a finalizar las sesiones. Para evitarlo, la aplicación debe proporcionar mensajes Status-Acknowledge(Ack) para los datos RQE que no desea rechazar en este caso. Una respuesta después de cinco cadenas RQE consecutivas debe ser suficiente. Estos mensajes se conocen como confirmaciones de cortesía y no dan lugar a una respuesta al host, sino que simplemente liberan datos de correlación interna.
Las seis ilustraciones siguientes muestran el protocolo de confirmación de datos aplicado entre el nodo local y la aplicación, y muestran los efectos de la aplicación que genera mensajes Status-Acknowledge positivos y negativos.
Las ilustraciones muestran:
Las marcas RH pertinentes en solicitudes y respuestas de SNA.
El número de secuencia de solicitudes y respuestas de SNA.
Cualquier dato de sentido (que se muestra como "SENSE=...") en solicitudes/respuestas de SNA y mensajes Status-Acknowledge.
El campo ACKRQD en mensajes Data.
El campo de clave de mensaje en mensajes Data.
Por motivos de simplicidad, se supone que todos los mensajes son datos de FM que fluyen en la misma sesión de PLU.
En la ilustración siguiente, la aplicación acepta un mensaje Data correspondiente a una RU de respuesta definitiva.
La aplicación envía un mensaje Data correspondiente a una RU de respuesta definitivaEn la ilustración siguiente, la aplicación acepta un mensaje Data correspondiente a una cadena de respuesta definitiva de RU múltiple.
La aplicación acepta un mensaje Data correspondiente a una cadena de respuesta definitiva de RU múltiple.En la ilustración siguiente, la aplicación rechaza un mensaje Data correspondiente a una cadena de respuesta definitiva.
La aplicación rechaza un mensaje Data correspondiente a una cadena de respuesta definitiva.En la ilustración siguiente, la aplicación rechaza un mensaje Data correspondiente a una cadena de respuesta definitiva de RU múltiple.
La aplicación rechaza un mensaje Data correspondiente a una cadena de respuesta definitiva de RU múltiple.En la ilustración siguiente, el nodo local aplica el modo de respuesta inmediata. Las respuestas deben aparecer en secuencia. La aplicación rechaza la segunda cadena de respuesta a excepciones y acepta la cadena de respuesta definitiva, lo que implica la aceptación de la tercera cadena de respuesta a excepciones.
El nodo local aplica el modo de respuesta inmediata.En la ilustración siguiente, el nodo local detecta un error de encadenamiento (RQD pero no EC) en los datos destinados a la aplicación. (En este ejemplo se requiere que la comprobación de recepción 0x4007 esté en vigor. Para obtener más información, consulte Apertura de la conexión SSCP).
El nodo local detecta un error de encadenamiento en los datos destinados a la aplicación
Consulte también
Datos de entrada
Datos de entrada desde las aplicaciones de LUA