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 che originano al host all'applicazione su connessioni diverse, a seconda della sessione SNA su cui scorrono i dati.

• I dati di gestione delle funzioni (FMD NS) (servizi di sessione) e i dati di gestione delle funzioni (FMD) provenienti dall'host SSCP e indirizzati all'unità logica host integration server (LU) vengono inviati all'applicazione nella connessione SSCP.

• I dati FMD originati dall'host PLU e indirizzati a un server LU SNA vengono inviati all'applicazione sulla connessione PLU.

  Per tutte le connessioni, solo le richieste FMD vengono presentate all'applicazione 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 Status-Control Message.

  Il nodo locale esegue le modifiche dello stato di 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 di intestazione di trasmissione delle richieste SNA (TH) e RH non sono disponibili per l'applicazione nei messaggi di dati in uscita. Il nodo locale fornisce invece 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 dell'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 dell'applicazione unità logica (LUA) 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 dei messaggi nei messaggi in uscita Status-Control Request.

  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 Data senza il flag ACKRQD abilitato.

• Le richieste RQN in uscita generano messaggi dati senza che il flag ACKRQD sia impostato.

• Se la sessione usa la modalità richiesta immediata primaria, è necessario che un messaggio di dati con set ACKRQD 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 immediatamente riconosciuto 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 conferme di ricezione in ordine.

  Se il nodo locale imposta il campo ACKRQD nell'intestazione del messaggio di un messaggio di 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 della chiave del messaggio e del numero di sequenza del messaggio Dati .

  Al ricevimento di un Status-Acknowledge(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 adeguata.

  L'applicazione deve usare il messaggio Status-Acknowledgement(Nack-1) come riconoscimento negativo. Quando viene ricevuta una conferma di stato (Nack-1), il nodo locale correla il messaggio con i messaggi in uscita in sospeso e genera una risposta negativa SNA e i dati di significato alla richiesta SNA appropriata. L'applicazione fornisce i dati sensoriali che devono accompagnare la risposta negativa come parte del messaggio Status-Acknowledge(Nack-1) e deve includere la stessa chiave del messaggio, i flag dell'applicazione e i campi del numero di sequenza del messaggio Dati a cui questo è 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 di dati in uscita e il messaggio Status-Acknowledg corrispondente è puramente coincidente. Per informazioni dettagliate sui messaggi status-control corrispondenti alle richieste SNA, vedere Status-Control Messaggio.

  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 di applicazione SDI e ECI.

• Il codice di senso associato all'errore occupa i primi quattro byte del messaggio Dati . Per altre informazioni, vedere Status-Control Message.

• ACKRQD è impostato.

  L'applicazione deve restituire un status-acknowledgement (Ack) e il nodo locale genera una risposta negativa che trasporta il codice del senso appropriato per l'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, se l'operazione non riesce, verrà forzata l'interruzione delle sessioni. Per evitare questo, l'applicazione deve fornire messaggi Status-Acknowledge(Ack) per i dati RQE che non vuole rifiutare in questo caso. Una risposta dopo cinque catene RQE consecutive dovrebbe essere sufficiente. Tali messaggi sono definiti riconoscimenti di cortesia e non danno origine a una risposta all'host, ma liberano semplicemente i 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 di riconoscimento dello statopositivi e negativi.

  Le figure mostrano:

• I flag RH rilevanti nelle richieste/risposte SNA.

• Numero di sequenza di richieste/risposte SNA.

• Qualsiasi dato di senso (visualizzato come "SENSE=...") nelle richieste/risposte SNA e nei messaggi di conferma dello stato .

• Campo ACKRQD nei messaggi di dati .

• Campo chiave del messaggio nei 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 un RU di risposta definita

  Nella 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ù UR

  Nella 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 definita

  Nella figura seguente l'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposta definita multi UR.

  
  L'applicazione rifiuta un messaggio di dati corrispondente a una catena di risposta definita con più UR

  Nella 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 alle eccezioni e accetta la catena di risposta definita, che implica l'accettazione della terza catena di risposta alle eccezioni.

  
  Il nodo locale applica la modalità di risposta immediata

  Nella 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

Vedere anche

Dati in ingresso
Dati in ingresso da applicazioni LUA