本節說明撰寫邏輯單元應用（LUA）應用時需考慮的 SNA 資訊。
BIND 檢查
在 LU 會話初始化時，主機會向 LUA 應用程式發送 BIND 訊息，其中包含請求/回應單元（RU）大小等資訊，供 LU 會話使用。 Microsoft®主機整合伺服器會在 RUI_READ 將此訊息回傳給 LUA 應用程式。 LUA 應用程式必須驗證 BIND 上指定的參數是否適用。 申請表有以下選項：
它可以透過發出包含 OK 回應的 BIND RUI_WRITE 來接受 BIND 的現狀。 回應時無法傳送額外的 BIND 資料。
它可以嘗試協商一個或多個 BIND 參數。 （這僅在 BIND 可協商的情況下被允許。）為此，應用程式會發出包含OK回應的 RUI_WRITE ，但包含修改過的BIND作為資料。
它可以透過發出包含負面回應的 RUI_WRITE ，並使用適當的 SNA 感應碼作為資料來拒絕 BIND。
驗證 BIND 參數並確保所有發送的訊息與之一致，是 LUA 應用程式的責任。 然而，以下兩項限制適用：
主機整合伺服器拒絕任何指定的 RUI_WRITE，如果其 RU 長度超過 BIND 中指定的大小。
主機整合伺服器要求 BIND 指定次要 LU 為爭用勝者，錯誤復原由爭用失敗者負責。
備註
如果應用程式會進行任何 BIND 檢查，則必須在 SLI_OPEN 上指定使用 SLI_BIND_ROUTINE。
感謝致詞
主機整合伺服器會記錄主機收到的請求，以將應用程式發送的任何回應與相應請求做對應。 當應用程式發送回應時，主機整合伺服器會將回應與原始請求的資料對應，並釋放與該請求相關的儲存空間。
若主機僅指定例外回應（可發送負面回應但不應發送正面回應），主機整合伺服器仍需保留請求紀錄，以防應用程式隨後發出負面回應。 若應用程式未發送回應，則無法釋放與此請求相關的儲存空間。
因此，主機整合伺服器（Host Integration Server）使 LUA 應用程式能對主機僅有例外回應的請求發出正面回應。 （這稱為禮貌性致謝。）回應不會傳送給主機，但 LUA 會用來清除與請求相關的儲存空間。
備註
申請不需要對每個僅例外回應的請求發送禮貌確認。 為了提高效率，應用程式可以減少回應頻率。 節點將禮貌確認視為對所有先前待處理請求的隱含確認。
區分 SNA 感應碼與其他次要回傳碼
非感知碼的次要回傳碼，其前兩個位元組的值總是為零。
SNA 感應碼的前兩個位元組中必定包含非零值。 第一個位元組給出意義碼類別，第二個位元組則識別該類別中特定的意義碼。 （第三和第四位元組可以包含額外資訊，也可以是零。）
關於 SNA 感應碼的資訊
如果你需要關於回傳感應碼的資訊，請參考
負面反應與SNA感應碼
SNA 感應碼可在以下情況下回傳至 LUA 應用程式：
當主機對 LUA 應用程式的請求發送負面回應時，會包含一個 SNA 感知碼，指示否定回應的原因。 這些資訊會在後續的 RUI_READ 或 SLI_RECEIVE 時回報給應用程式。
感官代碼 說明 主要返回代碼 LUA_OK。 請求/回應指示器、回應類型指示器及包含感測資料的指示器 全部設為1，表示包含感官資料的負面反應。 傳回的數據 即SNA感應碼。 當主機整合伺服器收到主機的無效資料時，通常會向主機發送負面回應，且不會將無效資料傳給 LUA 應用程式。 此資訊會在後續的 RUI_READ、SLI_RECEIVE、 RUI_BID或SLI_BID 中報告給申請表，並附有以下資訊：
感官代碼 說明 主要返回代碼 LUA_NEGATIVE_RESPONSE。 次要回傳代碼 SNA 感應碼傳送給主機。 在某些情況下，主機整合伺服器偵測到主機提供的資料無效，但無法判斷正確的感應碼。 此時，它會以異常請求（EXR）將無效資料傳給 LUA 應用程式，並附上以下資訊 RUI_READ 或 SLI_RECEIVE 。
感官代碼 說明 請求/回應指示器 設為 0，表示有請求。 感測數據包含指標 設為 1，表示包含感官資料。 （此指示器通常僅用於回應。） 訊息資料 建議的SNA感應代碼。 應用程式必須對訊息發出否定回應。 它可以使用主機整合伺服器建議的感知碼，或是修改感應碼。
主機整合伺服器可以傳送感應碼給應用程式，表示應用程式所提供的資料無效。 此資訊會在 RUI_WRITE 或 SLI_SEND 報告給應用程式。
感官代碼 說明 主要返回代碼 LUA_UNSUCCESSFUL 次要回傳代碼 SNA 感應代碼。 可作為 LUA 動詞次要回傳碼的意義碼列於 WINLUA.H 標頭檔案中。 關於此檔案，請參閱主機整合伺服器（Host Integration Server，簡稱 SNA SDK）。
節奏
節奏控制由 LUA 介面負責。 LUA 應用程式不需要控制節奏，也絕不應該設定節奏指示標誌。
若 LUA 應用程式傳送至主機的資料使用節流（由 BIND 決定），RUI_WRITE 或 SLI_SEND 可能需要一些時間才能完成。 這是因為 LUA 必須等待主機的節奏回應，才能傳送更多資料。
如果 LUA 應用程式單向傳輸大量資料，無論是傳送到主機還是從主機（例如檔案傳輸應用程式），主機設定應指定該方向使用流量控制。 這確保接收資料的節點不會被資料淹沒，也不會耗盡資料儲存空間。
清除資料至鏈尾
當主機向 LUA 應用程式發送一連串請求單元時，該應用程式可以等待收到鏈中最後一個 RU 後再發送回應，或是向非鏈中最後一個 RU 發送負面回應。 若在鏈中途被傳送負面回應，LUA 會清除該鏈中所有後續的 RU，且不會將這些 RU 送回應用程式。
當 LUA 收到鏈中最後一個 RU 時，會透過將 RUI_READ 或 RUI_BID 的主要回傳碼設為 LUA_NEGATIVE_RESPONSE，並設定為零次要回傳碼來通知應用程式。
主機可以在鏈中發送如 CANCEL 等訊息來終止該鏈。 此時，CANCEL 訊息會在 RUI_READ 回傳給應用程式。 LUA_NEGATIVE_RESPONSE回傳代碼未被使用。
分割
RU的分段由LUA介面處理。 LUA 總是將完整的 RU 傳給應用程式，而應用程式也應該把完整的 RU 傳給 LUA。