Dezentrale Administrationsprogramme

Wenn die administrierten Anwendungen vollständige Administrationsprogramme verwenden, wie sie im Kapitel „Erstellen eigener Administrationsprogramme" beschrieben sind, liegt die Steuerung eines Administrations-Vorgangs im Wesentlichen bei der administrierten Anwendung. Das Administrationsprogramm muss damit

• eine empfangene Nachricht interpretieren, die von der Administrations-Anwendung oder - z.B. bei automatischer Administration - von einem Anwendungs-eigenen MSGTAC-Programm kommt

• sämtliche Bereiche für den Administrationsaufruf richtig versorgen

• die Returncodes auswerten und darauf reagieren, d.h. bei Fehlern die Administrations-Anwendung benachrichtigen und eventuell die Transaktion zurücksetzen

• die zurückgegebenen Daten auswerten und entscheiden, welche Daten an die Administrations-Anwendung geschickt werden.

Dabei ist es zu empfehlen, für die verschiedenen Administrationsaufgaben entweder einzelne Teilprogramme zu erstellen oder, falls Sie ein komplettes Administrationsprogramm verwenden, das Programm je nach Aufgabe mit unterschiedlichen TACs anzusprechen. Dann wird die Aufgabe anhand des TAC und nicht anhand der Nachricht ausgewählt.

Portable Administrationsprogramme

Wenn Sie Ihre Administrationsprogramme in verschiedenen Anwendungen einsetzen wollen, die auf verschiedenen Plattformen ablaufen, dann können Sie die Programme so schreiben, dass sie sowohl auf Unix-, Linux- und Windows-Systemen als auch auf BS2000-Systemen ablaufen.

Diese Aufgabe wird Ihnen dadurch erleichtert, dass die Programmschnittstelle auf allen Plattformen die gleichen Datenstrukturen besitzt. Sie müssen jedoch folgende Plattform-spezifische Unterschiede beachten:

• Es gibt einzelne Felder und Unterstrukturen, die nur auf einer Plattform eine Bedeutung besitzen.

  • Beim Auslesen von Daten werden Felder, die für die Plattform nicht relevant sind, immer mit binär null belegt.

  • Beim Modifizieren oder Erzeugen von Objekten müssen die Felder, die für die jeweilige Plattform nicht relevant sind, mit binär null belegt werden. Daher sollte das Programm zuerst die Plattform ermitteln, auf dem es abläuft. Dazu muss es das Feld system_type in der Struktur kc_system_par_str auswerten, nachdem es KDCADMI mit folgenden Parametern aufgerufen hat:

    opcode=KC_GET_OBJECT
    subcode1=KC_APPLICATION_PAR
    obj_type=KC_SYSTEM_PAR

    Nach dem Ermitteln der Plattform muss das Programm für die eigentlichen Administrationsaufrufe erst die Felder besetzen, die für alle Betriebssysteme gültig sind. Anschließend belegt es die für die jeweilige Plattform notwendigen Felder.

• Die Sortierreihenfolge der Zeichen ist auf BS2000-Systemen und auf Unix-, Linux- und Windows-Systemen unterschiedlich, da BS2000-Systeme in der Regel einen EBCDIC- und Unix-, Linux- sowie Windows-Systeme einen ISO-Code verwenden.

• Auf BS2000-Anwendungen werden für Namen nur Großbuchstaben verwendet, auf Unix-, Linux- und Windows-Systemen dagegen sowohl Klein- als auch Großbuchstaben.

• Unix, Linux- und Windows-Systeme verwenden normalerweise andere Zeichen-Codierungen als BS2000-Systeme (ASCII/EBCDIC Problematik).

Das folgende Beispiel zeigt ein portables Administrationsprogramm, das in der dezentralen Anwendung ein Lademodul, Shared Object bzw. DLL austauscht. Das Programm prüft, auf welcher Plattform es abläuft, und benutzt das Ergebnis, um im Programm entsprechend zu verzweigen.

Auf Unix-, Linux- und Windows-Systemen wird nur das Shared Object/die DLL ausgetauscht, während auf BS2000-Systemen geprüft wird, ob das Lademodul in einem Common Memory Pool liegt und damit ein Anwendungsaustausch notwendig ist.

 #include <kcadminc.h>       /* Include-Datei fuer die Administration     */
 INIT
 ...
 MGET                         /* Name/Daten des Teilprogramms einlesen    */
 
 ... Eingabe analysieren
 KDCADMI opcode=KC_GET_OBJECT /* Betriebssystem abfragen                  */
 
 KDCADMI opcode=KC_GET_OBJECT
                              /* Aktuelle Version des Lademoduls          */
                              /* ermitteln und prüfen, ob es ueberhaupt   */
                              /* austauschbar ist                         */
  
 if (BS2000)                  /* BS2000-Routine                           */
    { KDCADMI opcode=KC_GET_OBJECT
                              /* Lademodus abfragen und ermitteln, ob das */
                              /* Programm zum Austausch vorgemerkt ist    */
      KDCADMI opcode=KC_MODIFY_OBJECT
                              /* Lademodul austauschen bzw. vormerken,    */
                              /* falls er in Common Memory Pool liegt     */
      if (Common Memory Pool) 
          KDCADMI opcode=KC_CHANGE_APPLICATION
                              /* Anwendung austauschen                    */
    }                         /* Ende der BS20000-Routine                 */
 else                         /* Unix/Linux/Windows-Routine               */
      KDCADMI opcode=KC_MODIFY_OBJECT
                              /* Shared Object/DLL austauschen             */
                              /* Ende der Unix/Linux/Windows-Routine       */
 
 MPUT                         /* Meldung an Initiator                      */
 PEND FI

Das Programm kann noch ergänzt werden um dynamische Generierung (TAC, PROGRAM,...) wie im Beispiel im Abschnitt "Mehrere Administrationsaufrufe".