Compartir a través de

Shutdown

  • Artículo

El protocolo de apagado brinda a la aplicación host la capacidad de evitar que la aplicación envíe otras solicitudes de flujo normal. Este protocolo se utiliza cuando la aplicación host desea finalizar la sesión de manera ordenada y solo está disponible para las sesiones que utilizan el perfil de administración de funciones (FM) 3 o 4.

Si el nodo local recibe una solicitud SHUTD proveniente del host, emite una solicitud Status-Control(SHUTD) (sin ACKRQD) para solicitar a la aplicación que ingrese a un estado de inactividad en un momento adecuado. Es la aplicación la que determina el momento adecuado. Por ejemplo, podría ser después de recibir una solicitud Status-Session(BETB) .

Cuando la aplicación decida que está lista para entrar en un estado de inactividad, deberá emitir una solicitud Status-Control(SHUTC) (como antes, sin ACKRQD) para indicar esta transición. El nodo local enviará una solicitud SHUTC para notificar al host sobre este cambio. El host puede seguir enviando solicitudes de salida de flujo normal y, posteriormente, puede realizar una de estas acciones:

  • El host envía una solicitud UNBIND para terminar la sesión de la unidad lógica principal (PLU). El nodo local envía una solicitud Close(PLU) a la aplicación para cerrar la conexión de PLU. La sesión del punto de control de servicios del sistema (SSCP) permanece activa.

  • El host envía una solicitud RELQ para abandonar el procedimiento de apagado. El nodo local envía una solicitud Status-Control(RELQ) (con ACKRQD) a la aplicación para indicar que ahora puede reanudar los envíos en la sesión de PLU. RELQ solo se admite en las sesiones que utilizan el perfil de FM 4.

  • El host restablece la sesión al enviar CLEAR, un perfil de servicio de transmisión (perfil TS) 3 o 4. Uno de los efectos de esto es liberar el estado de inactividad. (Para más información, consulte el artículo sobre recuperación).

    Las dos ilustraciones siguientes muestran los protocolos de apagado entre el nodo local y la aplicación y cómo se relacionan esos protocolos con los protocolos SNA subyacentes.

    En la ilustración siguiente, el host envía la solicitud SHUTD mientras la aplicación envía en el estado entre corchetes. La aplicación completa el corchete, envía una solicitud Status-Control(SHUTC) y el host envía la solicitud UNBIND para terminar la sesión de PLU. El nodo local cierra la conexión de PLU.

    Imagen que muestra cómo un host envía SHUTD mientras la aplicación envía en estado entre corchetes.
    Host envía una solicitud SHUTD mientras la aplicación envía en el estado entre corchetes

    En la ilustración siguiente, el host envía la solicitud SHUTD mientras la aplicación envía en el estado entre corchetes. La aplicación completa el corchete, envía una solicitud Status-Control(SHUTC) y el host envía la solicitud RELQ para liberar la aplicación del estado de inactividad. El nodo local envía una solicitud Status-Control(RELQ) a la aplicación, que inicia un corchete nuevo.

    Imagen que muestra un host que envía SHUTD mientras la aplicación envía en estado entre corchetes.
    Host envía una solicitud SHUTD mientras la aplicación envía en el estado entre corchetes

Consulte también

Apertura de la conexión de PLU
Sesión de PLU
Encadenamiento de salida
Encadenamiento de entrada
Entrega de segmentos
Brackets
Dirección
Velocidad y fragmentación
Confirmación y rechazo de datos]
Apagado y modo inactivo
Recuperación
Terminación iniciada por la aplicación
LUSTATs]
Datos del Monitor de tiempo de respuesta