Tabelle dati CF (Coupling facility)
I comandi di controllo dei file CICS® possono accedere alle tabelle di dati delle strutture di accoppiamento (CFDT). L'accoppiamento delle tabelle di dati delle strutture fornisce un metodo di condivisione dei dati del file, senza la necessità di una regione proprietaria del file e senza la necessità di un supporto RLS VSAM.
- Dati di natura relativamente breve (creati durante l'esecuzione dell'applicazione o caricati inizialmente da una fonte esterna)
- Volumi di dati non tipicamente grandi
- Dati che devono essere consultati velocemente
- Dati la cui perdita occasionale può essere tollerata dalle applicazioni dell'utente
- Dati che richiedono comunemente l'integrità dell'aggiornamento.
- Tabelle di ricerca dei numeri di telefono o dei numeri delle carte di credito rubate
- Dati di lavoro costituiti da pochi elementi, come ad esempio un sottoinsieme di clienti da un elenco clienti
- Informazioni specifiche dell'utente dell'applicazione o relative al terminale da cui viene eseguita l'applicazione
- Dati estratti da un file o da un database più grande per un'ulteriore elaborazione.
L'accoppiamento delle tabelle di dati della struttura consente vari tipi di accesso ai dati informali: sola lettura, aggiornamento singolo, aggiornamento multiplo, accesso sequenziale, accesso casuale, inserimento e cancellazione casuale.
Per molti scopi, essendo di portata globale, l'accoppiamento delle tabelle di dati della struttura può offrire vantaggi significativi rispetto a risorse come l'area di lavoro comune ( CICS.
Per un programma applicativo, un CFDT appare come una tabella di dati gestita dall'utente a livello di sysplex: si accede a un CFDT usando lo stesso sottoinsieme dell'API di un UMT (cioè l'API di controllo dei file completa, tranne le opzioni MASSINSERT e RBA). Tuttavia, un CFDT è limitato a una lunghezza massima della chiave di 16 byte.
- Gli aggiornamenti di un CFDT, come quelli di un UMT, non si riflettono nel set di dati VSAM di base (se la tabella è stata inizialmente caricata da un set). Gli aggiornamenti vengono apportati solo alla CFDT.
- Un CFDT viene caricato una sola volta, quando la tabella viene creata per la prima volta nella tabella dei dati dell'impianto di accoppiamento, e rimane in essere nell'impianto di accoppiamento anche quando l'ultimo file che fa riferimento al CFDT viene chiuso (mentre un UMT viene cancellato ogni volta che la regione proprietaria termina). È possibile forzare il ricarico di un CFDT dal set di dati di origine solo eliminando prima la tabella dal pool CFDT, utilizzando un comando DELETE TABLE del server CFDT. Il primo file aperto con il CFDT dopo l'operazione di cancellazione fa sì che il server ricarichi la tabella.Nota: un pool di tabelle di dati dell'impianto di accoppiamento è definito come una struttura di elenco di impianti di accoppiamento e può contenere più di una tabella di dati. Per informazioni sulla creazione di una struttura di elenchi per l'accoppiamento delle tabelle di dati della struttura, vedere Parametri server delle tabelle di dati della struttura accoppiate ).
- Le regole di accesso per un UMT in fase di caricamento consentono di soddisfare qualsiasi richiesta di lettura diretta dalla tabella (se il record è già stato caricato) o dal set di dati di origine, ma rifiutano qualsiasi richiesta di aggiornamento, lettura imprecisa o consultazione, con la condizione LOADING. Per un CFDT, qualsiasi richiesta è consentita durante il caricamento, ma le richieste hanno successo solo per i record che rientrano nell'intervallo di chiavi già caricato.
Accoppiamento dei modelli di tabelle di dati delle strutture
- Modello di contesa
- Ciò garantisce prestazioni ottimali, ma richiede programmi scritti per gestire la situazione in cui i dati sono stati modificati da quando è stata emessa una richiesta di lettura-aggiornamento. La nuova risposta CHANGED può essere fornita con un comando REWRITE o DELETE. È stato inoltre introdotto un nuovo uso della risposta NOTFND, che può essere restituita per indicare al programma applicativo che il record è stato cancellato da quando il programma ha emesso la richiesta di aggiornamento.Nota: È possibile utilizzare programmi esistenti con il modello di contesa se si è certi che non possono ricevere le eccezioni CHANGED o NOTFND in caso di REWRITE o DELETE. Un esempio potrebbe essere quello di un programma applicativo che opera solo sui record relativi all'utente del programma e quindi nessun altro utente potrebbe aggiornare gli stessi record.
- Modello di bloccaggio
- Questo modello è compatibile con i programmi esistenti conformi al sottoinsieme UMT dell'API di controllo dei file. Il modello di chiusura può essere:
- Non recuperabile
- Per gli aggiornamenti dei CFDT non recuperabili, i blocchi non durano fino al punto di sincronizzazione (vengono rilasciati al completamento della richiesta di controllo del file) e gli aggiornamenti non vengono annullati se un'unità di lavoro fallisce
- Recuperabile
- I CFDT sono recuperabili in caso di guasto di un'unità di lavoro e in caso di guasto di una regione CICS, di un server CFDT e di un guasto z/OS® (gli aggiornamenti effettuati dalle unità di lavoro che erano in volo al momento del guasto vengono annullati).
Il modello di chiusura recuperabile supporta i fallimenti di indoubt e backout: se un'unità di lavoro fallisce durante il backout di un aggiornamento al CFDT, o se fallisce indoubt durante l'elaborazione del punto di sincronizzazione, i blocchi vengono convertiti in blocchi conservati e l'unità di lavoro viene spostata.
Le CFDT non possono essere recuperate a posteriori. Un CFDT non sopravvive alla perdita della struttura CF in cui risiede.
Si può specificare il modello di aggiornamento desiderato per ogni tabella nella definizione della risorsa file, consentendo a tabelle diverse di utilizzare modelli diversi.