Datos de entrada
En esta sección, se describen los flujos de datos entrantes desde la aplicación al nodo local. 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 los aspectos más complejos (como el uso del modo de solicitud retrasada) solo son aplicables a la conexión PLU.
La aplicación puede enviar datos de entrada en cualquiera de las conexiones, como se indica a continuación:
Los servicios de red de datos de administración de funciones (FMD NS) (servicios de sesión) y los datos codificados por caracteres de datos de administración de funciones (FMD) destinados al SSCP del host deben enviarse al nodo local en la conexión SSCP.
Los datos FMD diseñados para la PLU del host deben enviarse al nodo local en la conexión PLU.
La aplicación no puede usar mensajes Data para enviar mensajes de control de flujo de datos (DFC) o de solicitud de control de sesión al host. En su lugar, debe usar mensajes Status-Control. (Para más información, vea Mensaje de control de estado).
Para todas las conexiones, la aplicación debe rellenar determinados campos clave del encabezado del mensaje Data. En concreto, debe hacer lo siguiente:
Establecer el tipo de mensaje en DATAFMI.
Asignar una nueva clave de mensaje para los mensajes de Datos entrantes en esta conexión.
Establecer el campo ACKRQD si es necesario.
Establecer las marcas de aplicación. (Para más información, vea Marcas de aplicación).
Los campos nxtqptr, hdreptr y numelts del encabezado del mensaje, y los campos elteptr y startd de los elementos del mensaje se establecen mediante las rutinas de administración de búferes de Host Integration Server. (Para más información, vea Interfaz DL-BASE/DMOD). La aplicación es responsable de establecer el campo endd.
Si la aplicación no tiene acceso a estas rutinas (por ejemplo, cuando el entorno operativo no admite llamadas a procedimientos de intertarea y memoria compartida), la aplicación debe establecer todos los campos del encabezado.
Los indicadores del encabezado de transmisión (TH) y del encabezado de respuesta (RH) no están disponibles para la aplicación en los mensajes de Datos de entrada. La aplicación debe establecer las marcas de aplicación adecuadas en el encabezado del mensaje para controlar el encadenamiento, la dirección, etc. Para obtener una descripción de las marcas de aplicación disponibles para los datos entrantes y los temas posteriores de esta sección para obtener una descripción de cómo se usan las marcas para controlar los flujos de datos entrantes, vea Marcas de aplicación.
En el caso de los datos entrantes, el primer byte es RU[0] para la interfaz de administración de funciones estándar (FMI).
El nodo local usa la clave del mensaje proporcionada por la aplicación en el encabezado de mensaje de Datos de entrada para indicar a qué mensaje de Datos de esta conexión hace referencia un mensaje Status-Acknowledge saliente. La aplicación debe mantener una secuencia de claves de mensajes única para el flujo de datos de entrada en cada conexión que tenga con el nodo local, de modo que la aplicación pueda usar la clave de mensaje para correlacionar los mensajes de Datos entrantes y los mensajes Status-Acknowledge salientes en la conexión. Tenga en cuenta que la aplicación también debe proporcionar una clave de mensaje en los mensajes Status-Control Request para diferenciar entre varios mensajes RQE LUSTAT.
El protocolo de confirmación de datos de entrada refleja el protocolo de respuesta de cadena secundaria y el modo de solicitud en uso en la sesión, como se indica a continuación:
Los mensajes de Datos entrantes con ACKRQD establecido en el encabezado generan solicitudes RQD.
Los mensajes de Datos entrantes sin ACKRQD establecido en el encabezado generan solicitudes RQE o RQN en función del protocolo de respuesta de cadena.
La aplicación solo debe establecer ACKRQD en los mensajes de Datos que tengan establecida la marca de aplicación del indicador de cadena final (ECI).
Si la sesión especifica que el elemento secundario usa el modo de solicitud inmediato, la aplicación todavía puede enviar más mensajes Data después de enviar datos con ACKRQD establecido, aunque no haya recibido un mensaje Status-Acknowledge para ese mensaje Data. Los mensajes se ponen en cola dentro del nodo local y se envían progresivamente a medida que se reciben respuestas positivas.
Si la sesión especifica que el elemento secundario usa el modo de solicitud retrasada, después de enviar un mensaje Data con ACKRQD establecido, la aplicación puede seguir enviando mensajes Data.
Si la aplicación establece el campo ACKRQD en el encabezado del mensaje de un mensaje Data, indica que requiere una confirmación para este mensaje Data. El nodo local confirma un mensaje Data de entrada mediante el envío de un mensaje Status-Acknowledge a la aplicación en la misma conexión y el uso de la misma clave de mensaje que el mensaje Data. (Para obtener una ilustración, vea la primera ilustración al final de este tema).
El nodo local procesa los mensajes Data entrantes de la aplicación a través de sus equipos de estado interno, asigna el número de secuencia SNA correcto o un identificador para este flujo y envía los datos en una solicitud al host. El tipo de respuesta en cadena de la solicitud depende de si ACKRQD se estableció en el mensaje Data y en los parámetros de sesión.
El nodo local asigna una respuesta positiva del host a Status-Acknowledge(Ack) en la aplicación. La aplicación puede usar la clave de mensaje en Status-Acknowledge para correlacionar la confirmación con el mensaje Data original. Por lo tanto, la recepción de una confirmación Status-Acknowledge(Ack) para un mensaje Data determinado indica que el nodo local ha recibido una respuesta SNA positiva del host a la solicitud SNA entrante. (Para obtener una ilustración, vea la segunda ilustración al final de este tema).
Tenga en cuenta que las respuestas se usan en la sesión SSCP-PU.
Tenga en cuenta que los mensajes Status-Acknowledge(Ack) salientes contienen marcas de aplicación y un número de secuencia. Las marcas de aplicación reflejan los indicadores RH en la respuesta. El número de secuencia es el número de secuencia de SNA de la respuesta y proporciona un mecanismo para que las aplicaciones que usan el perfil de servicio de transmisión (perfil de TS) 4 realicen el seguimiento del número de secuencia secundaria de SNA correspondiente a una unidad de trabajo.
El nodo local asigna una respuesta positiva del host a un mensaje Status-Acknowledge(Nack-1) en la aplicación. La aplicación puede usar la clave de mensaje en Status-Acknowledge para correlacionar la confirmación negativa con el mensaje Data original. El mensaje Status-Acknowledge(Nack-1) de salida contiene los códigos de detección de SNA y el número de secuencia de la respuesta negativa. (Para obtener una ilustración, vea las ilustraciones tercera y cuarta al final de este tema).
Si el nodo local detecta un error en el formato de un mensaje Data de entrada o el mensaje Data no es adecuado para el estado actual de la sesión, envía una confirmación de estado Status-Acknowledge(Nack-2) a la aplicación que contiene un código de error. (Para obtener una lista de códigos de error, vea Códigos de error y detección). El nodo local no envía una solicitud al host correspondiente al mensaje Data en el error y el número de secuencia de SNA no avanza para la sesión. La aplicación puede usar cualquier clave de mensaje en su siguiente mensaje Data de entrada (suponiendo que el error no cause un error crítico).
Un ejemplo de un error de encadenamiento grave, donde la aplicación envía un mensaje Data con ACKRQD pero sin ECI en las marcas de aplicación, se muestra en la última ilustración al final de este tema. Tenga en cuenta que, después de detectar este error concreto, el nodo local marca la conexión de la aplicación como con errores críticos, cierra la conexión y envía una solicitud TERM-SELF a SSCP para obtener un elemento UNBIND. (Para más información, consulte el artículo sobre recuperación).
Los mensajes Status-Control entrantes, que generan 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 entrantes. Para obtener más información sobre qué mensajes Status-Control corresponden a las solicitudes de flujo rápido, vea Mensaje de control de estado.
En las cinco ilustraciones siguientes se muestran ejemplos de los protocolos de confirmación de datos entrantes, y los protocolos SNA subyacentes, para diferentes tipos de respuesta de cadena y modos de solicitud de sesión secundaria.
Las cifras muestran:
El campo ACKRQD en mensajes Data.
Clave de mensaje en mensajes Data.
Cualquier marca de aplicación pertinente en los mensajes Data.
Códigos de error (que se muestran como "ERROR=...") en los mensajes Data.
Las marcas RH pertinentes en solicitudes y respuestas de SNA.
Números de secuencia en solicitudes y respuestas de SNA.
Códigos de detección (que se muestran como "SENSE=....") en solicitudes y respuestas de SNA.
Por motivos de simplicidad, se supone que todos los mensajes fluyen en la misma sesión de PLU.
En la ilustración siguiente, la aplicación envía correctamente un mensaje Data.
La aplicación envía correctamente un mensaje Data.En la ilustración siguiente, la aplicación envía correctamente una cadena de mensajes Data.
La aplicación envía correctamente una cadena de mensajes Data.En la ilustración siguiente, el host rechaza una cadena de mensajes Data.
El host rechaza una cadena de mensajes Data.En la ilustración siguiente, el host rechaza la primera cadena de respuesta definitiva y rechaza la tercera cadena de respuesta a excepciones en una sesión de solicitud retrasada. Tenga en cuenta que la respuesta negativa a la tercera cadena genera una respuesta positiva a la segunda cadena.
El host rechaza la primera cadena de respuesta definitiva.En la ilustración siguiente, el nodo local detecta el uso no válido de ACKRQD de la aplicación sin la marca de aplicación ECI en un mensaje Data. Tenga en cuenta que no se envía ningún dato al host. Sin embargo, dado que el error es crítico, el nodo local enviará un mensaje TERM-SELF a SSCP.
El nodo local detecta el uso no válido de ACKRDQ de la aplicación sin la marca de aplicación ECI en un mensaje Data.
Consulte también
Datos de salida
Datos de entrada desde las aplicaciones de LUA