이 섹션에서는 애플리케이션에서 로컬 노드로의 인바운드 데이터 흐름에 대해 설명합니다. 설명된 프로토콜의 전체 구조는 시스템 서비스 제어 지점(SSCP) 및 PLU(기본 논리 단위) 연결에 적용되지만 더 복잡한 측면(예: 지연된 요청 모드 사용)은 PLU 연결에만 적용됩니다.
애플리케이션은 다음과 같이 모든 연결에서 인바운드 데이터를 보낼 수 있습니다.
호스트 SSCP용으로 지정된 FMD NS(함수 관리 데이터 네트워크 서비스)(세션 서비스) 및 FMD(함수 관리 데이터) 문자로 코딩된 데이터를 SSCP 연결의 로컬 노드로 보내야 합니다.
호스트 PLU용 FMD 데이터를 PLU 연결의 로컬 노드로 보내야 합니다.
애플리케이션은 데이터 메시지를 사용하여 DFC(데이터 흐름 제어) 또는 세션 제어 요청 메시지를 호스트에 보낼 수 없습니다. 대신 상태 제어 메시지를 사용해야 합니다. 자세한 내용은 Status-Control 메시지를 참조하세요.
모든 연결의 경우 애플리케이션은 데이터 메시지 헤더의 특정 키 필드를 입력해야 합니다. 특히 다음을 수행해야 합니다.
메시지 유형을 DATAFMI로 설정합니다.
이 연결에서 인바운드 데이터 메시지에 대한 새 메시지 키를 할당합니다.
필요한 경우 ACKRQD 필드를 설정합니다.
애플리케이션 플래그를 설정합니다. (자세한 내용은 애플리케이션 플래그를 참조하세요.)
메시지 헤더의 nxtqptr, hdreptr 및 numelts 필드와 메시지 요소의 elteptr 및 시작 필드는 Host Integration Server 버퍼 관리 루틴에 의해 설정됩니다. (자세한 내용은 DL-BASE/DMOD 인터페이스를 참조하세요.) 애플리케이션은 endd 필드를 설정합니다.
애플리케이션이 이러한 루틴에 액세스할 수 없는 경우(예: 운영 환경에서 작업 프로시저 호출 및 공유 메모리를 지원하지 않는 경우) 헤더의 모든 필드를 애플리케이션에서 설정해야 합니다.
TH(전송 헤더) 및 RH(응답 헤더) 표시기를 인바운드 데이터 메시지의 애플리케이션에서 사용할 수 없습니다. 애플리케이션은 메시지 헤더에 적절한 애플리케이션 플래그를 설정하여 연결, 방향 등을 제어해야 합니다. 인바운드 데이터 및 인바운드 데이터 흐름을 제어하는 데 플래그를 사용하는 방법에 대한 설명은 이 섹션의 이후 항목에 사용할 수 있는 애플리케이션 플래그에 대한 설명을 보려면 Application Flags를 참조하세요.
인바운드 데이터의 경우 첫 번째 바이트는 표준 FMI(함수 관리 인터페이스)용 RU[0]입니다.
인바운드 데이터 메시지 헤더의 애플리케이션에서 제공하는 메시지 키는 아웃바운드 Status-Acknowledge가 참조하는 이 연결의 데이터 메시지를 나타내기 위해 로컬 노드에서 사용됩니다. 애플리케이션은 로컬 노드와의 각 연결에서 인바운드 데이터 흐름에 대한 고유한 메시지 키 시퀀스를 유지 관리해야 하므로 애플리케이션은 메시지 키를 사용하여 인바운드 데이터 메시지와 아웃바운드 상태-승인 메시지의 상관 관계를 연결할 수 있습니다. 또한 애플리케이션은 여러 RQE LUSTAT 메시지를 구분하기 위해 Status-Control 요청 메시지에 메시지 키를 제공해야 합니다.
인바운드 데이터 승인 프로토콜은 다음과 같이 세션에서 사용 중인 보조 체인 응답 프로토콜 및 요청 모드를 반영합니다.
헤더에 ACKRQD가 설정된 인바운드 데이터 메시지는 RQD 요청을 생성합니다.
헤더에 ACKRQD가 설정되지 않은 인바운드 데이터 메시지는 체인 응답 프로토콜에 따라 RQE 또는 RQN 요청을 생성합니다.
애플리케이션은 ECI(끝 체인 표시기) 애플리케이션 플래그가 설정된 데이터 메시지에 대해서만 ACKRQD를 설정해야 합니다.
세션에서 보조가 즉각적인 요청 모드를 사용하도록 지정하는 경우 애플리케이션은 해당 데이터 메시지에 대한 Status-Acknowledge 메시지를 받지 않았더라도 ACKRQD 집합으로 데이터를 보낸 후에도 추가 데이터 메시지를 보낼 수 있습니다. 메시지는 로컬 노드 내에서 큐에 대기되고 긍정적인 응답이 수신되면 점진적으로 전송됩니다.
세션에서 보조 데이터베이스가 지연된 요청 모드를 사용하도록 지정하는 경우 ACKRQD가 설정된 데이터 메시지를 보낸 후에도 애플리케이션은 데이터 메시지를 계속 보낼 수 있습니다.
애플리케이션이 데이터 메시지의 메시지 헤더에 ACKRQD 필드를 설정하는 경우 이 데이터 메시지에 대한 승인이 필요하다는 것을 나타냅니다. 로컬 노드는 동일한 연결에서 애플리케이션에 Status-Acknowledge 메시지를 보내고 데이터 메시지와 동일한 메시지 키를 사용하여 인바운드 데이터 메시지를 승인합니다. (그림의 경우 이 항목의 끝에 있는 첫 번째 그림을 참조하세요.)
로컬 노드는 내부 상태 컴퓨터를 통해 애플리케이션에서 인바운드 데이터 메시지를 처리하고, 이 흐름에 대한 올바른 SNA 시퀀스 번호 또는 식별자를 할당하고, 요청의 데이터를 호스트에 보냅니다. 요청의 체인 응답 형식은 데이터 메시지 및 세션 매개 변수에서 ACKRQD가 설정되었는지 여부에 따라 달라집니다.
로컬 노드는 호스트에서 온 긍정적인 응답을 Status-Acknowledge(Ack)로 애플리케이션에 매핑합니다. 애플리케이션은 Status-Acknowledge 의 메시지 키를 사용하여 승인과 원본 데이터 메시지의 상관 관계를 지정할 수 있습니다. 따라서 특정 데이터 메시지에 대한 Status-Acknowledge(Ack)를 수신하면 로컬 노드가 호스트에서 인바운드 SNA 요청으로 긍정적인 SNA 응답을 수신했음을 의미합니다. (그림의 경우 이 항목의 끝에 있는 두 번째 그림을 참조하세요.)
응답은 SSCP-PU 세션에서 흡수됩니다.
아웃바운드 Status-Acknowledge(Ack) 메시지에는 애플리케이션 플래그와 시퀀스 번호가 포함됩니다. 애플리케이션 플래그는 응답에 RH 지표를 반영합니다. 시퀀스 번호는 응답의 SNA 시퀀스 번호이며, TS 프로필(Transmission Service profile) 4를 사용하는 애플리케이션이 작업 단위에 해당하는 SNA 보조 시퀀스 번호를 추적하는 메커니즘을 제공합니다.
로컬 노드는 호스트의 음수 응답을 Status-Acknowledge(Nack-1) 메시지에 애플리케이션에 매핑합니다. 애플리케이션은 Status-Acknowledge 의 메시지 키를 사용하여 부정 승인과 원본 데이터 메시지의 상관 관계를 지정할 수 있습니다. 아웃바운드 Status-Acknowledge(Nack-1) 메시지에는 음수 응답의 SNA 감지 코드와 시퀀스 번호가 포함됩니다. (그림의 경우 이 항목의 끝에 있는 세 번째 및 네 번째 그림을 참조하세요.)
로컬 노드가 인바운드 데이터 메시지 형식의 오류를 감지하거나 데이터 메시지가 세션의 현재 상태에 적합하지 않은 경우 오류 코드가 포함된 애플리케이션에 Status-Acknowledge(Nack-2) 를 보냅니다. (오류 코드 목록은 오류 및 감지 코드를 참조하세요.) 로컬 노드는 오류로 데이터 메시지에 해당하는 호스트에 요청을 보내지 않으며 세션에 대한 SNA 시퀀스 번호를 진행하지 않습니다. 애플리케이션은 다음 인바운드 데이터 메시지에서 메시지 키를 사용할 수 있습니다(오류가 심각한 오류를 일으키지 않는다고 가정).
애플리케이션이 ACKRQD를 사용하지만 애플리케이션 플래그에 ECI가 없는 데이터 메시지를 보내는 심각한 연결 오류의 예는 이 항목의 마지막 그림에 나와 있습니다. 이 특정 오류를 감지한 후 로컬 노드는 애플리케이션의 연결을 심각하게 실패한 것으로 표시하고, 연결을 닫고, UNBIND를 유도하기 위해 SSCP에 TERM-SELF 요청을 보냅니다. (자세한 내용은 복구를 참조 하세요.)
신속한 흐름 요청 생성을 유발하는 인바운드 상태 제어 메시지는 언제든지 전송될 수 있으며 인바운드 데이터 메시지에 대한 긍정 또는 부정 승인 전송에는 영향을 주지 않습니다. SNA 긴급 흐름 요청에 해당하는 상태 제어 메시지에 대한 자세한 내용은 Status-Control 메시지를 참조하세요.
다음 5개 그림에서는 다양한 체인 응답 형식 및 보조 세션 요청 모드에 대한 인바운드 데이터 승인 프로토콜(및 기본 SNA 프로토콜)의 예를 보여 줍니다.
수치는 다음과 같습니다.
데이터 메시지의 ACKRQD 필드입니다.
데이터 메시지의 메시지 키 입니다 .
데이터 메시지에 대한 모든 관련 애플리케이션 플래그입니다.
데이터 메시지의 오류 코드("ERROR=..."로 표시됨).
SNA 요청/응답에 대한 관련 RH 플래그입니다.
SNA 요청/응답의 시퀀스 번호입니다.
SNA 요청/응답에 대한 감지 코드("SENSE=...."로 표시)입니다.
간단히 하기 위해 모든 메시지는 동일한 PLU 세션에서 흐르는 것으로 간주됩니다.
다음 그림에서 애플리케이션은 데이터 메시지를 성공적으로 보냅니다.
애플리케이션이 데이터 메시지를 성공적으로 보냅니다.다음 그림에서 애플리케이션은 데이터 메시지 체인을 성공적으로 보냅니다.
애플리케이션이 데이터 메시지 체인을 성공적으로 보냅니다.다음 그림에서 호스트는 데이터 메시지 체인을 거부합니다.
호스트가 데이터 메시지 체인을 거부합니다.다음 그림에서 호스트는 첫 번째 명확한 응답 체인을 거부하고 지연된 요청 세션에서 세 번째 예외 응답 체인을 거부합니다. 세 번째 체인에 대한 부정적인 응답은 두 번째 체인에 대한 긍정적인 응답을 의미합니다.
호스트가 첫 번째 명확한 응답 체인을 거부합니다.다음 그림에서 로컬 노드는 데이터 메시지에 대한 ECI 애플리케이션 플래그 없이 애플리케이션의 잘못된 ACKRQD 사용을 검색합니다. 호스트에 데이터가 전송되지 않습니다. 그러나 오류가 중요하기 때문에 로컬 노드는 TERM-SELF 메시지를 SSCP에 보냅니다.
로컬 노드가 데이터 메시지에서 ECI 애플리케이션 플래그 없이 애플리케이션이 ACKRDQ를 잘못 사용하는 것을 감지합니다.