Come viene mantenuta la congruenza in IBM MQ for z/OS

I dati in IBM® MQ for z/OS® devono essere congruenti con batch, CICS®, IMSo TSO. Qualsiasi dato modificato in uno deve corrispondere a una modifica nell'altro.

Prima che un sistema esegue il commit dei dati modificati, deve sapere che l'altro sistema può apportare la modifica corrispondente. Quindi, i sistemi devono comunicare.

Durante un commit a due fasi (ad esempio in CICS ), un sottosistema coordina il processo. Tale sottosistema viene chiamato il coordinatore; l'altro è il partecipante. CICS o IMS è sempre il coordinatore nelle interazioni con IBM MQe IBM MQ è sempre il partecipante. Nell'ambiente batch o TSO, IBM MQ può partecipare a protocolli di commit a due fasi coordinati da z/OS RRS.

Durante un commit a fase singola (ad esempio in TSO o batch), IBM MQ è sempre il coordinatore nelle interazioni e controlla completamente il processo di commit.

In un ambiente WebSphere® Application Server , la semantica dell'oggetto sessione JMS determina se viene utilizzata la coordinazione di commit a fase singola o a due fasi.

Congruenza con CICS o IMS

La connessione tra IBM MQ e CICS o IMS supporta i seguenti protocolli del punto di sincronizzazione:

Commit a due fasi - per le transazioni che aggiornano le risorse di proprietà di più di un gestore risorse.
Questo è il protocollo syncpoint distribuito standard. Comporta più registrazione e flussi di messaggi rispetto a un commit a fase singola.
Commit a fase singola - per transazioni che aggiornano le risorse di proprietà di un singolo gestore risorse ( IBM MQ).
Questo protocollo è ottimizzato per la registrazione e i flussi di messaggi.
Bypass del punto di sincronizzazione - per le transazioni che coinvolgono IBM MQ ma che non fanno nulla nel gestore code che richiede un punto di sincronizzazione (ad esempio, sfogliare una coda).

In ogni caso, CICS o IMS agisce come gestore del punto di sincronizzazione.

Le fasi del commit a due fasi che IBM MQ utilizza per comunicare con CICS o IMS sono le seguenti:

Nella fase 1, ogni sistema determina in maniera indipendente se ha registrato abbastanza informazioni di recupero nel suo log e può eseguire il commit del suo lavoro.
Al termine della fase, i sistemi comunicano. Se sono d'accordo, ognuno inizia la fase successiva.
Nella fase 2, le modifiche vengono rese permanenti. Se uno dei sistemi termina in modo anomalo durante la fase 2, l'operazione viene completata dal processo di ripristino durante il riavvio.

Illustrazione del processo di commit in due fasi

La Figura 1 illustra il processo di commit a due fasi. Gli eventi nel coordinatore CICS o IMS vengono mostrati nella riga superiore, gli eventi in IBM MQ nella riga inferiore.

Un diagramma che illustra il processo di commit a due fasi, come descritto nel seguente paragrafo. — Figura 1. Il processo di commit a due fasi

I numeri nella sezione seguente sono collegati a quelli mostrati nella figura.

I dati nel coordinatore si trovano in un punto di coerenza.
Un programma applicativo nel coordinatore richiama IBM MQ per aggiornare una coda aggiungendo un messaggio.
Questo avvia un'unità di recupero in IBM MQ.
L'elaborazione continua nel coordinatore fino a quando non viene raggiunto un punto di sincronizzazione dell'applicazione.
Il coordinatore avvia quindi l'elaborazione del commit. I programmi CICS utilizzano un comando SYNCPOINT o una normale chiusura dell'applicazione per avviare il commit. I programmi IMS possono avviare il commit utilizzando una chiamata CHKP, una chiamata SYNC, una chiamata GET UNIQUE all'IOPCB o una normale terminazione dell'applicazione. Inizia la fase 1 dell'elaborazione del commit.
Come il coordinatore inizia l'elaborazione fase 1, così fa IBM MQ.
IBM MQ completa con esito positivo la fase 1, scrive questo fatto nel relativo log e notifica il coordinatore.
Il coordinatore riceve la notifica.
Il coordinatore ha completato correttamente l'elaborazione della fase 1. Ora entrambi i sottosistemi accettano di eseguire il commit delle modifiche dei dati, perché entrambi hanno completato la fase 1 e potrebbero recuperare da eventuali errori. Il coordinatore registra nel suo registro l'istante del commit - la decisione irrevocabile dei due sottosistemi di apportare le modifiche.
Il coordinatore inizia ora la fase 2 dell'elaborazione - l'impegno effettivo.
Il coordinatore notifica a IBM MQ di iniziare la fase 2.
IBM MQ registra l'inizio della fase 2.
La fase 2 è stata completata con esito positivo e questo è ora un nuovo punto di coerenza per IBM MQ. IBM MQ notifica quindi al coordinatore di aver terminato l'elaborazione della fase 2.
Il coordinatore termina l'elaborazione della fase 2. I dati controllati da entrambi i sottosistemi sono ora coerenti e disponibili per altre applicazioni.

Come viene mantenuta la coerenza dopo una terminazione anomala

Quando un gestore code viene riavviato dopo una chiusura anomala, deve determinare se eseguire il commit o il backout delle unità di recupero che erano attive al momento della chiusura. Per alcune unità di recupero, IBM MQ ha informazioni sufficienti per prendere la decisione. Per altri, non lo fa e deve ottenere informazioni dal coordinatore quando la connessione viene ristabilita.

La Figura 1 mostra quattro periodi nelle due fasi: a, b, c e d. Lo stato di un'unità di ripristino dipende dal periodo in cui si è verificata la chiusura. Lo stato può essere uno dei seguenti:

In volo: Il gestore code è terminato prima di terminare la fase 1 (periodo a o b); durante il riavvio, IBM MQ esegue il backout degli aggiornamenti.
In dubbio: Il gestore code è terminato dopo aver terminato la fase 1 e prima della fase 2 (punto c); solo il coordinatore sa se l'errore si è verificato prima o dopo il commit (punto 9). Se si è verificato in precedenza, IBM MQ deve eseguire il backout delle modifiche; se si è verificato in seguito, IBM MQ deve apportare le modifiche ed eseguirne il commit. Al riavvio, IBM MQ attende le informazioni dal coordinatore prima di elaborare questa unità di recupero.
Nel commit: Il gestore code è terminato dopo che ha iniziato la propria elaborazione fase 2 (periodo d); apporta modifiche di cui è stato eseguito il commit.
In backout: Il gestore code è terminato dopo il ripristino di un'unità di ripristino, ma prima del completamento del processo (non mostrato nella figura) durante il riavvio, IBM MQ continua a ripristinare le modifiche.