Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En esta sección se describen los flujos de datos salientes del nodo local a la aplicación. La estructura general de los protocolos descritos se aplica al punto de control de servicios del sistema (SSCP) y a las conexiones de unidad lógica principal (PLU), pero ciertas características (como el uso del modo de solicitud retrasada) solo se aplican a la conexión PLU.
El nodo local presenta 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 indica 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 son enviados a la aplicación a través de la conexión SSCP.
Los datos de FMD que se originan en la PLU del host y se dirigen a una LU de servidor SNA se envían a la aplicación en la conexión PLU.
Para todas las conexiones, solo las solicitudes FMD se presentan a la aplicación como mensajes de datos (con el 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, consulte Status-Control Message).
El nodo local realiza los cambios de estado de control de flujo de datos requeridos por los indicadores de encabezado de respuesta (RH) de la solicitud, antes de enviar un mensaje data a la aplicación.
Los indicadores de encabezado de transmisión de solicitudes SNA (TH) y RH no están disponibles para la aplicación en los mensajes de datos salientes. En su lugar, el nodo local proporciona marcas de aplicación en el encabezado de Data del mensaje que reflejan la configuración de un subconjunto de los indicadores RH, y que el nodo local interpreta para proteger la aplicación de los aspectos más oscuros del encadenamiento y del uso de corchetes. Para obtener una descripción de las marcas disponibles y la forma en que el nodo local los usa en los datos de salida, consulte Marcas de aplicación.
Para los datos salientes, el primer byte es RU[0] para la interfaz de administración de funciones estándar (FMI) y TH[0] para la variante de aplicación de unidad lógica (LUA) de FMI.
Todos los mensajes de datos del nodo local a una aplicación contienen una clave de mensaje. El nodo local mantiene una secuencia de clave 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 en la secuencia de salida 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 de datos en una conexión determinada entre el nodo local y la aplicación. Tenga en cuenta que el nodo local también pone las claves de los mensajes en los mensajes de solicitud de control de estado 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 indica a continuación:
Las solicitudes de RQD salientes generan mensajes de datos con ACKRQD establecido en el encabezado del mensaje.
Las solicitudes RQE salientes generan mensajes datos sin ACKRQD configurado.
Las solicitudes de RQN salientes generan mensajes de datos sin definir el ACKRQD.
Si la sesión usa el modo de solicitud inmediata principal, la aplicación debe confirmar un mensaje de datos con ACKRQD establecido antes de recibir más mensajes de datos .
Si la sesión usa el modo de solicitud retrasada principal, la aplicación no debe confirmar inmediatamente un mensaje de datos con el conjunto ACKRQD . Los mensajes de datos seguirán recibiendose.
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 de mensaje de un mensaje de datos en la aplicación, indica que se requiere una confirmación para este mensaje de datos . La aplicación reconoce un mensaje de datos saliente enviando 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 un status-Acknowledge(Ack), el nodo local correlaciona la clave de mensaje con 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 un status-acknowledge(Nack-1), el nodo local correlaciona el mensaje con los mensajes de salida pendientes y genera una respuesta negativa de SNA, además de los datos de diagnóstico, a la petición 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) y debe incluir la misma clave de mensaje, marcas de aplicación y campos de número de secuencia que el mensaje Datos al que se trata de una confirmación negativa.
Los mensajes de status-control causados por solicitudes de flujo acelerado se pueden enviar en cualquier momento y no afectan al envío de confirmaciones positivas o negativas a los mensajes de Datos salientes normales. El hecho de que se puedan producir entre un mensaje de datos saliente y el mensaje Status-Acknowledge coincidente es meramente coincidente. Para obtener más información sobre los mensajes Status-Control que corresponden a las solicitudes de SNA, consulte Status-Control Message.
Si se detectan errores en el formato de una solicitud de flujo normal desde el host o la solicitud no es adecuada para el estado de la sesión, el nodo local genera un mensaje de error Data 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, consulte Status-Control Message).
ACKRQD está establecido.
La aplicación debe devolver un status-Acknowledge(Ack) y el nodo local genera una respuesta negativa que lleva el código de sentido adecuado para el error detectado. Este mecanismo hace lo siguiente:
Informa a la aplicación del error detectado.
Permite que la aplicación responda a los datos recibidos anteriormente antes de que el nodo local envíe la respuesta negativa a este mensaje de datos.
En las sesiones en las que la aplicación recibe una serie de cadenas de RQE, el nodo local conservará la información de correlación de 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 forzará a finalizar las sesiones. Para evitar esto, la aplicación debe proporcionar mensajes Status-Acknowledge(Ack) para los datos de RQE que no desea rechazar en este caso. Una respuesta después de cinco cadenas de RQE consecutivas debe ser suficiente. Estos mensajes se conocen como confirmaciones de cortesía y no requieren una respuesta al host, sino simplemente liberan los datos de correlación interna.
En las seis figuras siguientes se muestra el protocolo de confirmación de datos aplicado entre el nodo local y la aplicación, y se muestran los efectos de la aplicación que genera mensajes e positivos y negativos de confirmación de estado.
Las cifras muestran:
Los indicadores de RH pertinentes en las solicitudes o respuestas de SNA.
Número de secuencia de solicitudes y respuestas de SNA.
Cualquier dato de detección (mostrado como "SENSE=...") en solicitudes/respuestas de SNA y en mensajes de reconocimiento de estado Status-Acknowledge.
Campo ACKRQD en Mensajes de datos .
Campo de clave de mensaje en Mensajes de datos .
Por simplicidad, se supone que todos los mensajes son datos FM que fluyen en la misma sesión de PLU.
En la ilustración siguiente, la aplicación acepta un mensaje de datos correspondiente a una RU de respuesta definitiva.
La aplicación envía un mensaje de datos correspondiente a una respuesta definitiva a un RUEn la ilustración siguiente, la aplicación acepta un mensaje de datos correspondiente a una cadena de respuesta definitiva de múltiples RU.
La aplicación acepta un mensaje de datos correspondiente a una cadena de respuesta definitiva de varias RUEn la ilustración siguiente, la aplicación rechaza un mensaje de datos correspondiente a una cadena de respuesta definitiva.
La aplicación rechaza un mensaje de datos correspondiente a una cadena de respuesta definitivaEn la ilustración siguiente, la aplicación rechaza un mensaje de datos correspondiente a una cadena de respuesta definitiva de varias RU.
La aplicación rechaza un mensaje de datos correspondiente a una cadena de respuesta definida de varias RUEn la ilustración siguiente, el nodo local aplica el modo de respuesta inmediata. Las respuestas deben enviarse en secuencia. La aplicación rechaza la segunda cadena de respuesta de excepciones y acepta la cadena de respuesta definitiva, lo que implica la aceptación de la tercera cadena de respuesta de excepción.
El nodo local exige el modo de respuesta inmediataEn 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.