Eingabeserialisierung zwischen separaten Ausführungsgruppen, die auf demselben Broker auf z/OS ausgeführt werden

Dieses Beispiel veranschaulicht, dass immer nur jeweils ein MQEmpfangsknoten Nachrichten aus einer gemeinsam genutzten Warteschlange nimmt, wenn Nachrichtenflüsse, die in separaten Ausführungsgruppen ausgeführt werden, dasselbe Serialisierungs-Token verwenden.

Ein identischer Nachrichtenfluss namens MyFlowA wird im Broker MQ01BRK in die Ausführungsgruppen MYGroupA und MYGroupB implementiert.

In diesem Fall muss der Warteschlangenmanager nicht Mitglied einer Gruppe mit gemeinsam genutzter Warteschlange sein. Die Eingabewarteschlange INQueue ist als lokal mit der Disposition QMGR definiert.

Es gelten dieselben Hinweise wie in Serielle Eingabeverarbeitung zwischen separaten Brokern auf z/OS:
Abbildung mehrerer Ausführungsgruppen im selben Broker
Nachfolgend sehen Sie eine typische Folge von Ereignissen für dieses Beispiel:
  1. Der Broker MQ01BRK startet, und als erstes wird der Nachrichtenfluss MyFlowA in der Ausführungsgruppe MyGroupA ausgeführt. Der MQEmpfangsknoten MyInputNode stellt unter Verwendung des Serialisierungs-Tokens MyToken123ABC eine Verbindung zum Warteschlangenmanager MQ01 her. Der MQEmpfangsknoten öffnet erfolgreich die gemeinsam genutzte Warteschlange INQUeue.QSG und erhält seine Eingabenachrichten.
  2. Die zweite Ausführungsgruppe MyGroupB startet, und der Nachrichtenfluss MyFlowA in der Ausführungsgruppe MyGroupB wird ausgeführt. Der MQEmpfangsknoten MyInputNode versucht nun, unter Verwendung des Serialisierungs-Tokens MyToken123ABC eine Verbindung zum Warteschlangenmanager MQ01 herzustellen. Folgende SDSF-Konsolnachricht wird protokolliert:
     BIP2656I MQ01BRK MyGroupB 11 UNABLE TO OPEN QUEUE
     'INQueue' ON WEBSPHERE BUSINESS INTEGRATION QUEUE 
     MANAGER 'MQ01':  BECAUSE SERIALIZATION TOKEN  
     MyToken123ABC is already in use. NO USER ACTION REQUIRED

    Der Nachrichtenfluss MyFlowA, der in der Ausführungsgruppe MyGroupA ausgeführt wird, kann die Eingabe nicht verarbeiten, da das Serialisierungs-Token, das er weitergegeben hat, bereits im Warteschlangenmanager verwendet wird (vom MQEmpfangsknoten im Nachrichtenfluss MyFlowA in der Ausführungsgruppe MyGroupA). Dies wird durch den Ursachencode 2271 (MQRC_CONN_TAG_IN_USE) in der Nachricht bip2623 angezeigt.

  3. Die erste Ausführungsgruppe wird gelöscht oder abgebrochen.

    Wenn die erste Ausführungsgruppe vom Operator abgebrochen wird, abnormal endet oder während einer erneuten Implementierung der Broker-Konfiguration gelöscht wird, kann der Empfangsknoten in der zweiten Ausführungsgruppe nun Eingabenachrichten aus der Warteschlange INQueue empfangen.

    Es werden mehrere SDSF-Konsolnachrichten protokolliert, von denen die nachfolgende von Bedeutung ist:
      BIP2091I MQ01BRK MyGroupB 11 THE BROKER HAS 
     RECONNECTED TO WEBSPHERE BUSINESS INTEGRATION 
     SUCCESSFULLY : ImbCommonInputNode(785)               

Der Nachrichtenfluss MyFlowA, der in der Ausführungsgruppe MyGroupB ausgeführt wird, kann nun die Verarbeitung von Nachrichten aus der gemeinsam genutzten Warteschlange INQueue.QSG wiederherstellen.

Obwohl die Eingabe durch Konfiguration der Eingabewarteschlange für eine exklusive Eingabe auf ähnliche Weise serialisiert werden kann, ist die Nachrichtenintegrität in diesem Fall bei einer Wiederherstellung nicht gewährleistet. Dies lässt sich nur durch die Verwendung eines Serialisierungs-Tokens, wie in diesem Beispiel beschrieben, sicherstellen.

Zugehörige Konzepte
Übersicht zur z/OS-Anpassung
Übersicht über die serielle Nachrichtenverarbeitung unter z/OS
Serielle Eingabeverarbeitung zwischen separaten Brokern auf z/OS
Serielle Eingabeverarbeitung in einer Ausführungsgruppe auf z/OS
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ae27020_