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 entrantes de la aplicación al nodo local. 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 los aspectos más complejos (como el uso del modo de solicitud retrasada) solo se aplican a la conexión PLU.
La aplicación puede enviar datos entrantes 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 de administración de funciones (FMD) codificados con caracteres destinados al SSCP del host deben enviarse al nodo local en la conexión SSCP.
Los datos de FMD destinados al host PLU deben enviarse al nodo local en la conexión PLU.
La aplicación no puede usar mensajes de datos para enviar el control de flujo de datos (DFC) o los mensajes de solicitud de control de sesión al host. En su lugar, debe usar mensajes Status-Control . (Para obtener más información, consulte Status-Control Message).
Para todas las conexiones, la aplicación debe rellenar determinados campos clave en el encabezado del mensaje Datos . En concreto, debe:
Establezca el tipo de mensaje en DATAFMI.
Asigne una nueva clave de mensaje para los mensajes de datos entrantes en esta conexión.
Establezca el campo ACKRQD si es necesario.
Establezca las banderas de la aplicación. (Para obtener más información, consulte Marcas de aplicación).
Los campos nxtqptr, hdreptr y numelts en el encabezado del mensaje, y los campos elteptr y startd en los elementos del mensaje son configurados por las rutinas de administración del búfer del Host Integration Server. (Para obtener más información, vea DL-BASE/DMOD Interface.) 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 intertask y memoria compartida), la aplicación debe establecer todos los campos del encabezado.
Los indicadores de encabezado de transmisión (TH) y encabezado de respuesta (RH) no están disponibles para la aplicación en mensajes de datos entrantes. La aplicación debe establecer las banderas de aplicación adecuadas en el encabezado del mensaje para controlar el encadenamiento, la dirección y otros aspectos. Para obtener una descripción de las marcas de aplicación disponibles para los datos entrantes y 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, consulte Marcas de aplicación.
Para los datos entrantes, el primer byte es RU[0] para la interfaz de administración de funciones estándar (FMI).
El nodo local utiliza la clave de mensaje suministrada por la aplicación en el encabezado de mensaje de datos entrante para indicar a qué mensaje de datos de esta conexión hace referencia la Confirmación de Estado saliente. La aplicación debe mantener una secuencia de clave de mensaje ú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 mensajes de datos entrantes y mensajes Status-Acknowledge salientes en la conexión. Tenga en cuenta que la aplicación también debe proporcionar una clave de mensaje en Status-Control Request para diferenciar entre varios RQE LUSTAT mensajes.
El protocolo de confirmación de datos de entrada refleja el protocolo de respuesta de la cadena secundaria y el modo de solicitud en uso en la sesión, como se indica a continuación:
Mensajes de datos entrantes con ACKRQD establecido en el encabezado generan solicitudes RQD.
Los mensajes de datos entrantes sin ACKRQD establecidos en el encabezado generan solicitudes RQE o RQN en función del protocolo de respuesta de la cadena.
La aplicación solo debe establecer ACKRQD en mensajes de datos que tengan establecida la marca de aplicación indicador de cadena final (ECI).
Si la sesión especifica que la secundaria usa el modo de solicitud inmediata, la aplicación todavía puede enviar más mensajes de datos después de enviar datos con ACKRQD establecido, aunque no haya recibido un mensaje Status-Acknowledge para ese mensaje de datos . 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 la secundaria usa el modo de solicitudes demoradas, 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 de mensaje de un mensaje data , indica que requiere una confirmación para este mensaje de datos . El nodo local confirma un mensaje de datos entrante enviando un mensaje Status-Acknowledge a la aplicación en la misma conexión y usando 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 de datos 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 cadena-respuesta de la solicitud depende de si ACKRQD se estableció en el mensaje Datos y los parámetros de sesión.
El nodo local asigna una respuesta positiva del host a status-Acknowledge(Ack) a 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 un mensaje Status-Acknowledge(Ack) para un mensaje de datos determinado implica que el nodo local ha recibido una respuesta SNA positiva del host a la solicitud de SNA entrante. (Para obtener una ilustración, vea la segunda ilustración al final de este tema).
Tenga en cuenta que las respuestas se absorben en la sesión de SSCP-PU.
Tenga en cuenta que los mensajes Status-Acknowledge(Ack) salientes contienen marcas de aplicación y un número de secuencia. Las banderas de aplicación reflejan los indicadores de RH en la respuesta. El número de secuencia es el número de secuencia SNA de la respuesta y proporciona un mecanismo para que las aplicaciones usen el perfil del servicio de transmisión (perfil de TS) 4 para realizar un seguimiento del número de secuencia secundaria de SNA correspondiente a una unidad de trabajo.
El nodo local asigna una respuesta negativa del host a un mensaje Status-Acknowledge(Nack-1) a 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) saliente 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 cifras tercera y cuarta al final de este tema).
Si el nodo local detecta un error en el formato de un mensaje de datos entrante o el mensaje Datos no es adecuado para el estado actual de la sesión, envía un Status-Acknowledge(Nack-2) a la aplicación que contiene un código de error. (Para obtener una lista de códigos de error, consulte Códigos de error y detección). El nodo local no envía una solicitud al host correspondiente al mensaje Data en error y no avanza el número de secuencia de SNA para la sesión. La aplicación puede usar cualquier clave de mensaje en su siguiente mensaje de datos entrante (suponiendo que el error no causa un error crítico).
Un ejemplo de un error de encadenamiento grave, donde la aplicación envía un mensaje de datos 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 en particular, 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 al SSCP para iniciar un UNBIND. (Para obtener más información, consulte Recuperación).
Los mensajes status-Control entrantes, que provocan la generación de solicitudes de flujo acelerado, se pueden enviar en cualquier momento y no afectan al envío de una confirmación positiva o negativa a los mensajes de datos entrantes. Para obtener más información sobre los mensajes Status-Control que corresponden a las solicitudes de flujo acelerado de SNA, consulte Status-Control Message.
En las cinco cifras siguientes se muestran ejemplos de los protocolos de confirmación de datos entrantes (y los protocolos SNA subyacentes) para los distintos tipos de respuesta de cadena y modos de solicitud de sesión secundaria.
Las cifras muestran:
El campo ACKRQD de los mensajes de datos.
Clave de mensaje en Mensajes de datos .
Cualquier bandera de aplicación pertinente en mensajes de datos.
Códigos de error (que se muestran como "ERROR=...") en mensajes de datos .
Indicadores relevantes de RH en las solicitudes y respuestas de SNA.
Números de secuencia en solicitudes/respuestas de SNA.
Códigos de sentido (que se muestran como "SENSE=....") en solicitudes o 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 de datosEn 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 de datosEn la ilustración siguiente, el host rechaza una cadena de mensajes data .
El host rechaza una cadena de mensajes de datosEn la ilustración siguiente, el host rechaza la primera cadena de respuesta definitiva y rechaza la tercera cadena de respuesta de excepción en una sesión de solicitud retrasada. Tenga en cuenta que la respuesta negativa a la tercera cadena implica una respuesta positiva a la segunda cadena.
El host rechaza la primera cadena de respuesta definitivaEn la figura siguiente, el nodo local detecta el uso no válido de la aplicación de ACKRQD 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 al SSCP.
El nodo local detecta el uso no válido de ACKRDQ por parte de la aplicación sin la bandera ECI de la aplicación en un mensaje de datos