Concatenamento in uscita

Il nodo locale verifica che le catene in uscita delle richieste siano conformi all'utilizzo SNA corretto, all'utilizzo del concatenamento per la sessione e allo stato corrente della sessione. Il nodo locale accetterà catene di dati in uscita valide dall'host se una delle condizioni seguenti è vera:

• Il traffico dati è attivo in una sessione full-duplex.

• La sessione è in uno stato in cui può ricevere dati.

• La sessione è compresa tra parentesi quadre con nessuna delle due sessioni che attualmente inviano o la sessione è in conflitto per una sessione di contesa half-duplex. Per altre informazioni, vedere Brackets.

• La sessione è in attesa che l'host avvii una procedura di ripristino. Ad esempio, il nodo locale ha inviato una risposta negativa a una catena in uscita. Per altre informazioni, vedere Ripristino.

  Il nodo locale invia un messaggio Data all'applicazione per ogni richiesta in uscita, ma è importante notare gli effetti quando l'applicazione specifica l'opzione di recapito dei segmenti nel blocco di controllo delle informazioni di connessione. Per ulteriori informazioni, vedere Consegna del segmento. Se l'applicazione non specifica la consegna dei segmenti, l'indicatore della catena iniziale (BCI) e i flag dell'indicatore di fine catena (ECI) nell'intestazione del messaggio riflettono gli indicatori di concatenamento nell'intestazione della richiesta.

  Una catena in uscita può terminare in diversi modi:

• La catena viene ricevuta completa e senza errori. Tutte le richieste nella catena sono state passate all'applicazione come messaggi Data e sono state riconosciute, ove applicabile.

• L'applicazione rileva un errore in un messaggio di dati durante la ricezione della catena. L'applicazione deve inviare un Status-Acknowledge(Nack-1) con dati di rilevamento associati al nodo locale, che invia una risposta negativa più i dati di rilevamento all'host per la richiesta corrispondente al messaggio Dati in errore. Il nodo locale non elimina il resto della catena, quindi l'applicazione vedrà End Chain (EC). In alternativa, l'host può terminare la catena con un CANCEL, che viene recapitato all'applicazione come Status-Control(CANCEL) con ACKRQD impostato.

• Il nodo locale rileva un errore in una richiesta e presenta all'applicazione un messaggio di dati di errore rilevato dal sistema per segnalare la chiusura prematura della catena. Questo messaggio contiene gli indicatori di errore rilevati dal sistema (SDI) e i flag dell'applicazione ECI, i codici di senso per l'errore e l'indicatore ACKRQD. Non contiene dati utente. Quando l'applicazione risponde con Status-Acknowledgement(Ack), il nodo locale genera una risposta negativa alla catena usando il codice di senso appropriato. L'applicazione può usare i codici di senso segnalati per generare informazioni di diagnostica per l'utente. Ad esempio, un emulatore 3270 genera codici di controllo PROG . Il nodo locale elimina il resto della catena, quindi l'applicazione potrebbe non vedere EC. In alternativa, l'host può terminare la catena con un CANCEL, che viene recapitato all'applicazione come Status-Control(CANCEL) con ACKRQD impostato.

• L'host può annullare la catena durante l'invio inviando la richiesta CANCEL . Il nodo locale invia un messaggio Status-Control(CANCEL) all'applicazione, che l'applicazione deve confermare.

  Se si verifica un errore durante la ricezione di dati e la sessione utilizza protocolli flip-flop half-duplex, l'applicazione deve presupporre uno stato in attesa di ripristino dell'errore. Per altre informazioni, vedere Ripristino.

  Per una sessione che usa protocolli flip-flop half-duplex, se i flag dell'applicazione nell'ultimo messaggio Dati della catena hanno impostato il flag CDI (cambio di direzione):

• Se la catena è stata ricevuta senza errori, l'applicazione ha un orientamento.

• Se l'applicazione ha rifiutato qualsiasi messaggio nella catena, l'host mantiene la direzione.

  Le quattro figure seguenti illustrano i protocolli di concatenamento in uscita tra il nodo locale e l'applicazione e il modo in cui tali protocolli sono correlati ai protocolli SNA sottostanti.

  Nella prima figura viene ricevuta una catena in uscita completa senza errori e accettata dall'applicazione. Si noti che, dopo l'invio di Status-Acknowledge(Ack), l'applicazione ha la direzione.

  
  Catena in uscita ricevuta senza errori e accettata dall'applicazione

  Nella figura seguente viene ricevuta una catena in uscita completa senza errori, ma viene rifiutata dall'applicazione. Si noti che, anche se la catena supportava CD, l'applicazione non ha direzione.

  
  La catena in uscita è stata ricevuta senza errori, ma è stata rifiutata dall'applicazione.

  Nella figura seguente, il nodo locale rileva l'uso non valido di RQD senza EC e converte la richiesta in un messaggio di dati con il set di flag dell'applicazione SDI, più ACKRQD e i codici di senso appropriati. Status-Acknowledge(Ack) dell'applicazione genera una risposta negativa all'host. In questo esempio si presuppone che il controllo di ricezione 4007 sia stato specificato nel CICB in Open (SSCP).

  
  Il nodo locale rileva l'uso non valido e converte la richiesta

  Nella figura seguente l'host annulla la catena in uscita.

  
  Host che annulla la catena di trasmissione

Vedere anche

Apertura della connessione PLU
Sessione PLU
Concatenamento in ingresso
Consegna del Segmento
parentesi quadre
Direzione
Ritmo e suddivisione in blocchi
Conferma e rifiuto dei dati]
Arresto e disattivazione
Ripristino
Terminazione iniziata dall'applicazione
LUSTATs]
Dati di Monitoraggio tempo di risposta