다음을 통해 공유


인바운드 데이터

이 섹션에서는 애플리케이션에서 로컬 노드로의 인바운드 데이터 흐름에 대해 설명합니다. 설명된 프로토콜의 전체 구조는 SSCP(시스템 서비스 제어 지점) 및 PLU(기본 논리 단위) 연결에 적용되지만 보다 복잡한 측면(예: 지연된 요청 모드의 사용)은 PLU 연결에만 적용됩니다.

애플리케이션은 다음과 같이 모든 연결에서 인바운드 데이터를 보낼 수 있습니다.

  • 호스트 SSCP용으로 문자 코드된 FMD NS(함수 관리 데이터 네트워크 서비스)(세션 서비스) 및 FMD(함수 관리 데이터) 데이터는 SSCP 연결의 로컬 노드로 전송되어야 합니다.

  • 호스트 PLU용 FMD 데이터는 PLU 연결의 로컬 노드로 전송되어야 합니다.

    애플리케이션은 Data 메시지를 사용하여 DFC(데이터 흐름 제어) 또는 세션 제어 요청 메시지를 호스트로 보낼 수 없습니다. 대신 Status-Control 메시지를 사용해야 합니다. 자세한 내용은 Status-Control 메시지를 참조하세요.

    모든 연결에 대해 애플리케이션은 Data 메시지 헤더의 특정 키 필드를 채워야 합니다. 특히 다음을 수행해야 합니다.

  • message-type을 DATAFMI로 설정합니다.

  • 이 연결의 인바운드 Data 메시지에 대해 새 메시지 키를 할당합니다.

  • 필요한 경우 ACKRQD 필드를 설정합니다.

  • 애플리케이션 플래그를 설정합니다. 자세한 내용은 애플리케이션 플래그를 참조하세요.

    메시지 헤더의 nxtqptr, hdreptr, numelts 필드와 메시지 요소의 elteptrstartd 필드는 Host Integration Server 버퍼 관리 루틴에 따라 설정됩니다. 자세한 내용은 DL-BASE/DMOD 인터페이스를 참조하세요. 애플리케이션은 endd 필드를 설정해야 합니다.

    애플리케이션이 이러한 루틴에 액세스할 수 없는 경우(예: 운영 환경에서 작업 간 프로시저 호출 및 공유 메모리를 지원하지 않는 경우) 헤더의 모든 필드를 애플리케이션에서 설정해야 합니다.

    TH(전송 헤더) 및 RH(응답 헤더) 표시기는 애플리케이션에서 인바운드 Data 메시지에 사용할 수 없습니다. 애플리케이션은 메시지 헤더에서 적절한 애플리케이션 플래그를 설정하여 체이닝, 방향 등을 제어해야 합니다. 인바운드 데이터에 사용 가능한 애플리케이션 플래그에 대한 설명과 이 섹션의 뒷부분에 나오는 플래그를 사용하여 인바운드 데이터 흐름을 제어하는 방법에 대한 자세한 내용은 애플리케이션 플래그를 참조하세요.

    인바운드 데이터에서는 첫 번째 바이트가 표준 FMI(함수 관리 인터페이스)에 대한 RU[0]입니다.

    인바운드 Data 메시지 헤더에서 애플리케이션이 제공한 메시지 키는 아웃바운드 Status-Acknowledge가 참조하는 이 연결의 Data 메시지를 나타내기 위해 로컬 노드에서 사용됩니다. 애플리케이션은 로컬 노드와의 각 연결에서 인바운드 데이터 흐름에 대해 고유한 메시지 키 시퀀스를 유지 관리해야 하므로 애플리케이션은 메시지 키를 사용하여 연결에서 인바운드 Data 메시지와 아웃바운드 Status-Acknowledge 메시지를 상호 연결할 수 있습니다. 또한 애플리케이션은 Status-Control Request 메시지에서 메시지 키를 제공하여 여러 RQE LUSTAT 메시지를 구분해야 합니다.

    인바운드 데이터 승인 프로토콜에는 다음과 같이 세션에서 사용 중인 보조 체인 응답 프로토콜 및 요청 모드가 반영됩니다.

  • 헤더에 ACKRQD가 설정된 인바운드 Data 메시지는 RQD 요청을 생성합니다.

  • 헤더에 ACKRQD가 설정되지 않은 인바운드 Data 메시지는 체인 응답 프로토콜에 따라 RQE 또는 RQN 요청을 생성합니다.

  • 애플리케이션은 ECI(끝 체인 표시기) 애플리케이션 플래그가 설정된 Data 메시지에서만 ACKRQD를 설정해야 합니다.

  • 세션에서 보조가 즉시 요청 모드를 사용하도록 지정하는 경우 애플리케이션은 해당 Data 메시지에 대한 Status-Acknowledge 메시지를 받지 않은 경우에도 ACKRQD가 설정된 추가 Data 메시지를 계속 보낼 수 있습니다. 메시지는 로컬 노드 내에서 큐에 대기되며 긍정 응답을 수신하면 점진적으로 전송됩니다.

  • 세션에서 보조가 지연된 요청 모드를 사용하도록 지정하면 ACKRQD가 설정된 Data 메시지를 보낸 후에도 애플리케이션은 Data 메시지를 계속 보낼 수 있습니다.

    애플리케이션이 Data 메시지의 메시지 헤더에 ACKRQD 필드를 설정하면 이 Data 메시지에 대한 승인이 필요함을 나타냅니다. 로컬 노드는 동일한 연결에서 애플리케이션에 Status-Acknowledge 메시지를 보내고 Data 메시지와 동일한 메시지 키를 사용하여 인바운드 Data 메시지를 승인합니다. 자세한 내용은 이 항목의 끝 부분에 있는 첫 번째 그림을 참조하세요.

    로컬 노드는 내부 상태 컴퓨터를 통해 애플리케이션의 인바운드 Data 메시지를 처리하고 이 흐름에 올바른 SNA 시퀀스 번호나 식별자를 할당하며 요청의 데이터를 호스트로 보냅니다. 요청의 체인-응답 형식은 ACKRQDData 메시지에서 설정되었는지, 세션 매개 변수에서 설정되었는지에 따라 달라집니다.

    로컬 노드는 호스트의 긍정 응답을 애플리케이션에 대한 Status-Acknowledge(Ack)에 매핑합니다. 애플리케이션은 Status-Acknowledge의 메시지 키를 사용하여 승인을 원래 Data 메시지와 상호 연결할 수 있습니다. 따라서 특정 Data 메시지에 대한 Status-Acknowledge(Ack) 수신은 로컬 노드가 호스트로부터 인바운드 SNA 요청에 대해 긍정 SNA 응답을 받았음을 의미합니다. 자세한 내용은 이 항목의 끝 부분에 있는 두 번째 그림을 참조하세요.

    응답은 SSCP-PU 세션에 흡수됩니다.

    아웃바운드 Status-Acknowledge(Ack) 메시지에는 애플리케이션 플래그와 시퀀스 번호가 포함됩니다. 애플리케이션 플래그는 응답에 RH 표시기를 반영합니다. 시퀀스 번호는 응답의 SNA 시퀀스 번호이며, TS 프로필(전송 서비스 프로필) 4를 사용하여 작업 단위에 해당하는 SNA 보조 시퀀스 번호를 추적하는 메커니즘을 애플리케이션에 제공합니다.

    로컬 노드는 호스트의 부정 응답을 애플리케이션에 대한 Status-Acknowledge(Nack-1) 메시지에 매핑합니다. 애플리케이션은 Status-Acknowledge의 메시지 키를 사용하여 부정 승인을 원래 Data 메시지와 상호 연결할 수 있습니다. 아웃바운드 Status-Acknowledge(Nack-1) 메시지에는 부정 응답의 SNA 센스 코드와 시퀀스 번호가 포함됩니다. 자세한 내용은 이 항목의 끝 부분에 있는 세 번째 및 네 번째 그림을 참조하세요.

    로컬 노드가 인바운드 Data 메시지 형식의 오류를 검색하거나 Data 메시지가 세션의 현재 상태에 적합하지 않은 경우 오류 코드를 포함하여 Status-Acknowledge(Nack-2)를 애플리케이션에 보냅니다. 오류 코드 목록은 오류 및 센스 코드를 참조하세요. 로컬 노드는 오류의 Data 메시지에 해당하는 요청을 호스트에 보내지 않으며 세션에 대한 SNA 시퀀스 번호를 미리 보내지 않습니다. 애플리케이션은 다음 인바운드 Data 메시지의 모든 메시지 키를 사용할 수 있습니다(오류가 심각한 오류를 발생시키지 않는다고 가정).

    애플리케이션이 애플리케이션 플래그에 ACKRQD는 있지만 ECI는 없는 Data 메시지를 보내는 심각한 체이닝 오류의 예는 이 항목의 끝 부분에 있는 마지막 그림에 표시되어 있습니다. 이 특정 오류를 검색하면 로컬 노드는 애플리케이션의 연결을 심각하게 실패한 것으로 표시하고 연결을 닫은 다음, SSCP에 TERM-SELF 요청을 전송하여 UNBIND를 유도합니다. 자세한 내용은 복구를 참조하세요.

    긴급 흐름 요청이 생성되도록 하는 인바운드 Status-Control 메시지는 언제든지 보낼 수 있으며 인바운드 Data 메시지에 대한 긍정 승인이나 부정 승인 보내기에 영향을 주지 않습니다. SNA 긴급 흐름 요청에 해당하는 Status-Control 메시지에 대한 자세한 내용은 Status-Control 메시지를 참조하세요.

    다음 5개의 그림에서는 다양한 체인-응답 형식 및 보조 세션 요청 모드에 대한 인바운드 데이터 승인 프로토콜 및 기본 SNA 프로토콜의 예를 보여 줍니다.

    그림에서는 다음을 보여 줍니다.

  • Data 메시지의 ACKRQD 필드.

  • Data 메시지의 메시지 키.

  • Data 메시지의 관련 애플리케이션 플래그.

  • Data 메시지의 오류 코드(“ERROR=...”로 표시됨).

  • SNA 요청/응답의 관련 RH 플래그.

  • SNA 요청/응답의 시퀀스 번호.

  • SNA 요청/응답의 센스 코드(“SENSE=....”로 표시됨).

    편의상 모든 메시지가 동일한 PLU 세션에서 이동하는 것으로 가정합니다.

    다음 그림에서 애플리케이션은 Data 메시지를 성공적으로 보냅니다.

    애플리케이션이 데이터 메시지를 성공적으로 보내는 방법을 보여 주는 이미지입니다.
    Data 메시지를 성공적으로 보내는 애플리케이션

    다음 그림에서 애플리케이션은 Data 메시지 체인을 성공적으로 보냅니다.

    애플리케이션이 데이터 메시지 체인을 성공적으로 보내는 방법을 보여 주는 이미지입니다.
    Data 메시지 체인을 성공적으로 보내는 애플리케이션

    다음 그림에서 호스트는 Data 메시지 체인을 거부합니다.

    호스트가 데이터 메시지 체인을 거부하는 방법을 보여 주는 이미지입니다.
    Data 메시지 체인을 거부하는 호스트

    다음 그림에서 호스트는 첫 번째 명확한 응답 체인을 거부하고 지연된 요청 세션에서 세 번째 예외 응답 체인을 거부합니다. 세 번째 체인에 대한 부정 응답은 두 번째 체인에 대한 긍정 응답을 의미합니다.

    호스트가 첫 번째 명확한 응답 체인을 거부하는 방법을 보여 주는 이미지입니다.
    첫 번째 명확한 응답 체인을 거부하는 호스트

    다음 그림에서 로컬 노드는 Data 메시지에 ECI 애플리케이션 플래그가 없는 애플리케이션의 잘못된 ACKRQD 사용을 검색합니다. 데이터가 호스트에 전송되지 않습니다. 하지만 심각한 오류이기 때문에 로컬 노드에서 TERM-SELF 메시지를 SSCP에 보냅니다.

    로컬 노드가 데이터 메시지에서 ECI 애플리케이션 플래그 없이 애플리케이션의 잘못된 ACKRDQ 사용을 검색하는 방법을 보여 주는 이미지입니다.
    Data 메시지에 ECI 애플리케이션 플래그가 없는 애플리케이션의 잘못된 ACKRDQ 사용을 검색하는 로컬 노드

참고 항목

아웃바운드 데이터
LUA 애플리케이션의 인바운드 데이터