Empfehlungen für die Neugenerierung einer Anwendung

Beim Betrieb einer UTM-Anwendung ist es manchmal unumgänglich, eine Anwendung neu zu generieren.

Für UTM-Cluster-Anwendungen auf Unix-, Linux- oder Windows-Systemen gibt es einerseits Änderungen, die mit einer Neugenerierung der KDCFILE bei laufender UTM-Cluster-Anwendung gemacht werden können, andererseits Änderungen, die man nur durchführen kann, wenn die UTM-Cluster-Anwendung vollständig beendet wurde.

Eine Liste der Änderungen, die vor dem Start mit der neuen KDCFILE ein vollständiges Beenden der UTM-Cluster-Anwendung erfordern, finden Sie im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“

Mögliche Gründe für einen erneuten KDCDEF-Lauf sind:

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

• Für die verteilte Verarbeitung über OSI TP und LU6.1 müssen möglicherweise neue Objekte erzeugt werden, weil sich beispielsweise 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 (BS2000-Systeme), Shared Objects (Unix- und Linux-Systeme) oder DLLs (Windows-Systeme) 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 werden oder zum Löschen vorgemerkte Objekte müssen endgültig gelöscht werden, um die Tabellenplätze und die Namen der Objekte zur Wiederverwendung freizugeben.

Die Ausfallzeit Ihrer Anwendung, die eine Neugenerierung mit sich bringt, können Sie verringern, wenn Sie die folgenden Empfehlungen beachten:

• Teilen Sie bereits bei der Erstgenerierung Ihrer Anwendung die KDCDEF-Steueranweisungen auf verschiedene Dateien auf, und zwar getrennt nach nur statisch zu generierenden und dynamisch eintragbaren Objekten, die Sie KDCDEF als Input-Dateien mit der Anweisung OPTION DATA= zur Verfügung stellen.

• Schreiben Sie die Steueranweisungen USER, LTERM, PTERM, PROGRAM, TAC, CON, KSET, LSES und LTAC jeweils nach Objektgruppen getrennt in Dateien, damit Sie bei einer Neugenerierung der Anwendung diese Dateien einfach durch die vom inversen KDCDEF erzeugten Dateien (DEVICE, PROGRAM, USER, CON, KSET, LSES und LTAC) ersetzen können. Siehe dazu auch Abschnitt "CREATE-CONTROL-STATEMENTS - KDCDEF-Steueranweisungen erzeugen".

Vor einer Neugenerierung der Anwendung und vor dem inversen KDCDEF-Lauf empfiehlt es sich alle Objekte, die in der neuen Konfiguration nicht mehr enthalten sein sollen, dynamisch mit dem Aufruf KC_DELETE_OBJECT zu löschen. Siehe dazu das openUTM-Handbuch „Anwendungen administrieren“.

In UTM-Cluster-Anwendungen müssen Objekte, die sich dynamisch administrieren lassen, immer administrativ gelöscht werden. Ein Löschen nur in der KDCDEF-Source führt zu Inkonsistenzen in den einzelnen Knoten-Anwendungen der UTM-Cluster-Anwendung.

Das dynamische Löschen hat gegenüber dem manuellen Löschen der zugehörigen Steueranweisungen aus der Input-Datei für den KDCDEF-Lauf folgende Vorteile:

• Wird bei der Neugenerierung ein Objekt aus der Input-Datei manuell gelöscht und im selben Generierungslauf ein Objekt gleichen Typs und Namens aber mit anderen Eigenschaften neu definiert, dann kann das im Anschluss laufende Tool KDCUPD die Objekte nicht als zwei verschiedene Objekte erkennen und überträgt die Daten des gelöschten Objekts für das neue Objekt in die KDCFILE. Dieses unerwünschte Verhalten tritt nicht auf, wenn Sie das Objekt zuvor dynamisch löschen und dann bei der Neugenerierung ein Objekt gleichen Typs und Namens erzeugen. In diesem Fall erkennt KDCUPD, dass es sich um verschiedene Objekte handelt und überträgt die Daten des alten Objekts nicht in die neue KDCFILE.

• Das manuelle Löschen von KDCDEF-Anweisungen aus der KDCDEF-Eingabedatei 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. Sie können in einer Prozedur den inversen KDCDEF aufrufen und die von ihm erzeugten Dateien dem KDCDEF direkt zur Verfügung stellen. Im Anschluss daran kann die Prozedur das Tool KDCUPD aufrufen. Durch diesen vollautomatischen prozeduralen Ablauf wird die Ausfallzeit bei einer Neugenerierung minimiert.

Um unerwünschte Folgen zu vermeiden, beachten Sie bitte beim dynamischen Löschen, ob für Objekte, die in der laufenden Anwendung dynamisch gelöscht bzw. gesperrt werden, nicht noch wartende Aufträge etc. existieren.