Vorgehensweise der Modul-Installation

Vor der Modul-Einbindung muss das Standardsystem lauffähig sein. Ins Verzeichnis '<benutzer>@<rechner>:~/src/' wechseln.

1. Eintrag in modules.in

Das neue Modul muss in die Datei

 <benutzer>:~/src/modules.in

eingetragen werden. Im folgenden Beispiel soll das Modul 'mod_beispiel' heißen. Es muss eine neue Zeile mit dem Namen 'mod_beispiel' angelegt werden.

2. Compiler

Damit das Modul vom Compiler berücksichtigt wird, muss hinter dem Modulnamen eine '1' eingegeben werden. Als Whitespaces ist nur der Tabulator zulässig!

3. make modulesdir

Weiter wird mit dem Aufruf:

make modulesdir NICHT! verwenden! (da dadurch falsche Verzeichnisse und leere .ppi's angelegt werden!

 <benutzer>@<rechner>:~/src > make modulesdir

eine leere Verzeichnisstruktur erstellt und folgende Verzeichnisse angelegt:

docs: dieses Verzeichnis ist für Hilfedateien, wie z.B. Dokumentationen vorgesehen, wird aber derzeit nicht bei der Modulentwicklung verwendet.
formscripts: wird nicht mehr verwendet
formular: hier liegen die Quelldateien mit Anwendungsfunktionalität.
- .sr = kompilierte Dateien
- .ssh = include-Dateien
- .ssr = Quellcode-Dateien
- .ssd = diese Dateien werden ausschließlich vom „make“ verwendet und definieren Abhängigkeiten von Formularen und Include-Dateien.
help: hier liegen Dateien mit Hilfetexten, für alle Masken und Felder eines Modules.
images: hier liegen alle Bilder, wie Logos oder Hintergrundbilder als eps- oder jpg.-Dateien, oder Button-Bilder als .gif -Dateien.
maskdef: beinhaltet alle Quelldateien für Masken- und Felddefinitionen.
- .def -files sind die Quellcode-Dateien der Maskendefinitionen.
- .ded-files definieren Abhängigkeiten von Masken und include-files; diese Dateien werden generiert und ausschließlich vom „make“ verwendet.
- .deh-files sind include-Dateien und enthalten Definitionen.

4. Dateien erstellen

Jetzt können die benötigten Dateien in den jeweiligen Verzeichnissen erstellt oder auch eine Archiv-Datei (*.tar, *.tgz) mit den Beispiel-Dateien ausgepackt werden.

make

Danach wird der Compiler mit dem Befehl 'make' aufgerufen (im Verzeichnis ~/src).

Korrektur Fehler

Die vom 'make' angezeigten Fehler müssen korrigiert werden.

Achtung!
Zum nächsten Schritt darf man nur dann übergehen, wenn das 'make' fehlerfrei durchläuft! Enthält das Modul keine neuen oder geänderten Dateien, wird ein 'make'-Aufruf fehlschlagen, weil mit dem Einbeziehen eines neuen Moduls Änderungen erwartet werden. Die Datenbank-Struktur wird aktualisiert. Die Änderungen, die das neue Modul eventuell beinhaltet, werden dabei berücksichtigt.

Das Programm dafür lautet 'reltool' und muss im Verzeichnis

 <benutzer>@<rechner>:~/src/programs

aufgerufen werden.

WICHTIG!
Vorher müssen die ESS-Prozesse heruntergefahren werden. Dafür muss vom Benutzer-'root' der folgende Befehl ausgeführt werden:

 <root>:~ # sh etc/pentaprise/ess/mxrc stopmxsd

Die Datenbank-Prozesse laufen mit diesem Befehl weiterhin.

Der Befehl für eine Postgres-Datenbank kann zum Beispiel wie folgt aussehen:

 pg_dump -U pg_mx001 -s MXDBS | reltool -n mxmask.msk -sfxD -O -

Liegen nach Analyse der Datei reltool.out keine Fehler vor, kann man den folgenden Befehl aufrufen:

 psql MXDBS -U pg_mx001 < reltool.out

Damit werden die Datenbankänderungen aktiv! Die Protokollierung der Aktion wird in die Datei load.prot geschrieben.

Werden durch Module Änderungen an Grundfunktionalitäten des ESS erstellt, so hat hierarchisch immer das Formular des am letzten genannten Modules die höchste Priorität!