정지 프로토콜은 FM(함수 관리) 프로필 4를 사용하는 세션에서만 지원됩니다. 정지 프로토콜은 반 세션에서 시작할 수 있습니다.
애플리케이션은 호스트에서 파트너 반 세션을 정지하려는 경우 Status-Control(QEC) Request를 로컬 노드로 보냅니다. 노드는 호스트에 대해 QEC 요청을 생성하여 현재 아웃바운드 체인을 완료한 후 정지하도록 호스트에 요청합니다.
호스트는 정지되면 로컬 노드가 Status-Control(QC) Request(ACKRQD 포함)로 애플리케이션에 제공하는 QC 요청을 보냅니다. 호스트는 애플리케이션이 Status-Control(RELQ) Request를 보낼 때까지 정지된 상태로 유지됩니다. 로컬 노드는 호스트에 RELQ 요청을 보내고 호스트는 PLU(기본 논리 단위) 세션에서 통신을 다시 시작합니다.
호스트를 정지하려는 시도가 실패하면 호스트는 로컬 노드가 Status-Control(QEC) Negative-Acknowledge-1로 애플리케이션에 제공하는 부정 QEC 응답으로 응답합니다.
반대로, 호스트에서 QEC 요청을 받으면 Status-Control(QEC) Request(ACKRQD 제외)가 애플리케이션에 제공됩니다. 이 방향에서는 QEC를 거부할 수 없습니다. 로컬 노드는 인바운드 데이터를 보내려는 추가 시도를 거부하여 Status-Control(QEC) Request를 제공한 후 항상 애플리케이션을 강제로 정지합니다. 애플리케이션은 정지되면 Status-Control(QC) Request를 로컬 노드에 보내고 QC 요청을 호스트에 보냅니다. 그런 다음, 로컬 노드가 Status-Control(RELQ) Request로 애플리케이션에 제공하는 RELQ 요청을 호스트에서 사용하여 애플리케이션을 해제할 수 있습니다.
CLEAR 또는 UNBIND–BIND 시퀀스를 수신하면 Close(PLU)–Open(PLU) 을 통해 정지된 상태를 해제할 수 있습니다.
다음 세 그림에서는 로컬 노드와 애플리케이션 간의 정지 프로토콜 및 이러한 프로토콜이 기본 SNA 프로토콜과 어떻게 관련되는지를 보여 줍니다.
첫 번째 그림에서 애플리케이션은 호스트를 정지했다가 정지를 해제합니다.
애플리케이션이 호스트를 정지했다가 정지를 해제함
다음 그림에서 애플리케이션은 호스트를 정지하려고 시도하지만, 호스트가 정지를 거부하고 다음 체인을 계속 진행합니다.
애플리케이션이 호스트를 정지하려고 시도하지만, 호스트가 거부하고 다음 체인을 계속 진행함
다음 그림에서는 애플리케이션이 체인을 보내는 동안 호스트가 QEC를 보냅니다. 애플리케이션은 체인을 완료하고 Status-Control(QC) Request를 보냅니다. 호스트는 RELQ를 전송하여 정지를 해제하고 로컬 노드는 애플리케이션에 Status-Control(RELQ) Request를 보낸 다음, 새 체인을 시작합니다.
애플리케이션이 체인을 보내는 동안 호스트가 QEC를 보냄
참고 항목
PLU 연결 열기
PLU 세션
아웃바운드 체이닝
인바운드 체이닝
세그먼트 배달
Brackets
방향
속도 및 청크
데이터 확인 및 거부]
종료 및 정지
복구
애플리케이션에서 시작한 종료
LUSTAT]
응답 시간 모니터 데이터