Das Systemjournal

Eine Datenbank ist ein großer Aktenschrank. Schön organisiert und strukturiert liegen Unternehmensdaten bereit und warten auf ihre Verwendung. Neben diesen Aktenschrank steht eine Tonne. Es ist eine unscheinbare Tonne. Sie hat keine grellen Farben oder wird in schicker Verpackung geliefert und was sie schon gar nicht hat, ist eine Schleife oben drauf. Diese unscheinbare Tonne neben den Aktenschrank ist das Journal.

Und obgleich es zwar bekannt ist und auch so beschrieben sein könnte wird es hier wie folgt formuliert: Wie durch Geisterhand, über Umwege über ein Paralleluniversum, liegen in dieser Tonne nicht nur sämtliche aktuellen Daten, die auch im Aktenschrank liegen, sondern sämtliche Versionen der Selbigen. Oft fragt man nun: Wirklich? Und die Antwort lautet schlicht: Ja, sämtliche Versionen sämtlicher Daten. Also alle Datenveränderungen. Jedes veränderte Bit!

Weshalb wird es dann nicht verwendet? Anlässe gäbe es in der IT genug: Historische Datenhaltung, Daten- und Prozessanalysen, Katastrophen-Szenarien und Fehlerfälle, Flussdiagramme oder einfach die Schaffung eines Überblicks der Datenveränderung. Möglichkeiten Prozesse zu optimieren, Zeit, Geld und andere Ressourcen zu entlasten sowie zu schonen.

Die Antwort darauf ist einfach: Es wird deshalb selten verwendet, weil eine Tonne nicht einfach zu bedienen ist. Es ist naturgemäß nicht möglich in eine Tonne Unmengen an Papier zu werfen und eine Ordnung vorzufinden, wie im besagten Aktenschrank.

Das System stellt für die Anzeige und Datenextraktion ihres eigenen Journals lediglich einen Befehl zur Verfügung der über 30 Parameter hat. Dabei muss man eine eiserne Befehlsregel kennen: Der Befehl beschleunigt einen Prozess des Menschen; ein Parameter des Befehls verlangsamt den Prozess des Menschen. Anders formuliert: Es ist kein benutzerfreundlicher Befehl, nicht wirklich praxisnah und vor allem anderen ist er nicht hübsch.

Die Journal Werkzeugsammlung schließt diese Lücke und vereinfacht den Überblick, die Steuerung und die Handhabung der Journale. Aufgrund des erleichterten Zugangs verändert sich das Bewusstsein der Mitarbeiter bezüglich der Möglichkeiten dieses Systemfeatures.

Journale und ein leichter Zugang zu deren Fähigkeiten können viele IT-Prozesse optimieren.

       I. Journal Dienst

Der Journal-Dienst dient der Handhabung der System-Journale. Er überwacht und reorganisiert die Empfänger und stellt komprimierte und gruppierte Daten zur Verfügung.

Der Dienst ist ressourcenschonend und darauf ausgelegt pro Journal zu arbeiten. So können Journale gesteuert werden und dabei jedes Journal individuelle Einstellungen aufweisen bzw. unterschiedlich behandelt werden.

Der Dienst überwacht anhand einer freien Definition die Objekte. Dabei können Objekte im Journal registriert oder Aufzeichnungen beendet werden. Dies ist eine optionale Möglichkeit eine lückenlose Überwachung zu gewährleisten.

a. Journal Empfänger

Die Journal Empfänger beinhalten die eigentlichen Unternehmensdaten und müssen regelmäßig reorganisiert werden. Dabei ist ein komplexes Regelwerk zu beachten, welches aber über einfache Mechanismen reguliert werden kann.

  • Aufbewahrungsdauer
  • Verarbeitungsintervall
  • Erlaubter Sicherungsstatus des Empfängers bei einer Löschung usw.

Vom Navigationswerkzeug bereitgestellte statistische Auswertungen helfen beim Finden von Speicherfressern und der Balance zwischen Aufbewahrungsdauer, Inhalt und Ressourcenverbrauch der Empfänger.

b. Journal Navigation

Die Navigation durch die Journaldaten erfolgt über einen Befehl und ein interaktives Programm, mit welchem der Benützer über die Informationen

  • Objekt,
  • Programm,
  • Benutzerprofil und
  • Jobinformation

… zu den gesuchten Daten gelangt.

Mit verschieden Auswahlmöglichkeiten können Journaldaten behandelt bzw. betrachtet werden:

  • Systemeigener Befehl DSPJRN wird mit Navigationsdaten befüllt und bereitgestellt
  • Werkzeugeigene Anzeige der Detailschritte der gefilterten Daten
  • Weitere Befehle der Journal Werkzeugsammlung

     II. Journal Aufzeichnungen verfolgen

Datenverfolgung ist einer der häufigsten Analysevorgänge des Softwareentwicklers. Es muss dabei oft ein fachlicher Fall über dutzende Programme hinweg, über tausende Codezeilen verfolgt werden. Oft genug im trockenen Modus. Eine Trockenanalyse bedeutet der Softwareentwickler muss sich vorstellen was wo steht und in welchem Zustand es ist. Er weiß es nicht wirklich. Und das tausende Zeilen lang. Selbstredend ist dies ein zeitaufwendiger Prozess, welcher nur mit großer Aufmerksamkeit und hochkonzentriert durchgeführt wird. Macht besagte Person dabei nur einen Fehler und sei es auch noch so ein kleiner unscheinbarer, so stellt sich dies unter Umständen viel später heraus und die Analyse beginnt von vorne. Sofern der Analysefehler überhaupt entdeckt wird!

Aber darüber ist sich die IT im Klaren und erfand den Debug-Prozess. Wirklich eine tolle Sache, dieser Debug-Prozess. Dadurch schwimmen Softwareentwickler mit den Daten mit. Von Trockenanalyse ist hier nicht mehr die Rede.

Doch was, wenn ein Geschäftsfall schon vorbei ist und im produktiven Betrieb ist dies immer so. Diese Lücke wird von der Möglichkeit des Journals geschlossen, prompt und einfach fachliche Fälle zu verfolgen.

   III. Journal Aufzeichnungen empfangen

Um auf Unternehmensdaten auf gewohnte Weise zugreifen, sie auswerten zu können müssen diese in ihren Strukturen liegen. Das Journal kennt diese Strukturen nicht, obwohl es sämtliche Information hätte, um zumindest auf die richtige Struktur schließen zu können.

Mit diesem Befehl wird diese Lücke geschlossen. Natürlich hat der Befehl seine Tücken und jeder Softwareentwickler der Datenbanken, die im Journal aufgezeichnet werden, verändert, wird sie nennen können. Aber vor allem nützen Softwareentwickler diesen Befehl. In der Regel wissen die, was sie tun.

  IV. Journal Aufzeichnungen wiederherstellen

Natürlich bietet das Journal die Möglichkeit mittels Befehl Daten wiederherzustellen. Doch praxisnah ist das nicht. Im Falle einer Katastrophe muss dieser Prozess vor allem schnell und verlässlich sein. Im Falle von Tests muss die Wiederherstellung einfach von der Hand gehen, da es unzählig oft wiederholt werden wird.

Dieser Befehl schließt diese Lücken.