ARM in einem IBM MQ -Netz verwenden

Sie können Ihren Warteschlangenmanager so konfigurieren, dass die Kanalinitiatoren und die zugeordneten Empfangsprogramme automatisch gestartet werden, wenn der Warteschlangenmanager erneut gestartet wird.

Gehen Sie wie folgt vor, um einen vollständig automatischen Neustart des Warteschlangenmanagers auf demselben z/OS® -Image für LU 6.2 und TCP/IP-Kommunikationsprotokolle sicherzustellen:

Starten Sie die Empfangsprogramme automatisch, indem Sie den entsprechenden Befehl START LISTENER zum CSQINPX-Datensatz hinzufügen.
Starten Sie den Kanalinitiator automatisch, indem Sie den entsprechenden Befehl START CHINIT zur Datei CSQINP2 hinzufügen.

Informationen zum erneuten Starten eines Warteschlangenmanagers mit TCP/IP oder LU6.2 finden Sie unter.

Informationen zu den Dateien CSQINP2 und CSQINPX finden Sie unter Aufgabe 13: Initialisierungseingabedateien anpassen .

Neustart auf einem anderen z/OS -Image mit TCP/IP

Wenn Sie TCP/IP als Kommunikationsprotokoll verwenden und virtuelle IP-Adressen verwenden, können Sie diese für die Wiederherstellung auf anderen z/OS -Images konfigurieren, sodass Kanäle, die eine Verbindung zu diesem Warteschlangenmanager herstellen, ohne Änderungen wiederhergestellt werden können. Andernfalls können Sie eine TCP/IP-Adresse nach dem Verschieben eines Warteschlangenmanagers in ein anderes z/OS -Image nur neu zuordnen, wenn Sie Cluster verwenden oder wenn Sie eine Verbindung zu einer Gruppe mit gemeinsamer Warteschlange unter Verwendung eines logischen DNS-Gruppennamens (DNS-Domain Name System) des WLM herstellen.

Bei Verwendung von Clustering

z/OS ARM reagiert auf einen Systemfehler durch einen Neustart des Warteschlangenmanagers auf einem anderen z/OS -Image in demselben Sysplex. Dieses System hat eine andere TCP/IP-Adresse als das ursprüngliche z/OS -Image. Im Folgenden wird erläutert, wie Sie mithilfe von IBM® MQ -Clustern die TCP/IP-Adresse eines Warteschlangenmanagers neu zuordnen können, nachdem er durch einen ARM-Neustart in ein anderes z/OS -Image verschoben wurde.

Wenn ein Client-WS-Manager den Warteschlangenmanagerfehler (als Kanalfehler) feststellt, antwortet er, indem er geeignete Nachrichten in seiner Clusterübertragungswarteschlange auf einen anderen Server-WS-Manager, der eine andere Instanz der Zielclusterwarteschlange enthält, erneut zuweist. Sie kann jedoch keine Nachrichten erneut zuordnen, die durch Affinitätseinschränkungen an den ursprünglichen Server gebunden sind, oder Nachrichten, die sich im Zweifel befinden, weil der Warteschlangenmanager des Servers während der Verarbeitung des Stapelverarbeitungs-Stapeljobs fehlgeschlagen ist. Gehen Sie wie folgt vor, um diese Nachrichten zu verarbeiten:

Ordnen Sie jedem z/OS -Warteschlangenmanager einen anderen Clusterempfängerkanalnamen und einen anderen TCP/IP-Port zu. Jeder Warteschlangenmanager benötigt einen anderen Port, damit zwei Systeme einen einzelnen TCP/IP-Stack auf einem z/OS -Image gemeinsam nutzen können. Eine davon ist der Warteschlangenmanager, der ursprünglich auf diesem z/OS -Image ausgeführt wird, und die andere ist der Warteschlangenmanager, den ARM nach einem Systemausfall auf diesem z/OS -Image erneut startet. Konfigurieren Sie jeden Port auf jedem z/OS -Image, damit ARM jeden Warteschlangenmanager auf jedem z/OS -Image erneut starten kann.
Erstellen Sie für jede Kombination aus Warteschlangenmanager und z/OS -Image eine andere Eingabedatei für den Kanalinitiatorbefehl (CSQINPX), auf die beim Start des Kanalinitiators verwiesen werden soll.
Jede CSQINPX-Datei muss einen für diesen Warteschlangenmanager spezifischen Befehl START LISTENER PORT (port) und einen Befehl ALTER CHANNEL für einen Clusterempfängerkanal enthalten, der für diese Kombination aus Warteschlangenmanager und z/OS -Image spezifisch ist. Der Befehl ALTER CHANNEL muss den Verbindungsnamen auf den TCP/IP-Namen des z/OS -Image setzen, auf dem er erneut gestartet wird. Sie muss die Portnummer, die für den neu gestarteten Warteschlangenmanager spezifisch ist, als Teil des Verbindungsnamens enthalten.

Die Start-JCL jedes Warteschlangenmanagers kann einen festen Dateinamen für diese CSQINPX-Datei haben und jedes z/OS -Image muss eine andere Version jeder CSQINPX-Datei auf einem nicht gemeinsam genutzten DASD-Datenträger haben.

Wenn ein ARM-Neustart erfolgt, macht IBM MQ die geänderte Kanaldefinition für das Cluster-Repository zugänglich, das sie wiederum für alle Client-Warteschlangenmanager veröffentlicht, die ein Interesse am Server-Warteschlangenmanager bekundet haben.

Der Client-WS-Manager behandelt den Ausfall des Server-WS-Managers als Kanalfehler und versucht, den fehlgeschlagenen Kanal erneut zu starten. Wenn der Client-WS-Manager den neuen Server verbindungsname erlernt, verbindet der Kanalneustart den Client-WS-Manager mit dem neu gestarteten Server-WS-Manager. Der Client-WS-Manager kann dann seine Nachrichten resynchronisieren, alle unbestätigten Nachrichten in der Übertragungswarteschlange des Clientwarteschlangenmanagers auflösen und die normale Verarbeitung fortgesetzt werden.

Beim Herstellen einer Verbindung zu einer Gruppe mit gemeinsamer Warteschlange

Wenn Sie eine Verbindung zu einer Gruppe mit gemeinsamer Warteschlange über den logischen Gruppennamen des dynamischen DNS für eine TCP/IP-Adresse herstellen, gibt der Verbindungsname in Ihrer Kanaldefinition den logischen Gruppennamen Ihrer Gruppe mit gemeinsamer Warteschlange an und nicht den Hostnamen oder die IP-Adresse einer physischen Maschine. Beim Start dieses Kanals wird eine Verbindung zum dynamischen DNS und anschließend zu einem der Warteschlangenmanager in der Gruppe mit gemeinsamer Warteschlange hergestellt. Dieser Prozess wird in Kommunikation für IBM MQ for z/OS mithilfe von Gruppen mit gemeinsamer Warteschlange einrichtenerläutert.

Im unwahrscheinlichen Fall eines Imagefehlers tritt einer der folgenden Fehler auf:

Die Warteschlangenmanager auf dem fehlerhaften Image werden aus dem dynamischen DNS, das auf Ihrem Sysplex ausgeführt wird, entfernt. Der Kanal antwortet auf den Verbindungsfehler durch Eingabe des Status RETRYING und stellt dann eine Verbindung zu dem dynamischen DNS her, das auf dem Sysplex ausgeführt wird. Das dynamische DNS ordnet die eingehende Anforderung einem der übrigem Mitglieder der Gruppe mit gemeinsamer Warteschlange zu, das noch immer in den verbleibenden Images ausgeführt wird.
Wenn kein anderer Warteschlangenmanager in der Gruppe mit gemeinsamer Warteschlange aktiv ist und ARM den Warteschlangenmanager und den Kanalinitiator erneut in einem anderen Image startet, wird der Gruppenlistener mit dem dynamischen DNS von diesem neuen Image registriert. Dies bedeutet, dass der Name der logischen Gruppe (aus dem Feld für den Verbindungsnamen des Kanals) eine Verbindung zum dynamischen DNS herstellt und dann mit demselben Warteschlangenmanager verbunden ist, der jetzt auf einem anderen Image ausgeführt wird. Für die Kanaldefinition war keine Änderung erforderlich.

Damit diese Art der Wiederherstellung ausgeführt werden kann, müssen die folgenden Punkte beachtet werden:

Unter z/OSwird das dynamische DNS auf einem der z/OS -Images im Sysplex ausgeführt. Wenn dieses Image fehlschlagen würde, muss der dynamische DNS so konfiguriert werden, dass im Sysplex ein sekundärer Namensserver aktiv ist, der als Alternative zum primären Namensserver agiert. Informationen zu primären und sekundären dynamischen DNS-Servern finden Sie im Handbuch OS/390® SecureWay CS IP Configuration
Der TCP/IP-Gruppenlistener wurde möglicherweise an einer bestimmten IP-Adresse gestartet, die in diesem z/OS -Image möglicherweise nicht verfügbar ist. Ist dies der Fall, muss das Empfangsprogramm unter Umständen in einer anderen IP-Adresse auf dem neuen Image gestartet werden. Wenn Sie virtuelle IP-Adressen verwenden, können Sie diese für die Wiederherstellung auf anderen z/OS -Images konfigurieren, sodass keine Änderung des Befehls START LISTENER erforderlich ist.

Neustart auf einem anderen z/OS -Image mit LU 6.2

Wenn Sie nur LU 6.2 -Kommunikationsprotokolle verwenden, führen Sie die folgende Prozedur aus, um die Netzverbindung nach dem automatischen Neustart eines Warteschlangenmanagers auf einem anderen z/OS -Image im Sysplex zu aktivieren:

Definieren Sie jeden WS-Manager innerhalb des Sysplex mit einem eindeutigen Subsystemnamen.
Definieren Sie jeden Kanalinitiator innerhalb des Sysplex mit einem eindeutigen LUNAME. Diese Angabe wird sowohl in den WS-Managerattributen als auch im Befehl START LISTENER angegeben.
Hinweis: Der LUNAME benennt einen Eintrag in der APPC-Nebentabelle, der diesen wiederum dem tatsächlichen LUNAME zuordnet.
Richten Sie eine gemeinsam genutzte APPC-Nebentabelle ein, die von jedem z/OS -Image im Sysplex referenziert wird. Dieser Eintrag muss einen Eintrag für jeden LUNAME des Kanalinitiators enthalten. Weitere Informationen hierzu finden Sie unter „ z/OS MVS -Planung: APPC/ MVS -Management “.
Richten Sie ein Member APPCPM xx von SYS1.PARMLIB für jeden Kanalinitiator innerhalb des Sysplex ein, um eine LUADD-Datei zu enthalten, um den APPC-seitigen Tabelleneintrag für diesen Kanalinitiator zu aktivieren. Diese Member sollten von jedem z/OS -Image gemeinsam genutzt werden. Das entsprechende SYS1.PARMLIB wird durch einen z/OS -Befehl SET APPC = xxaktiviert, der automatisch während des ARM-Neustarts des Warteschlangenmanagers (und seines Kanalinitiators) in einem anderen z/OS -Image ausgegeben wird, wie im folgenden Text beschrieben.
Verwenden Sie das WS-Manager-Attribut LU62ARM, um das Suffix xx dieses SYS1.PARMLIB-Members für jeden Kanalinitiator anzugeben. Dies bewirkt, dass der Kanalinitiator den erforderlichen z/OS -Befehl SET APPC= xx ausgibt, um seinen LUNAME zu aktivieren.

Definieren Sie Ihre ARM-Richtlinie so, dass sie den Kanalinitiator nur erneut startet, wenn er fehlschlägt, während das zugehörige z/OS -Image aktiv bleibt. Die Benutzer-ID, die dem XCFAS-Adressraum zugeordnet ist, muss berechtigt sein, den IBM MQ -Befehl START CHINIT auszugeben. Starten Sie den Kanalinitiator nicht automatisch erneut, wenn auch sein z/OS -Image fehlschlägt. Verwenden Sie stattdessen Befehle in den CSQINP2 -und CSQINPX-Dateien, um den Kanalinitiator und die Empfangsprogramme zu starten.