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 Logical 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 su una qualsiasi delle connessioni, come indicato di seguito:

• I servizi di rete dati di gestione delle funzioni (FMD NS) (servizi di sessione) e i dati con codifica FMD (Function Management Data) 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 i 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 Status-Control Message.

  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 di dati in ingresso in questa connessione.

• Impostare il campo ACKRQD , se necessario.

• Impostare i flag dell'applicazione. Per altre informazioni, vedere Indicatori dell'applicazione.

  I campi nxtqptr, hdreptr e numelts nell'intestazione del messaggio e i campi elteptr e start negli elementi del messaggio vengono configurati dalle routine di gestione del buffer di Host Integration Server. Per altre informazioni, vedere l'interfaccia DL-BASE/DMOD. L'applicazione è responsabile dell'impostazione del campo endd.

  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 dell'intestazione di trasmissione (TH) e dell'intestazione di risposta (RH) non sono disponibili per l'applicazione nei messaggi di dati in ingresso. L'applicazione deve impostare i flag di applicazione appropriati nell'intestazione del messaggio per controllare il concatenamento, la direzione e così via. Per una descrizione dei flag di applicazione disponibili per i dati in ingresso e su come i flag vengono utilizzati per controllare i flussi di dati in ingresso, consultare la sezione Application Flags.

  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 dati in ingresso viene usata dal nodo locale per indicare a quale messaggio dati in questa connessione fa riferimento 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 lo stato in uscita sulla connessione. Si noti che l'applicazione deve anche fornire una chiave di messaggio nei messaggi di Richiesta di Status-Control per distinguere tra più messaggi RQE LUSTAT.

  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 impostato nell'intestazione generano richieste RQE o RQN a seconda del protocollo di risposta della catena.

• L'applicazione deve impostare ACKRQD solo sui messaggi di dati che hanno il flag dell'applicazione ECI (End Chain Indicator) impostato.

• Se la sessione specifica che il database secondario 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 conferma dello stato per tale messaggio di dati . I messaggi vengono accodati all'interno del nodo locale e vengono successivamente inviati al ricevimento di risposte positive.

• Se la sessione specifica che il database 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 di dati in ingresso inviando un messaggio di conferma dello stato all'applicazione nella stessa connessione e usando la stessa chiave di messaggio del messaggio Dati . 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 di dati e nei parametri della sessione.

  Il nodo locale mappa una risposta positiva dall'host a un Status-Acknowledge(Ack) all'applicazione. L'applicazione può usare la chiave del messaggio in Status-Acknowledgement per correlare il riconoscimento al messaggio dati originale. Pertanto, la ricezione di un messaggio status-acknowledgement (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 di SSCP-PU.

  Si noti che i messaggi Status-Acknowledgement (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 della risposta e fornisce un meccanismo per le applicazioni che usano il profilo TS (Transmission Service Profile) 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-Acknowledgement(Nack-1) all'applicazione. L'applicazione può usare la chiave del messaggio in Status-Acknowledgement per correlare il riconoscimento negativo con il messaggio dati originale. Il messaggio Status-Acknowledge(Nack-1) in uscita contiene i codici di rilevamento SNA e il numero di sequenza della risposta negativa. Per un'illustrazione, vedere la terza e la 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 allo stato corrente della sessione, invia un valore Status-Acknowledgement(Nack-2) all'applicazione contenente un codice di errore. Per un elenco dei codici di errore, vedere Codici Errore e Senso. Il nodo locale non invia una richiesta all'host corrispondente al messaggio Data 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 causi un errore critico.

  Un esempio di errore di concatenamento grave, in cui l'applicazione invia un messaggio di dati con ACKRQD ma senza ECI nei flag dell'applicazione, viene mostrato 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 di controllo dello stato 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 di dati in ingresso. Per informazioni dettagliate sui messaggi Status-Control corrispondenti alle richieste di flusso accelerato SNA, vedere Messaggio Status-Control.

  Le cinque figure 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 figure mostrano:

• Il campo ACKRQD nei messaggi Data.

• Chiave del messaggio nei messaggi di dati .

• Eventuali flag dell'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 nelle richieste/risposte SNA.

• Codici sense (visualizzati come "SENSE=....") nelle 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 Dati .

  
  L'applicazione invia correttamente un messaggio di dati

  Nella figura seguente l'applicazione invia correttamente una catena di messaggi di dati .

  
  L'applicazione invia correttamente una catena di messaggi di dati

  Nella figura seguente l'host rifiuta una catena di messaggi di dati .

  
  L'host rifiuta una catena di messaggi di dati

  Nella figura seguente, l'host rifiuta la prima catena di risposta definita e rifiuta la terza catena di risposte di eccezione in una sessione di 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 definita

  Nella figura seguente, il nodo locale rileva l'uso non valido dell'applicazione di ACKRQD senza il flag applicativo ECI in un messaggio Dati. Si noti che nessun dato viene inviato all'host. Tuttavia, poiché l'errore è critico, il nodo locale invierà un messaggio TERM-SELF a SSCP.

  
  Il nodo locale rileva l'uso non valido dell'applicazione di ACKRDQ senza il flag dell'applicazione ECI in un messaggio di dati

Vedere anche

Dati in uscita
Dati in ingresso da applicazioni LUA