Dati in uscita
Questa sezione descrive i flussi di dati in uscita dal nodo locale all'applicazione. La struttura complessiva dei protocolli descritti si applica al punto di controllo dei servizi di sistema (SSCP) e alle connessioni PLU (Primary Logical Unit), ma alcune funzionalità (ad esempio l'uso della modalità richiesta ritardata) sono applicabili solo alla connessione PLU.
Il nodo locale presenta i dati provenienti dall'host all'applicazione in connessioni diverse, a seconda della sessione SNA in cui i flussi di dati sono i seguenti:
I dati di gestione delle funzioni (FMD NS) e i dati di gestione delle funzioni (FMD) originati dall'host SSCP e indirizzati all'unità logica host integration server (LU) vengono inviati all'applicazione sulla connessione SSCP.
I dati FMD originati dal PLU host e indirizzati a un lu server SNA vengono inviati all'applicazione nella connessione PLU.
Per tutte le connessioni, all'applicazione vengono presentate solo richieste FMD come messaggi di dati (con tipo di messaggio = DATAFMI). Le richieste di controllo di sessione e DFC vengono usate per generare messaggi di controllo dello stato . Per altre informazioni, vedere Messaggio di controllo dello stato.
Il nodo locale esegue le modifiche dello stato del controllo del flusso di dati richieste dagli indicatori dell'intestazione di risposta (RH) nella richiesta, prima di inviare un messaggio Di dati all'applicazione.
Gli indicatori TH (Request Transmission Header) e RH non sono disponibili per l'applicazione nei messaggi di dati in uscita. Al contrario, il nodo locale fornisce i flag dell'applicazione nell'intestazione Messaggio di dati che riflettono le impostazioni di un subset degli indicatori RH, ma vengono interpretati dal nodo locale per proteggere l'applicazione dagli aspetti più oscuri dell'utilizzo del concatenamento e delle parentesi quadre. Per una descrizione dei flag disponibili e del modo in cui il nodo locale li usa nei dati in uscita, vedere Flag applicazione.
Per i dati in uscita, il primo byte è UR[0] per l'interfaccia di gestione delle funzioni standard (FMI) e TH[0] per la variante LUA (Logical Unit Application) di FMI.
Tutti i messaggi di dati dal nodo locale a un'applicazione contengono una chiave di messaggio. Il nodo locale gestisce una sequenza di chiavi di messaggio univoca per ogni flusso di dati in uscita a un'applicazione. Quando il nodo locale invia un messaggio Dati a un'applicazione in una determinata connessione, inserisce la chiave del messaggio successiva nella sequenza in uscita nell'intestazione del messaggio, imposta i flag dell'applicazione e invia il messaggio all'applicazione. Ciò significa che la chiave del messaggio identifica in modo univoco un messaggio di dati in una determinata connessione tra il nodo locale e l'applicazione. Si noti che il nodo locale inserisce anche le chiavi di messaggio nei messaggi di richiesta di controllo dello stato in uscita.
Il protocollo di riconoscimento applicato da Host Integration Server riflette il protocollo di risposta della catena e la modalità richiesta in uso nella sessione SNA, come indicato di seguito:
Le richieste RQD in uscita generano messaggi di dati con ACKRQD impostato nell'intestazione del messaggio.
Le richieste RQE in uscita generano messaggi di dati senza set ACKRQD .
Le richieste RQN in uscita generano messaggi di dati senza set ACKRQD .
Se la sessione usa la modalità richiesta immediata primaria, è necessario che un messaggio dati con ACKRQD impostato venga riconosciuto dall'applicazione prima che vengano ricevuti altri messaggi di dati .
Se la sessione usa la modalità richiesta ritardata primaria, un messaggio di dati con set ACKRQD non deve essere riconosciuto immediatamente dall'applicazione. I messaggi di dati continueranno a essere ricevuti.
Si noti che Host Integration Server applica l'equivalente della modalità di risposta immediata per il protocollo di riconoscimento dei dati in uscita per tutte le connessioni. L'applicazione deve inviare riconoscimenti in ordine.
Se il nodo locale imposta il campo ACKRQD nell'intestazione del messaggio di un messaggio Dati all'applicazione, indica che è necessario un riconoscimento a questo messaggio di dati . L'applicazione riconosce un messaggio di dati in uscita inviando un messaggio di conferma dello stato al nodo locale nella stessa connessione, che contiene gli stessi campi chiave del messaggio e numero di sequenza del messaggio Dati .
Alla ricezione di un riconoscimento dello stato (Ack), il nodo locale correla la chiave del messaggio con i messaggi in uscita in sospeso e genera una risposta positiva SNA alla richiesta SNA appropriata.
L'applicazione deve usare il messaggio Status-Acknowledgement(Nack-1) come riconoscimento negativo. Alla ricezione di un riconoscimento dello stato (Nack-1), il nodo locale correla il messaggio con i messaggi in uscita in sospeso e genera una risposta negativa SNA più i dati del senso alla richiesta SNA appropriata. L'applicazione fornisce i dati di senso che devono accompagnare la risposta negativa come parte del messaggio Status-Acknowledgement(Nack-1) e deve includere la stessa chiave del messaggio, i flag dell'applicazione e i campi del numero di sequenza come messaggio di dati a cui si tratta di un riconoscimento negativo.
I messaggi di controllo dello stato causati da richieste di flusso accelerato possono essere inviati in qualsiasi momento e non influiscono sull'invio di un riconoscimento positivo o negativo ai normali messaggi di dati in uscita del flusso. Il fatto che possano verificarsi tra un messaggio dati in uscita e il messaggio Status-Acknowledg corrispondente è puramente casuale. Per informazioni dettagliate sui messaggi Status-Control che corrispondono alle richieste SNA, vedere Messaggio di controllo dello stato.
Se vengono rilevati errori nel formato di una normale richiesta di flusso dall'host o la richiesta non è appropriata per lo stato della sessione, il nodo locale genera un messaggio di errore Dati per l'applicazione con le caratteristiche seguenti:
Vengono impostati i flag dell'applicazione SDI e ECI.
Il codice sense associato all'errore occupa i primi quattro byte del messaggio Di dati . Per altre informazioni, vedere Messaggio di controllo dello stato.
ACKRQD è impostato.
L'applicazione deve restituire status-acknowledgement (Ack) e il nodo locale genera una risposta negativa che trasporta il codice sense appropriato all'errore rilevato. Questo meccanismo esegue le operazioni seguenti:
Informa l'applicazione dell'errore rilevato.
Consente all'applicazione di rispondere a tutti i dati ricevuti in precedenza prima che il nodo locale invii la risposta negativa a questo messaggio di dati.
Nelle sessioni in cui l'applicazione riceve una serie di catene RQE, il nodo locale manterrà le informazioni di correlazione per ogni catena (nel caso in cui l'applicazione voglia inviare risposte negative a una delle catene). Se il nodo locale esaurisce le voci della tabella di correlazione, tenterà di allocare più voci e, in caso di errore, verrà forzato l'interruzione delle sessioni. Per evitare questo problema, l'applicazione deve fornire messaggi Status-Acknowledgement (Ack) per i dati RQE che non vogliono rifiutare in questo caso. Una risposta dopo cinque catene RQE consecutive deve essere sufficiente. Tali messaggi vengono definiti riconoscimenti di cortesia e non danno origine a una risposta all'host, ma semplicemente liberare dati di correlazione interni.
Le sei figure seguenti illustrano il protocollo di riconoscimento dei dati applicato tra il nodo locale e l'applicazione e mostrano gli effetti dell'applicazione che genera messaggi e-acknowledgement di statopositivi e negativi.
Le cifre mostrano:
Flag RH pertinenti nelle richieste/risposte SNA.
Numero di sequenza di richieste/risposte SNA.
Tutti i dati di senso (visualizzati come "SENSE=...") nelle richieste/risposte SNA e messaggi Di conferma dello stato .
Campo ACKRQD in Messaggi di dati .
Campo chiave messaggio in Messaggi di dati .
Per semplicità, si presuppone che tutti i messaggi siano flussi di dati FM nella stessa sessione PLU.
Nella figura seguente l'applicazione accetta un messaggio di dati corrispondente a un UR di risposta definita.
L'applicazione invia un messaggio di dati corrispondente a una ur di risposta definitaNella figura seguente l'applicazione accetta un messaggio di dati corrispondente a una catena di risposta definita con più UR.
L'applicazione accetta un messaggio di dati corrispondente a una catena di risposta definita con più URNella figura seguente l'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposta definita.
L'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposta definitaNella figura seguente l'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposte definite-UR a più UR.
L'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposta definita con più URNella figura seguente il nodo locale applica la modalità di risposta immediata. Le risposte devono essere inviate in sequenza. L'applicazione rifiuta la seconda catena di risposta delle eccezioni e accetta la catena di risposta definita,che implica l'accettazione della terza catena di risposta di eccezione.
Il nodo locale applica la modalità di risposta immediataNella figura seguente il nodo locale rileva un errore di concatenamento (RQD ma non EC) nei dati destinati all'applicazione. In questo esempio è necessario che il controllo di ricezione 0x4007 sia in vigore. Per altre informazioni, vedere Apertura della connessione SSCP.
Il nodo locale rileva un errore di concatenamento nei dati destinati all'applicazione