Considerazioni su SNA con LUA
In questa sezione vengono descritte le informazioni SNA da considerare per la scrittura di applicazioni di unità logica .
Controllo BIND
Durante l'inizializzazione della sessione LU, l'host invia all'applicazione LUA un messaggio BIND che contiene informazioni come le dimensioni di unità richiesta/risposta (UR) da usare dalla sessione LU. Microsoft® Host Integration Server restituisce questo messaggio all'applicazione LUA in RUI_READ. L'applicazione LUA deve verificare che i parametri specificati in BIND siano adatti. L'applicazione include le opzioni seguenti:
Può accettare bind così come è, eseguendo RUI_WRITE contenente una risposta OK a BIND. Non è possibile inviare dati BIND aggiuntivi nella risposta.
Può provare a negoziare uno o più parametri BIND. Questa opzione è consentita solo se BIND è negoziabile. A tale scopo, l'applicazione genera RUI_WRITE contenente una risposta OK, ma include l'associazione modificata come dati.
Può rifiutare BIND eseguendo RUI_WRITE contenente una risposta negativa, usando un codice SNA sense appropriato come dati.
La convalida dei parametri BIND e la verifica che tutti i messaggi inviati siano coerenti con essi è responsabilità dell'applicazione LUA. Tuttavia, si applicano le due restrizioni seguenti:
Host Integration Server rifiuta qualsiasi RUI_WRITE che specifica una lunghezza di UR maggiore della dimensione specificata in BIND.
Host Integration Server richiede a BIND di specificare che l'lu secondario è il vincitore della contesa e che il ripristino degli errori è responsabilità del perdente della contesa.
Nota
Per SLI, un'applicazione deve specificare che userà SLI_BIND_ROUTINE nel SLI_OPEN se eseguirà un controllo BIND.
Riconoscimenti di cortesia
Host Integration Server mantiene un record di richieste ricevute dall'host per correlare qualsiasi risposta inviata dall'applicazione con la richiesta appropriata. Quando l'applicazione invia una risposta, Host Integration Server correla la risposta con i dati della richiesta originale e può quindi liberare l'archiviazione associata.
Se l'host specifica solo la risposta di eccezione (è possibile inviare una risposta negativa ma non deve essere inviata una risposta positiva), Host Integration Server deve comunque mantenere un record della richiesta nel caso in cui l'applicazione invii successivamente una risposta negativa. Se l'applicazione non invia una risposta, l'archiviazione associata a questa richiesta non può essere liberata.
Per questo motivo, Host Integration Server consente all'applicazione LUA di emettere una risposta positiva a una richiesta di sola risposta di eccezione dall'host. Questa operazione è nota come riconoscimento di cortesia. La risposta non viene inviata all'host, ma viene usata da LUA per cancellare lo spazio di archiviazione associato alla richiesta.
Nota
L'applicazione non deve inviare un riconoscimento di cortesia per ogni richiesta di sola risposta all'eccezione. Per garantire l'efficienza, l'applicazione può rispondere meno frequentemente. Il nodo considera un riconoscimento di cortesia come un riconoscimento implicito per tutte le richieste in sospeso precedenti.
Distinguere i codici di senso SNA da altri codici restituiti secondari
Un codice restituito secondario che non è un codice sensato contiene sempre un valore pari a zero nei primi due byte.
Un codice di senso SNA contiene sempre un valore diverso da zero nei primi due byte. Il primo byte fornisce la categoria di codice sense e la seconda identifica un codice sense specifico all'interno di tale categoria. Il terzo e il quarto byte possono contenere informazioni aggiuntive o possono essere zero.
Informazioni sui codici di senso SNA
Se sono necessarie informazioni su un codice sense restituito, vedere
Risposte negative e codici di senso SNA
I codici di senso SNA possono essere restituiti a un'applicazione LUA nei casi seguenti:
Quando l'host invia una risposta negativa a una richiesta dall'applicazione LUA, include un codice di senso SNA che indica il motivo della risposta negativa. Questo viene segnalato all'applicazione in un RUI_READ o SLI_RECEIVE successivo con le informazioni seguenti.
Codice Sense Descrizione Codice restituito primario LUA_OK. Indicatore di richiesta/risposta, indicatore del tipo di risposta e dati di senso inclusi Tutti impostati su 1, che indica una risposta negativa che include dati di senso. Dati restituiti Codice senso SNA. Quando Host Integration Server riceve dati non validi dall'host, in genere invia una risposta negativa all'host e non passa i dati non validi all'applicazione LUA. Viene segnalato all'applicazione in un RUI_READ,SLI_RECEIVE, RUI_BID oSLI_BID successive con le informazioni seguenti:
Codice Sense Descrizione Codice restituito primario LUA_NEGATIVE_RESPONSE. Codice restituito secondario Codice del senso SNA inviato all'host. In alcuni casi, Host Integration Server rileva che i dati forniti dall'host non sono validi, ma non possono determinare il codice appropriato da inviare. In questo caso, passa i dati non validi in una richiesta di eccezione (EXR) all'applicazione LUA in RUI_READ o SLI_RECEIVE con le informazioni seguenti.
Codice Sense Descrizione Indicatore di richiesta/risposta Impostare su 0, che indica una richiesta. Indicatore di rilevamento dei dati inclusi Impostare su 1, a indicare che i dati di rilevamento sono inclusi. Questo indicatore viene in genere usato solo per una risposta. Dati del messaggio Codice di senso SNA suggerito. L'applicazione deve quindi inviare una risposta negativa al messaggio. Può usare il codice sense suggerito da Host Integration Server oppure può modificare il codice sense.
Host Integration Server può inviare un codice sense all'applicazione per indicare che i dati forniti dall'applicazione non sono validi. Questo viene segnalato all'applicazione in RUI_WRITE o SLI_SEND con le informazioni seguenti.
Codice Sense Descrizione Codice restituito primario LUA_UNSUCCESSFUL. Codice restituito secondario Codice senso SNA. I codici di senso che possono essere restituiti come codici restituiti secondari nei verbi LUA sono elencati in WINLUA. File di intestazione H. Per questo file, vedere Host Integration Server o SNA SDK.
Stimolazione
Il ritmo viene gestito dall'interfaccia LUA. Un'applicazione LUA non deve controllare il ritmo e non deve mai impostare il flag indicatore di avanzamento.
Se la pacing viene usata sui dati inviati dall'applicazione LUA all'host (determinato da BIND), RUI_WRITE o SLI_SEND potrebbero richiedere del tempo. Ciò è dovuto al fatto che LUA deve attendere una risposta di ritmo dall'host prima che possa inviare altri dati.
Se un'applicazione LUA trasferisce grandi quantità di dati in una direzione, all'host o dall'host (ad esempio, un'applicazione di trasferimento file), la configurazione host deve specificare che la velocità viene usata in tale direzione. Ciò garantisce che il nodo che riceve i dati non venga inondato con i dati e non esaurisca l'archiviazione dei dati.
Eliminazione dei dati alla fine della catena
Quando l'host invia una catena di unità richiesta a un'applicazione LUA, l'applicazione può attendere la ricezione dell'ultima UR nella catena prima di inviare una risposta oppure può inviare una risposta negativa a un UR che non è l'ultima nella catena. Se viene inviata una risposta negativa, LUA elimina tutte le UR successive da questa catena e non le invia all'applicazione.
Quando l'unità lua riceve l'ultima UR nella catena, indica tale valore all'applicazione impostando il codice restituito primario di RUI_READ o RUI_BID su LUA_NEGATIVE_RESPONSE con zero codice restituito secondario.
L'host può terminare la catena inviando un messaggio, ad esempio CANCEL, mentre è a metà catena. In questo caso, il messaggio CANCEL viene restituito all'applicazione in RUI_READ. Il codice restituito LUA_NEGATIVE_RESPONSE non viene usato.
Segmentazione
La segmentazione delle UR viene gestita dall'interfaccia LUA. LUA passa sempre le UR complete all'applicazione e l'applicazione deve passare le UR complete a LUA.