MQI-Client: Standardverhalten von Client- und Serververbindungskanälen

In Version 7.0 wurden die Standardeinstellungen für Client-und Serververbindungskanäle für die Verwendung gemeinsam genutzter Dialoge geändert. Diese Änderung hat Auswirkungen auf das Verhalten von Überwachungssignalen und Kanalexits und kann sich auch auf die Leistung auswirken.
Vor Version 7.0wurde jeder Dialog einer anderen Kanalinstanz zugeordnet. Ab Version 7.0nutzen Client-und Serververbindungen standardmäßig einen MQI-Kanal gemeinsam. Mit dem Parameter SHARECNV (Sharing Conversations) geben Sie die maximale Anzahl von Datenaustauschvorgängen an, die über eine bestimmte TCP/IP-Clientkanalinstanz gemeinsam genutzt werden können. Mögliche Werte sind:
SHARECNV(0)
Gibt an, dass kein gemeinsamer Datenaustausch über einen TCP/IP-Socket stattfindet. Die Kanalinstanz verhält sich genau so, als ob es sich um einen Version 6.0 -Server-oder Clientverbindungskanal handelt, und Sie erhalten keine zusätzlichen Funktionen wie bidirektionale Überwachungssignale, die verfügbar sind, wenn Sie SHARECNV auf 1 oder höher setzen. Verwenden Sie den Wert 0 nur, wenn Clientanwendungen vorhanden sind, die nicht ordnungsgemäß ausgeführt werden, wenn Sie SHARECNV auf 1 oder höher setzen.
SHARECNV(1)
Gibt an, dass kein gemeinsamer Datenaustausch über einen TCP/IP-Socket stattfindet. Die Leistung auf verteilten Servern gleicht dem Leistungsverhalten bei einem Wert von 0. Die Funktionalität für den Austausch von Client-Überwachungssignalen (in einem MQGET-Aufruf oder nicht) und Vorauslesen ist verfügbar und das Stilllegen (Quiesce) von Kanälen kann gesteuert werden. Sie können diese Einstellung normalerweise mit vorhandenen Clientanwendungen von Version 6.0 verwenden.
SHARECNV(2) bis SHARECNV(999999999)
Jeder dieser Werte gibt die Anzahl der gemeinsamen Datenaustauschaktionen an. Wenn der Clientverbindungswert SHARECNV nicht dem Serververbindungswert SHARECNV entspricht, wird der niedrigere Wert verwendet. Der Standardwert ist SHARECNV(10). Dies sind 10 Threads für bis zu 10 Client-Datenaustauschaktionen pro Kanalinstanz. Auf verteilten Servern kommt es bei SHARECNV-Kanälen jedoch zu Leistungsproblemen, die, sofern möglich, durch SHARECNV(1) minimiert werden sollten.
Bei allen SHARECNV-Werten ab 1 unterstützt der Kanal die folgenden Funktionen:
  • Bidirektionale Überwachungssignale
  • Administratorstop-quiesce
  • Vorauslesen
  • Asynchrone-konsumieren durch Clientanwendungen
Sie können auch die Option MQCONNX festlegen MQCNO_NO_CONV_SHARING und die Anwendung mit einem Kanal verbinden, bei dem SHARECNV auf einen Wert größer als 1gesetzt ist. Das Ergebnis ist dasselbe wie das Verbinden der Anwendung mit einem Kanal, bei dem SHARECNV auf 1gesetzt ist.

Leistung

Die Änderung in Version 7.0 für die Verwendung gemeinsam genutzter Dialoge und weitere funktionale Erweiterungen, die in Version 8.0eingeführt wurden, können sich auf die Leistung auf verteilten Servern auswirken. Weitere Informationen finden Sie unter Client-und Serververbindungskanäle optimieren.

Überwachungssignale

Ab Version 7.0können Überwachungssignale jederzeit in beide Richtungen über den Kanal fließen. Das Verhalten von SHARECNV(0) und Version 6.0 bedeutet, dass Überwachungssignale nur fließen, wenn ein MQGET -Aufruf wartet.

Kanalexits

Das Verhalten eines Client- oder Serververbindungskanalexits ändert sich, wenn der Kanal den gemeinsamen Datenaustausch verwendet (d. h., wenn SHARECNV größer als 1 ist). Es ist zwar unwahrscheinlich, jedoch möglich, dass die Änderung Auswirkungen auf das Verhalten eines vorhandenen Exits hat. Es ergibt sich folgende Änderung:
  • Durch Sende- oder Empfangsexits kann die MQCD-Struktur in einem MQXR_INIT-Aufruf geändert werden. Die Auswirkungen dieser Exits sind unterschiedlich und hängen davon ab, ob ein Kanal für den gemeinsamen Datenaustausch verwendet wird:
    • Wenn das MQCXP-Feld SharingConversations, das an die Exitinstanz übergeben wird, auf den Wert FALSE gesetzt wird, ist diese Exitinstanz die erste - oder einzige - Datenaustauschaktion, die in der Kanalinstanz ausgeführt wird. Kein anderer Exit kann den MQCD zu diesem Zeitpunkt ändern und am MQCD vorgenommene Änderungen können sich auf die Ausführung des Kanals auswirken.
    • Wenn das MQCXP-Feld SharingConversations, das an die Exitinstanz übergeben wird, auf den Wert TRUE gesetzt wird, ist diese Exitinstanz eine nachfolgende Datenaustauschaktion. In diesem Fall wird die Kanalinstanz von mehreren Datenaustauschaktionen gemeinsam genutzt. Am MQCD in der Exitinstanz vorgenommene Änderungen bleiben im MQCD erhalten, können sich allerdings nicht auf die Ausführung des Kanals auswirken.
  • Sende-, Empfangs- und Sicherheitsexits können den MQCD ändern, wenn das MQCXP-Feld SharingConversations auf den Wert TRUE gesetzt wird. Exitinstanzen in anderen Dialogen können die MQCD-Struktur gleichzeitig ändern. Aktualisierungen einer Exitinstanz können von einer anderen Instanz überschrieben werden. Um die Konsistenz der Felder im MQCD zu gewährleisten ist es deswegen möglicherweise erforderlich, den Zugriff auf den MQCD für diese unterschiedlichen Exitinstanzen zu serialisieren.

Eine Aktualisierung von MQCD, wenn das Feld SharingConversations auf TRUE gesetzt ist, hat keine Auswirkung auf die Kanalausführung. Nur Änderungen, die vorgenommen werden, wenn das Feld MQCXP SharingConversations in einem MQXR_INIT -Aufruf auf FALSEgesetzt ist, ändern das Kanalverhalten.