Concatenamento in uscita

Il nodo locale verifica che le catene di richieste in uscita 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 si trova in uno stato in cui può ricevere dati.

  • La sessione è tra parentesi quadre con nessuna sessione di mezza sessione attualmente in invio oppure la sessione è in conflitto per una sessione di contesa half-duplex. Per altre informazioni, vedere Parentesi quadre.

  • 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 Dati all'applicazione per ogni richiesta in uscita, ma si notino gli effetti dell'applicazione specificando l'opzione di recapito dei segmenti nel blocco di controllo delle informazioni di connessione. Per altre informazioni, vedere Distribuzione di segmenti. Se l'applicazione non specifica il recapito dei segmenti, l'indicatore della catena iniziale (BCI) e i flag dell'applicazione ECI (End Chain Indicator) 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 completata e senza errori. Tutte le richieste nella catena sono state passate all'applicazione come messaggi di dati e sono state riconosciute, se applicabile.

  • L'applicazione rileva un errore in un messaggio di dati durante la ricezione della catena. L'applicazione deve inviare un riconoscimento dello stato (Nack-1) con i dati sense associati al nodo locale, che invia una risposta negativa più i dati di senso 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 controllo di stato (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 terminazione 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 sense appropriato. L'applicazione può usare i codici sense segnalati per generare informazioni di diagnostica per l'utente. Ad esempio, un emulatore 3270 genera codici di controllo PROG . Il nodo locale ripulirà 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 controllo di stato (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 riconoscere.

    Se si verifica un errore durante la ricezione di una catena e la sessione usa protocolli flip-flop half-duplex, l'applicazione deve presupporre uno stato error-recovery-pending. 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 il flag CDI (direzione di modifica) impostato:

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

  • 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-Acknowledgement(Ack), l'applicazione ha la direzione.

    Immagine che mostra una catena in uscita ricevuta senza errori e accettata dall'applicazione.
    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 ha portato CD, l'applicazione non ha direzione.

    Immagine che mostra una catena in uscita ricevuta senza errori, ma viene rifiutata dall'applicazione.
    Catena in uscita ricevuta senza errori, ma 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 dati con il flag dell'applicazione SDI impostato, oltre a ACKRQD e i codici di senso appropriati. Status-Acknowledgement(Ack) dell'applicazione determina la risposta negativa all'host. In questo esempio si presuppone che il controllo di ricezione 4007 sia stato specificato in CICB in Open (SSCP).

    Immagine che mostra un nodo locale che rileva l'uso non valido e converte la richiesta.
    Il nodo locale rileva l'uso non valido e converte la richiesta

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

    Immagine che mostra un host che annulla la catena in uscita.
    Host che annulla la catena in uscita

Vedere anche

Apertura della connessione PLU
Sessione PLU
Concatenamento in ingresso
Consegna segmenti
Parentesi
Direzione
Spaziatura e suddivisione in blocchi
Conferma e rifiuto dei dati]
Arresto e disattivazione
Ripristino
Terminazione avviata dall'applicazione
LUSTAT]
Dati di monitoraggio del tempo di risposta