Caratteristiche della sessione SSCP

Per i nodi SNA di tipo 2.1, la sessione del punto di controllo dei servizi di sistema (SSCP) usa il profilo di gestione delle funzioni (FM) 0 e il profilo del servizio di trasmissione (profilo TS) 1. Questa combinazione di profili fornisce le caratteristiche di sessione seguenti:

• Le sessioni di metà primaria e secondaria usano entrambe la modalità richiesta immediata.

• Le mezze sessioni primarie e secondarie usano entrambe la modalità di risposta immediata.

• Sono consentite solo catene di unità richiesta singola a risposta definita.

• La dimensione massima dell'unità richiesta è limitata a 256 byte.

• Le unità richiesta di controllo del flusso di dati non sono supportate.

• La pacing non è supportata.

• Gli identificatori vengono usati (anziché numeri di sequenza) nei flussi normali.

  Ciò implica che la connessione SSCP presenta le caratteristiche seguenti:

• Tutti i messaggi di dati hanno il set di campi ACKRQD (ACKRQD).

• Tutti i messaggi di dati hanno l'indicatore della catena iniziale (BCI) e i flag dell'applicazione ECI (End Chain Indicator).

• I messaggi di controllo dello stato non vengono trasmessi alla connessione.

• I messaggi di sessione di stato dal nodo locale all'applicazione segnalano solo le modifiche apportate allo stato di attivazione della sessione.

• I protocolli di concatenamento, parentesi quadre, conferma e ripristino (descritti in Connessione PLU) non si applicano.

  Usando la connessione SSCP, l'applicazione può inviare e ricevere messaggi di dati corrispondenti alle richieste di servizi di rete dei dati di gestione delle funzioni (FMD NS) e richieste di dati FMD. Esempi di richieste NS (servizi di sessione) fmd sono:

• INIT-SELF. Le richieste dal database secondario all'host SSCP richiedono che SSCP assista all'avvio di una sessione al PLU host, richiedendo effettivamente un BINDING. Per altre informazioni, vedere Apertura della connessione PLU.

• TERMINE SELF. Le richieste dal database secondario all'host SSCP richiedono che la sessione PLU-SLU venga terminata con un UNBIND. Per altre informazioni, vedere Chiusura della connessione PLU.

• Richieste codificate con caratteri. Richieste come accesso, disconnessione o comandi di test dalla visualizzazione secondaria o un prompt di accesso dall'applicazione host.

• NOTIFICARE. Richieste usate dal database secondario per notificare all'host SSCP che un dispositivo è disponibile dopo che un BINDING è stato rifiutato con codice sense 0x0845, ad esempio, in cui un emulatore di dispositivo supporta l'accensione logica.

  Il nodo locale invia una richiesta NOTIFY a SSCP per conto dell'unità lu ogni volta che lo stato della connessione SSCP dell'applicazione cambia mentre l'unità di elaborazione è attiva. Una notifica (chiave vettoriale 0x0C con byte 5 impostata su 0x03), che può fungere da LU secondario, viene inviata nei casi seguenti:

• Quando viene ricevuta una richiesta Open(SSCP) quando l'unità lu è già attiva.

• Quando viene accettata una richiesta ACTLU quando la connessione SSCP è già aperta.

  Una notifica (chiave vettoriale 0x0C con byte 5 impostata su 0x01), che attualmente non può fungere da LU secondario, viene inviata nei casi seguenti:

• Quando viene ricevuto un ACTLU quando la connessione SSCP non è aperta.

• Quando viene ricevuta una richiesta Close(SSCP) quando la sessione PLU non è associata.

• Quando viene ricevuta una richiesta UNBIND quando la connessione SSCP non è aperta.

• Quando la risposta lunga che include il vettore NOTIFY viene usata per le richieste ACTLU.

  Questi messaggi NOTIFY possono essere usati dall'host in combinazione con la risposta negativa 0x0845 che il nodo locale restituisce a un bind ricevuto quando la connessione SSCP non è aperta. Per altre informazioni, vedere Apertura della connessione PLU.