Empfehlungen für die Neugenerierung einer Anwendung

Beim Betrieb einer UTM-Anwendung kann es unumgänglich werden, die Anwendung neu zu generieren, d.h. erneut einen KDCDEF-Lauf durchzuführen. Mögliche Gründe können sein:

• Die bei der Generierung festgelegten Maximalwerte müssen angepasst werden.

• Für die verteilte Verarbeitung über LU6.1 oder OSI TP müssen möglicherweise neue Objekte erzeugt werden, weil sich z.B. der Server-Verbund bei der verteilten Verarbeitung vergrößern soll.

  Für die verteilte Verarbeitung über LU6.1 ist ein KDCDEF-Lauf nur dann erforderlich, wenn neue LPAP-Objekte eingefügt werden müssen. Objekte vom Typ CON, LSES und LTAC lassen sich dagegen auch durch dynamische Administration erzeugen (vorausgesetzt es wurden ausreichend Tabellenplätze mit der RESERVE-Anweisung freigehalten).

• Neue Lademodule, Shared Objects oder DLLs müssen in das Anwendungsprogramm eingefügt werden.

• Die reservierten Tabellenplätze für das dynamische Eintragen von Objekten in die Konfiguration sind belegt. Die Tabellen müssen erweitert oder zum Löschen vorgemerkte Objekte müssen endgültig gelöscht werden, um die Tabellenplätze freizugeben.

Die Ausfallzeit Ihrer Anwendung, die eine solche Neugenerierung mit sich bringt, können Sie minimieren. Beachten Sie dazu die folgenden Empfehlungen:

• Bereits bei der Erstgenerierung Ihrer Anwendung sollten Sie die Steueranweisungen für den KDCDEF auf mehrere Dateien verteilen, die Sie KDCDEF dann mit OPTION DATA=zur Verfügung stellen. Insbesondere sollten Sie die Steueranweisungen USER, LTERM, PTERM, PROGRAM, TAC, CON, KSET, LSES und LTAC in separate Dateien schreiben. Dabei sollten die Anweisungen, die zu einer Gruppe gehören (siehe "Starten des inversen KDCDEF"), in eine Datei geschrieben werden. So können Sie diese Dateien bei einer späteren Neugenerierung der Anwendung durch die vom inversen KDCDEF erzeugten Dateien ersetzen.

• Vor einer Neugenerierung der Anwendung und vor dem inversen KDCDEF-Lauf sollten Sie alle Objekte dynamisch aus der Konfiguration löschen (KC_DELETE_OBJECT), die in der neuen Konfiguration nicht mehr enthalten sein sollen. Das dynamische Löschen hat gegenüber dem manuellen Löschen der zugehörigen Steueranweisungen aus der Input-Datei für den KDCDEF folgende Vorteile:

  • Das manuelle Löschen von KDCDEF-Anweisungen aus der KDCDEF-Input-Datei ist unkomfortabel und fehleranfällig. Es muss beim Löschen auf Abhängigkeiten zwischen den Objekten und damit zwischen den KDCDEF-Anweisungen geachtet werden. Werden Abhängigkeiten übersehen, muss der KDCDEF-Lauf wiederholt werden. Die Ausfallzeit wird damit vergrößert.

  • Die Abläufe bei der Neugenerierung können automatisiert werden durch Aufruf des offline inversen KDCDEF mit anschließendem KDCUPD, siehe openUTM-Handbuch „Anwendungen generieren“.

Beim manuellen Löschen eines Objekts können u.U. Daten, die zu den gelöschten Objekten in der KDCFILE gespeichert sind, vom KDCUPD, der im Zusammenhang mit der folgende Neugenerierung durchgeführt wird, in die neue KDCFILE übernommen werden. Dabei ist folgender Fall zu beachten:

Sie wollen für ein bestimmtes Objekt verhindern, dass KDCUPD die Daten aus der alten KDCFILE überträgt, die zu diesem Objekt gehören (z.B. weil das „neue“ Objekt zwar den gleichen Namen und Typ, aber andere Eigenschaften hat). Sie können beim KDCUPD aber nur die Datenübernahme für alle Objekte eines bestimmten Objekttyps ausschließen, nicht aber die Übernahme der Daten für ein bestimmtes Objekt. Sie sollten daher das Objekt dynamisch aus der Konfiguration löschen. In der Neugenerierung sollte das Objekt wieder enthalten sein.

In diesem Fall überträgt KDCUPD die Daten nicht, die zu diesem Objekt gehören, da KDCUPD Daten von gelöschten Objekten nicht überträgt.

Änderungsgenerierung einer UTM-Cluster-Anwendung siehe entsprechendes Unterkapitel im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“.

Beispiel

In der neuen Konfiguration soll ein Transaktionscode enthalten sein mit dem Namen eines Asynchron-Transaktionscodes, der in der „alten“ Konfiguration existierte. Der neue Transaktionscode ruft jedoch einen anderen Service auf (wird einem anderen Teilprogramm zugeordnet). Es sind folgende Fälle zu unterscheiden:

• Die Eigenschaften des „alten“ Transactionscodes wurden geändert:
  In diesem Fall überträgt KDCUPD, wenn Sie TRANSFER ASYNTACS=YES angeben, die Message Queue des „alten“ Transaktionscodes zusammen mit den in der Queue enthaltenen Asynchron-Aufträgen in die neue KDCFILE und ordnet sie dem „neuen“ Transaktionscode zu.
  KDCUPD mit TRANSFER ASYNTACS=NO bewirkt, dass für keinen Asynchron-Transaktionscode die Message Queue aus der alten in die neue KDCFILE übertragen wird.

• Der „alte“ Transaktionscode wurde dynamisch aus der Konfiguration gelöscht, in der neuen Konfiguration ist er wieder enthalten:
  In diesem Fall überträgt KDCUPD, auch wenn Sie TRANSFER ASYNTACS=YES angeben, die Message Queue des „alten“ Transaktionscodes nicht in die neue KDCFILE, weil KDCUPD keine Daten von gelöschten Objekten überträgt.

Entsprechendes gilt für die Message Queues von LTERM-Partnern und USER Queues von Benutzern.