Compartir a través de

Características de la sesión de SSCP

  • Artículo

En el caso de los nodos SNA de tipo 2.1, la sesión del punto de control de servicios del sistema (SSCP) usa el perfil de administración de funciones (FM) 0 y el perfil del servicio de transmisión (perfil TS) 1. Esta combinación de perfiles proporciona las siguientes características de sesión:

  • Las sesiones medias principales y secundarias usan el modo de solicitud inmediata.

  • Las sesiones medias principales y secundarias usan el modo de respuesta inmediata.

  • Solo se permiten cadenas de unidades de solicitud únicas de respuesta definitiva.

  • El tamaño máximo de la unidad de solicitud está limitado a 256 bytes.

  • No se admiten unidades de solicitud de control de flujo de datos.

  • No se admite el ritmo.

  • Los identificadores se usan (en lugar de números de secuencia) en los flujos normales.

    Esto implica que la conexión SSCP tiene las siguientes características:

  • Todos los mensajes de datos tienen establecido el campo de confirmación (ACKRQD).

  • Todos los mensajes de datos tienen establecidas las marcas de aplicación indicador de cadena inicial (BCI) y indicador de cadena final (ECI).

  • Los mensajes Status-Control no fluyen en la conexión.

  • Mensajes status-Session del nodo local a la aplicación solo notifican los cambios en el estado de activación de la sesión.

  • No se aplican los protocolos de encadenamiento, corchete, confirmación y recuperación (descritos en Conexión PLU).

    Con la conexión SSCP, la aplicación puede enviar y recibir mensajes de datos correspondientes a las solicitudes de servicios de red de datos de administración de funciones (FMD NS) (servicios de sesión) y solicitudes de datos FMD. Algunos ejemplos de solicitudes de FMD NS (servicios de sesión) son:

  • INIT-SELF. Solicitudes de la base de datos secundaria al SSCP del host que solicita que el SSCP ayude en el inicio de una sesión al host PLU, solicitando eficazmente un BIND. (Para obtener más información, vea Apertura de la conexión de PLU).

  • TERM-SELF. Solicitudes de la base de datos secundaria al SSCP del host que solicita que la sesión PLU-SLU finalice con un UNBIND. (Para obtener más información, vea Cerrar la conexión PLU).

  • Solicitudes codificadas por caracteres. Solicitudes como inicio de sesión, inicio de sesión o comandos de prueba desde la pantalla secundaria o un símbolo del inicio de sesión de la aplicación host.

  • NOTIFICAR. Las solicitudes usadas por la secundaria para notificar al host SSCP que un dispositivo está disponible después de que se rechazó bind con código de detección 0x0845, por ejemplo, donde un emulador de dispositivo admite el apagado lógico.

    El nodo local envía una solicitud NOTIFY al SSCP en nombre de la LU cada vez que cambia el estado de conexión SSCP de la aplicación mientras la LU está activa. Una notificación (0x0C de clave vectorial con el byte 5 establecido en 0x03), que puede actuar como LU secundaria, se envía en los casos siguientes:

  • Cuando se recibe una solicitud open(SSCP) cuando la LU ya está activa.

  • Cuando se acepta una solicitud ACTLU cuando la conexión SSCP ya está abierta.

    En los casos siguientes se envía una notificación (clave vectorial 0x0C con el byte 5 establecido en 0x01), que actualmente no puede actuar como LU secundaria:

  • Cuando se recibe una ACTLU cuando la conexión SSCP no está abierta.

  • Cuando se recibe una solicitud Close(SSCP) cuando la sesión de PLU no está enlazada.

  • Cuando se recibe una solicitud UNBIND cuando la conexión SSCP no está abierta.

  • Cuando se usa la respuesta larga, incluido el vector NOTIFY , para las solicitudes ACTLU.

    El host puede usar estos mensajes NOTIFY junto con la respuesta negativa 0x0845 que el nodo local proporciona a un BIND recibido cuando la conexión SSCP no está abierta. (Para obtener más información, vea Apertura de la conexión de PLU).