Im Journalumfeld gibt es eine ganze Reihe von Tipps und Tricks, die die Arbeit deutlich erleichtern können. In diesem und im nächsten Artikel dieser Serie möchte ich Ihnen einige nützliche Hinweise für das Arbeiten mit Journalen geben.

Eine einfache Methode, um die Zahl der Journaleinträge zu verringern, besteht darin, Open- und Close-Operationen nicht im Journal aufzeichnen zu lassen. Wird der Befehl STRJRNPF mit den Standardangaben verwendet, so wird jede Open- oder Close-Operation im Journal aufgezeichnet (siehe Abb. 1).

                    Aufz. der phys. Datei starten (STRJRNPF)           
                                                                       
 Auswahl eingeben und Eingabetaste drücken.                            
                                                                       
 Aufzuzeichnende phys. Datei  . .                 Name                 
   Bibliothek . . . . . . . . . .     *LIBL       Name, *LIBL, *CURLIB 
      + für weitere Werte                                              
                                      *LIBL                            
 Journal  . . . . . . . . . . . .                 Name                 
   Bibliothek . . . . . . . . . .     *LIBL       Name, *LIBL, *CURLIB 
 Satzabbilder . . . . . . . . . .   *AFTER        *AFTER, *BOTH        
 Wegzulassende Journaleinträge  .   *NONE         *NONE, *OPNCLO       

Diese Informationen können für die Analyse von Performanceproblemen oder im Debugging durchaus hilfreich sein – im normalen Anwendungsbetrieb erzeugen sie jedoch Journaleinträge, die weder für die Datenbank-Recovery nach einem abnormalen Systemende noch für APYJRNCHG bzw. RMVJRNCHG oder von journalbasierten Hochverfügbarkeitslösungen benötigt werden.

Seit V5R3 kann die Aufzeichnung von Open/Close-Operationen durch einen einfachen Befehl beendet oder gestartet werden (siehe Abb. 2; in älteren Releases war dies nur über ein ENDJRNPF und ein anschließendes STRJRNPF mit entsprechenden Parametern möglich).

                      Objektaufzeichnung ändern (CHGJRNOBJ)
 
 Auswahl eingeben und Eingabetaste drücken.
 
 Objekte:
   Objekt . . . . . . . . . . . . > *ALL          Name, *ALL
     Bibliothek . . . . . . . . .     *LIBL       Name, *LIBL, *CURLIB
   Objektart  . . . . . . . . . . > *FILE         *FILE, *DTAARA
      + für weitere Werte   
 Attribut . . . . . . . . . . . . > *OMTJRNE      *IMAGES, *OMTJRNE...
 Journaleintrag übergehen . . . . > *OPNCLOSYN    *SAME, *NONE, *OPNCLOSYN

Die Angabe von *OPNCLOSYN für den Parameter „Journaleinträge übergehen“ entspricht dabei dem „Wegzulassende Journaleinträge *OPNCLO“ im Befehl STRJRNPF.

Einen weiteren Unterschied gibt es zwischen Dateien, für die die Journalisierung manuell gestartet wurde und zwischen SQL-Tabellen, für die das System eine automatische Journalisierung startet. Bei einer automatischen Journalisierung werden Open/Close-Einträge per Default nicht aufgezeichnet – bei einer manuell gestarteten Journalisierung werden per Default alle Einträge in das Journal geschrieben.

Automatische Journalisierung neuer Objekte

Ein häufiges Problem im Bereich Journalisierung ist, dass auch neu erstellte Objekte von Anfang an journalisiert werden sollten. Nur so ist im Falle eines abnormalen Systemendes eine saubere und vollständige Recovery der Daten möglich. Wurde die Bibliothek über SQL erstellt (CREATE COLLECTION) und werden die Dateien dort ebenfalls über SQL erstellt (CREATE TABLE), so wird die Journalisierung automatisch vom Betriebssystem zum Zeitpunkt der Dateierstellung gestartet, wenn in der betroffenen Bibliothek ein Journal ­QSQJRN vorhanden ist.

Anders sieht es dagegen aus, wenn mit CRTLIB und DDS-beschriebenen Dateien gearbeitet wird. Hier liegt es in der Verantwortung der Anwendungsentwickler, für die Journalisierung neuer Objekte zu sorgen. Dies kann entweder manuell geschehen – was entsprechend fehleranfällig ist – oder über eine spezielle Dataarea mit dem Namen QDFTJRN für einzelne Bibliotheken automatisiert werden. Die Daten in dieser Dataarea teilen dem Betriebssystem mit, welches Journal verwendet werden soll, welche Objekte automatisch journalisiert werden sollen (Dateien, Dataareas und Dataqueues) und bei welchen Operationen die Journalisierung automatisch gestartet werden soll (Create, Move oder Restore).

Werden nach Erstellung der Dataarea neue Objekte vom Typ *FILE, *DTAARA oder *DTAQ der Bibliothek hinzugefügt, so entscheidet das Betriebssystem anhand der Einträge in der Dataarea QDFTJRN in dieser Bibliothek, ob die Journalisierung für dieses Objekt automatisch gestartet werden soll oder nicht.

Die Informationen in der Dataarea QDFTJRN müssen ein bestimmtes Format aufweisen. Die Dataarea muss mindestens 40 Bytes lang sein und den Typ Character haben. Der Aufbau der Dataarea wird in der Tabelle dargestellt.

Offset Feld Beschreibung
1 Bibliotheksname Bibliothek, in der das zu verwendende Journal liegt
11 Journalname Journal, das für die automatische Journalisierung neuer Objekte verwendet werden soll
21 Objektart/
Operationen-Paarungen
+ 10 Objekttyp Objektarten, die automatisch journalisiert werden sollen. Das Feld muss einen der folgenden Werte haben:
*FILE – nur physische Dateien
*DTAARA – nur Dataareas
*DTAQ – nur Dataqueues
*ALL – alle drei vorgenannten Objekttypen
+ 10 Operation Operationen, die eine automatische Journalisierung auslösen sollen. Defaultwert ist hier *CREATE. Das Feld muss einen der folgenden Werte haben:
*ALLOPR – beinhaltet move, create und restore
*CREATE – Neuerstellung von Objekten einschließlich CRTDUPOBJ oder CPYF
*MOVE – wird ein Objekt in die Bibliothek verschoben, erfolgt automatische Journalisierung
*RESTORE – ein Zurückspeichern eines Objekts erzeugt eine automatische Journalisierung
*RSTOVJRN – die Bedeutung dieses Eintrags wird im nach­folgenden Text detailliert erläutert

Die Paarung aus Objektart und Operation kann beliebig oft innerhalb der Dataarea wiederholt werden. Treten dabei Wiederholungen auf, so wird das erste gefundene Paar in der Dataarea verwendet.

Achtung: Alle Einträge in der Dataarea müssen in Großbuchstaben erfolgen, da ansonsten die entsprechenden Objekte nicht gefunden werden.

Kann die automatische Journalisierung nicht gestartet werden, wenn ein neues Objekt erstellt wird, weil z. B. das Journal, das in der Dataarea angegeben wurde, gar nicht existiert, so wird das neue Objekt trotzdem erstellt. Zusätzlich wird eine entsprechende Fehlermeldung (CPI6954 – Objekt kann nicht journalisiert werden) ausgegeben. Für die automatische Journalisierung werden wie aus dem SQL-Umfeld bekannt Open- und Close-Operationen nicht mit im Journal aufgezeichnet. Außerdem werden nur die After-Images im Journalreceiver festgehalten.

Berechtigungen

Damit die Journalisierung erfolgreich automatisch gestartet werden kann, muss auch auf die notwendigen Berechtigungen geachtet werden. Anwendungen, die neue Objekte erstellen, führen durch die Automatisierung auch einen STRJRNPF-Befehl aus – und benötigen somit Berechtigungen für das Journal, das in der Dataarea hinterlegt ist. Der entsprechende Benutzer benötigt *OBJOPR- und *OBJMGT-Berechtigung für das Journal selbst und *EXECUTE-Berechtigung für die Bibliothek, in der das Journal steht. Diese Berechtigungen bedeuten allerdings nicht, dass der Benutzer auch die Daten im Journal sehen kann – diese werden im Journalreceiver abgelegt – und nur wenn auch eine Zugriffsberechtigung auf den Journalreceiver besteht, kann auch der Inhalt von Journaleinträgen gelesen werden.

Verschiebung von Objekten

Was genau passiert, wenn ein Objekt aus einer Bibliothek in eine andere Bibliothek verschoben wird, in der die QDFTJRN Dataarea existiert? Wenn das Objekt schon in der alten Bibliothek journalisiert wurde, ändert sich nichts – das Objekt wird auch in der neuen Bibliothek weiterhin in das alte Journal journalisiert. Die QDFTJRN Dataarea kommt nur dann zum Tragen, wenn das Objekt in der alten Bibliothek nicht journalisiert wurde.

Restore mit dem Eintrag *RESTORE in QDFTJRN

Was passiert, wenn eine Datei z. B. auf einem Testsystem mit Journaling erstellt, dort gesichert und dann auf ein anderes System zurückgespielt wird? Standardmäßig wird immer zuerst versucht, das zurückgespeicherte Objekt wieder an das „alte“ Journal zu hängen. Nur wenn entweder die ursprüngliche Journalbibliothek oder das ursprüngliche Journal nicht auf dem neuen System gefunden werden, wird die QDFTJRN Dataarea mit den entsprechenden Einträgen verwendet. Wurde die Datei auf dem Ursprungssystem nicht journalisiert, so kommt sofort die QDFTJRN Dataarea zum Einsatz.

Restore mit dem Eintrag *RSTOVRJRN in QDFTJRN

Wie kann man nun vorgehen, wenn man eine journalisierte Datei z. B. zu Testzwecken aus der Produktivbibliothek sichern und in eine andere Bibliothek zurückspeichern möchte – und dabei zwar weiter journalisieren möchte – aber eben nicht in das Produktivjournal? Diese Funktion wurde über den Parameter *RSTOVRJRN in V5R4M0 mit einer Reihe von PTFs zur Verfügung gestellt. Notwendig sind die PTFs SI24505, SI24794, SI24812 und SI24864 (oder deren Nachfolger). Wird in der QDFTJRN Dataarea die Option *RSTOVRJRN verwendet – und ein neues Objekt über einen Restore erzeugt (also keine bereits existierende Datei überschrieben), so findet immer der Eintrag in der QDFTJRN Dataarea Verwendung – es kann also sichergestellt werden, dass in einer Testbibliothek auch ein Testjournal verwendet wird. Existiert das zurückgespeicherte Objekt bereits und wird es auch schon journalisiert, so wird das verwendete Journal NICHT ersetzt.

Weitere Tipps und Tricks im Journalumfeld folgen …