Dati in ingresso
Questa sezione descrive i flussi di dati in ingresso dall'applicazione al nodo locale. La struttura complessiva dei protocolli descritti si applica al punto di controllo dei servizi di sistema (SSCP) e alle connessioni PLU (Primary Logic Unit), ma gli aspetti più complessi (ad esempio l'uso della modalità richiesta ritardata) sono applicabili solo alla connessione PLU.
L'applicazione può inviare dati in ingresso in una delle connessioni, come indicato di seguito:
I dati di gestione delle funzioni (FMD NS) e i dati di gestione delle funzioni (FMD) destinati all'host SSCP devono essere inviati al nodo locale nella connessione SSCP.
I dati FMD destinati all'host PLU devono essere inviati al nodo locale nella connessione PLU.
L'applicazione non può usare messaggi di dati per inviare messaggi di richiesta di controllo del flusso di dati (DFC) o di controllo sessione all'host. Deve invece usare i messaggi Status-Control . Per informazioni dettagliate, vedere Messaggio di controllo dello stato.
Per tutte le connessioni, l'applicazione deve compilare determinati campi chiave nell'intestazione del messaggio di dati . In particolare, deve:
Impostare il tipo di messaggio su DATAFMI.
Allocare una nuova chiave di messaggio per i messaggi dati in ingresso in questa connessione.
Impostare il campo ACKRQD se necessario.
Impostare i flag dell'applicazione. Per altre informazioni, vedere Flag dell'applicazione.
I campi nxtqptr, hdreptr e numelts nell'intestazione del messaggio e i campi elteptr e startd negli elementi del messaggio vengono configurati dalle routine di gestione del buffer di Host Integration Server. Per altre informazioni, vedere INTERFACCIA DL-BASE/DMOD. L'applicazione è responsabile dell'impostazione del campo finale .
Se l'applicazione non ha accesso a queste routine, ad esempio quando l'ambiente operativo non supporta le chiamate di routine intertask e la memoria condivisa, tutti i campi nell'intestazione devono essere impostati dall'applicazione.
Gli indicatori di intestazione di trasmissione (TH) e intestazione di risposta (RH) non sono disponibili per l'applicazione nei messaggi dati in ingresso. L'applicazione deve impostare i flag dell'applicazione appropriati nell'intestazione del messaggio per controllare la concatenazione, la direzione e così via. Per una descrizione dei flag di applicazione disponibili per i dati in ingresso e gli argomenti successivi in questa sezione per una descrizione del modo in cui vengono usati i flag per controllare i flussi di dati in ingresso, vedere Flag applicazione.
Per i dati in ingresso, il primo byte è UR[0] per l'interfaccia di gestione delle funzioni standard (FMI).
La chiave del messaggio fornita dall'applicazione nell'intestazione del messaggio di dati in ingresso viene usata dal nodo locale per indicare a quale messaggio di dati in questa connessione si riferisce un riconoscimento dello stato in uscita. L'applicazione deve mantenere una sequenza di chiavi di messaggio univoca per il flusso di dati in ingresso in ogni connessione con il nodo locale, in modo che l'applicazione possa usare la chiave del messaggio per correlare i messaggi di dati in ingresso e confermare i messaggi di stato in uscita nella connessione. Si noti che l'applicazione deve anche fornire una chiave di messaggio nei messaggi Richiesta di controllo stato per distinguere tra più messaggi LUSTAT RQE .
Il protocollo di riconoscimento dei dati in ingresso riflette il protocollo di risposta della catena secondaria e la modalità richiesta in uso nella sessione, come indicato di seguito:
I messaggi di dati in ingresso con ACKRQD impostati nell'intestazione generano richieste RQD .
I messaggi di dati in ingresso senza ACKRQD impostati nell'intestazione generano richieste RQE o RQN a seconda del protocollo di risposta della catena.
L'applicazione deve impostare solo ACKRQD nei messaggi di dati con il flag dell'applicazione ECI (End Chain Indicator).
Se la sessione specifica che la modalità richiesta secondaria usa la modalità richiesta immediata, l'applicazione può comunque inviare altri messaggi di dati dopo l'invio di dati con il set ACKRQD , anche se non ha ricevuto un messaggio di riconoscimento dello stato per tale messaggio di dati . I messaggi vengono accodati all'interno del nodo locale e vengono inviati progressivamente come risposte positive vengono ricevute.
Se la sessione specifica che il secondario usa la modalità richiesta ritardata, dopo l'invio di un messaggio di dati con ACKRQD impostato, l'applicazione può continuare a inviare messaggi di dati .
Se l'applicazione imposta il campo ACKRQD nell'intestazione del messaggio di un messaggio Di dati , indica che richiede un riconoscimento a questo messaggio di dati . Il nodo locale riconosce un messaggio dati in ingresso inviando un messaggio Status-Acknowledge all'applicazione nella stessa connessione e usando la stessa chiave di messaggio del messaggio del messaggio Data . Per un'illustrazione, vedere la prima figura alla fine di questo argomento.
Il nodo locale elabora i messaggi di dati in ingresso dall'applicazione tramite i computer di stato interni, assegna il numero di sequenza SNA corretto o un identificatore per questo flusso e invia i dati in una richiesta all'host. Il tipo di risposta a catena della richiesta dipende dal fatto che ACKRQD sia stato impostato nel messaggio Dati e nei parametri della sessione.
Il nodo locale esegue il mapping di una risposta positiva dall'host a un riconoscimento stato(Ack) all'applicazione. L'applicazione può usare la chiave del messaggio nella conferma di stato per correlare il riconoscimento con il messaggio dati originale. Pertanto, la ricezione di un messaggio di riconoscimento dello stato (Ack) per un determinato messaggio di dati implica che il nodo locale ha ricevuto una risposta SNA positiva dall'host alla richiesta SNA in ingresso. Per un'illustrazione, vedere la seconda figura alla fine di questo argomento.
Si noti che le risposte vengono assorbite nella sessione SSCP-PU.
Si noti che i messaggi Status-Acknowledge(Ack) in uscita contengono flag dell'applicazione e un numero di sequenza. I flag dell'applicazione riflettono gli indicatori RH nella risposta. Il numero di sequenza è il numero di sequenza SNA dalla risposta e fornisce un meccanismo per le applicazioni che usano il profilo del servizio di trasmissione (profilo TS) 4 per tenere traccia del numero di sequenza secondario SNA corrispondente a un'unità di lavoro.
Il nodo locale esegue il mapping di una risposta negativa dall'host a un messaggio Status-Acknowledge(Nack-1) all'applicazione. L'applicazione può usare la chiave del messaggio nella conferma di stato per correlare il riconoscimento negativo con il messaggio dati originale. Il messaggio Di riconoscimento dello stato in uscita (Nack-1) contiene i codici di senso SNA e il numero di sequenza dalla risposta negativa. Per un'illustrazione, vedere la terza e quarta figura alla fine di questo argomento.
Se il nodo locale rileva un errore nel formato di un messaggio dati in ingresso o il messaggio Dati non è appropriato per lo stato corrente della sessione, invia un riconoscimento stato (Nack-2) all'applicazione contenente un codice di errore. Per un elenco di codici di errore, vedere Codici errore e senso. Il nodo locale non invia una richiesta all'host corrispondente al messaggio Di dati in errore e non avanza il numero di sequenza SNA per la sessione. L'applicazione può usare qualsiasi chiave di messaggio nel messaggio dati in ingresso successivo (presupponendo che l'errore non causa un errore critico).
Un esempio di grave errore di concatenamento, in cui l'applicazione invia un messaggio di dati con ACKRQD , ma senza ECI nei flag dell'applicazione, viene visualizzata nell'ultima figura alla fine di questo argomento. Si noti che dopo aver rilevato questo particolare errore, il nodo locale contrassegna la connessione dell'applicazione come non riuscita in modo critico, chiude la connessione e invia una richiesta TERM-SELF a SSCP per elicare un UNBIND. Per altre informazioni, vedere Ripristino.
I messaggi Status-Control in ingresso, che causano la generazione di richieste di flusso accelerato, possono essere inviati in qualsiasi momento e non influiscono sull'invio di un riconoscimento positivo o negativo ai messaggi dati in ingresso. Per informazioni dettagliate sui messaggi status-control corrispondenti alle richieste di flusso rapido SNA, vedere Messaggio di controllo stato.
Le cinque cifre seguenti illustrano esempi dei protocolli di riconoscimento dei dati in ingresso (e dei protocolli SNA sottostanti) per diversi tipi di risposta a catena e modalità di richiesta di sessione secondaria.
Le cifre mostrano:
Campo ACKRQD nei messaggi di dati .
Chiave del messaggio nei messaggi di dati .
Eventuali flag di applicazione pertinenti nei messaggi di dati .
Codici di errore (visualizzati come "ERROR=...") nei messaggi di dati .
Flag RH pertinenti nelle richieste/risposte SNA.
Numeri di sequenza in richieste/risposte SNA.
Codici di senso (visualizzati come "SENSE=....") in richieste/risposte SNA.
Per semplicità, si presuppone che tutti i messaggi vengano trasmessi nella stessa sessione PLU.
Nella figura seguente l'applicazione invia correttamente un messaggio Di dati .
L'applicazione invia correttamente un messaggio di datiNella figura seguente l'applicazione invia correttamente una catena di messaggi di dati .
L'applicazione invia correttamente una catena di messaggi di datiNella figura seguente l'host rifiuta una catena di messaggi di dati .
L'host rifiuta una catena di messaggi di datiNella figura seguente l'host rifiuta la prima catena di risposta definita e rifiuta la terza catena di risposta di eccezione in una sessione richiesta ritardata. Si noti che la risposta negativa alla terza catena implica una risposta positiva alla seconda catena.
L'host rifiuta la prima catena di risposta definitaNella figura seguente il nodo locale rileva l'uso non valido dell'applicazione di ACKRQD senza il flag dell'applicazione ECI in un messaggio Dati . Si noti che non vengono inviati dati all'host. Tuttavia, poiché l'errore è critico, il nodo locale invierà un messaggio TERM-SELF al SSCP.
Il nodo locale rileva l'uso non valido dell'applicazione di ACKRDQ senza il flag dell'applicazione ECI in un messaggio di dati