Considerazioni su SNA con LUA

Questa sezione illustra le informazioni di SNA che è necessario prendere in considerazione durante la scrittura di applicazioni luA (Logical Unit Application).

Controllo BIND

Durante l'inizializzazione della sessione lu, l'host invia all'applicazione LUA un messaggio BIND che contiene informazioni quali 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 offre le opzioni seguenti:

• Può accettare bind così come è, eseguendo RUI_WRITE contenente una risposta OK a BIND. Nella risposta non è possibile inviare dati BIND aggiuntivi.

• Può provare a negoziare uno o più parametri BIND. Questa opzione è consentita solo se BIND è negoziabile. A tale scopo, l'applicazione emette RUI_WRITE contenente una risposta OK, ma includendo il BIND modificato come dati.

• Può rifiutare il bind eseguendo RUI_WRITE contenente una risposta negativa, usando un codice senso SNA appropriato come dati.

  Convalidare i parametri BIND e assicurarsi 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 il BIND per specificare che la LU secondaria è il vincitore della contenione e che il recupero degli errori è responsabilità del perdente della contenione.

  Annotazioni

  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 mette in correlazione la risposta con i dati della richiesta originale e può quindi liberare lo spazio di archiviazione associato.

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.

Distinguere i codici di senso SNA da altri codici di ritorno secondari

Un codice restituito secondario che non è un codice sense 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 di senso specifico all'interno di tale categoria. Il terzo e il quarto byte possono contenere informazioni aggiuntive o possono essere pari a zero.

Informazioni sui codici dei sensi SNA

Per informazioni su un codice di senso restituito, consultare

• Messaggio di errore di stato

• Codici di errore e di stato

Risposte negative e codici di senso SNA

I codici 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 Sensore	Descrizione
  Codice di ritorno primario	LUA_OK.
  Indicatore di richiesta/risposta, indicatore del tipo di risposta e indicatore di senso inclusi	Tutto impostato su 1, che indica una risposta negativa che include dati di rilevamento.
  Dati restituiti	Codice del 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. Questo viene segnalato all'applicazione in un RUI_READ, SLI_RECEIVE, RUI_BID oSLI_BID successivo con le informazioni seguenti:

  Codice Sensore	Descrizione
  Codice di ritorno primario	LUA_NEGATIVE_RESPONSE.
  Codice di ritorno secondario	Codice di rilevamento SNA inviato al server.

• In alcuni casi, Host Integration Server rileva che i dati forniti dall'host non sono validi, ma non possono determinare il codice di senso corretto 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 Sensore	Descrizione
  Indicatore di richiesta/risposta	Impostare a 0, indicando una richiesta.
  Indicatore dei dati sensoriali incluso	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 del 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 Sensore	Descrizione
  Codice di ritorno primario	LUA_UNSUCCESSFUL.
  Codice di ritorno secondario	Codice di senso SNA.

  I codici di errore che possono essere restituiti come codici di ritorno secondari nei comandi LUA sono elencati nel file di intestazione WINLUA.H. Per questo file, vedere Host Integration Server o SNA SDK.

Controllo del ritmo

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 regolazione del flusso sia utilizzata sui dati inviati dall'applicazione LUA all'host (determinato da BIND), RUI_WRITE o SLI_SEND potrebbero richiedere del tempo per completarsi. 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 di file), la configurazione host deve specificare che la velocità viene usata in tale direzione. In questo modo il nodo che riceve i dati non viene inondato di dati e non esaurisce 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 fino a quando non viene ricevuta l'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 LUA riceve l'ultima UR nella catena, indica questa situazione 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 si trova a metà catena. In questo caso, il messaggio CANCEL viene restituito all'applicazione in RUI_READ. Il codice di ritorno LUA_NEGATIVE_RESPONSE non viene usato.

Segmentazione

La segmentazione delle UR viene gestita dall'interfaccia LUA. LUA passa sempre intere unità richieste (UR) all'applicazione e l'applicazione deve passare intere UR a LUA.