Beschreibung der Funktionen

In Sets einfügen

BINILOAD kann Sätze, die in die Datenbank gespeichert werden, in Sets einfügen, wobei zwischen Owner- und Membersatzarten zu unterscheiden ist:

• Ownersatzart:
  BINILOAD erzeugt z.B. in einem CHAIN-Set für jeden gespeicherten Ownersatz eine leere Set-Occurrence;

• Membersatzart eines oder mehrerer Sets:
  Sie müssen mit der INSERT-Anweisung (siehe Abschnitt „Anweisungen für BINILOAD") festlegen, in welche Sets BINILOAD die Sätze einfügen soll.

  Dies gilt auch für Sets, in denen die Satzart als AUTOMATIC-Member definiert ist.

Set-Occurrence auswählen

Soll BINILOAD Membersätze in einen Set einfügen, so benötigt BINILOAD Informationen zum Auswählen der Set-Occurrence, in die die Membersätze einzufügen sind. Dies geschieht, indem BINILOAD den Ownersatz auswählt.
BINILOAD kann den Ownersatz über folgende Schlüsselwerte auswählen:

• Wert des CALC-Key (siehe Handbuch „Entwerfen und Definieren“, LOCATION MODE-Klausel)

• Wert des SEARCH-Key; auf Satzartebene definiert entweder als INDEX-SEARCH-Key oder als CALC-SEARCH-Key (siehe Handbuch „Entwerfen und Definieren“, SEARCH-KEY-Klausel)

• Wert des Database Key; diese Methode ist immer möglich, da der Wert des Database Key ein eindeutiges Kennzeichen innerhalb der Datenbank ist

Wenn der Ownersatz Member in einem SYSTEM-Set ist, kann BINILOAD ihn über folgende Schlüsselwerte auswählen:

• Wert des ASC-/DESC-Key; bei einem sortierten SYSTEM-Set

• Wert des SEARCH-Key; auf Set-Ebene als INDEX-SEARCH-Key oder als CALC-SEARCH-Key definiert (siehe Handbuch „Entwerfen und Definieren“, Direktzugriff).

Den Schlüssel des Ownersatzes, über den die Set-Occurrence auszuwählen ist, können Sie BINILOAD auf zwei Arten mitteilen:

• Sie geben die Position des Schlüssels in den Sätzen der Eingabedatei an. In diesem Fall kann der Wert des Schlüssels von Satz zu Satz variieren. Demzufolge hängt BINILOAD die Sätze mit verschiedenen Schlüsselwerten in verschiedene Set-Occurrences ein.

• Sie geben den Schlüssel als Literal in der OWNER-Anweisung von BINILOAD an. In diesem Fall gilt der Schlüsselwert für alle zu speichernden Sätze. BINILOAD hängt also alle Sätze der Eingabedatei in eine Set-Occurrence ein.

Folgende Punkte müssen Sie beim Auswählen einer Set-Occurrence berücksichtigen:

• Duplikate
  Wählen Sie die Set-Occurrence aus durch Angabe des Schlüsselwertes (CALC-Key, ASC-/DESC-Key, SEARCH-Key) der Ownersatzart und existieren mehrere Sätze mit diesem Schlüsselwert (DUPLICATES ARE ALLOWED), dann wählt BINILOAD aus den Ownersätzen mit gleichem Schlüsselwert einen aus, ohne dass der Anwender vorhersehen kann, welcher dies ist.

• MANUAL-Member
  Sollen die Sätze der Eingabedatei in einen Set eingefügt werden, in dem ihre Satzart als MANUAL-Member definiert ist, so müssen Sie das Einhängen bzw. das Nichteinhängen angeben mit Hilfe der INSERT-Anweisung und durch Kennzeichnen der Eingabesätze bei wahlweisem Einhängen in einem BINILOAD-Lauf.

• Membersatzfolge
  Ist der Set, in den BINILOAD die zu speichernden Sätze als Membersätze einhängen soll, mit ORDER IS FIRST/LAST/NEXT/PRIOR oder IMMATERIAL definiert, dann können Sie mit der SET ORDER-Anweisung von BINILOAD angeben, wie BINILOAD die Sätze in die Set-Occurrences einhängen soll:

  • aufsteigend sortiert, nach dem Inhalt eines Feldes der Eingabesätze

  • in der Reihenfolge, in der sie in der Eingabedatei vorliegen

  In den anderen Fällen gilt die Reihenfolge, die in der ORDER-Klausel der Set-Beschreibung definiert wurde.

• Set-Occurrence nicht leer
  Sollen die zu speichernden Sätze als Membersätze in eine Set-Occurrence eingehängt werden, in der bereits Membersätze eingetragen sind, muss die Struktur der vorhandenen Set-Occurrence berücksichtigt werden.

  Diese Struktur wird bestimmt durch folgende Klauseln:

  • MODE-Klausel (SSL) mit POINTER-ARRAY, LIST, CHAIN

  • ORDER-Klausel (DDL) mit FIRST, LAST, NEXT, PRIOR, IMMATERIAL, SORTED (nur möglich bei CHAIN), SORTED INDEXED.

  DDL und SSL siehe Handbuch „Entwerfen und Definieren“.

  
  Folgendes müssen Sie dabei beachten:

  • Bei MODE IS CHAIN mit SORTED, SORTED INDEXED kann eine ungünstige Verkettungsstruktur entstehen.

  • Bei MODE IS LIST kann BINILOAD keine zusätzlichen Sätze in eine bereits vorhandene Set-Occurrence einfügen. Dies gilt auch für verteilbare Listen.

  • Bei MODE IS LIST benötigt BINILOAD für Stufe 0 jeder Set-Occurrence mindestens eine Seite.

In die Datenbank speichern

BINILOAD ist dafür gedacht, größere Mengen von Sätzen in die Datenbank zu speichern. Da BINILOAD keine teilweise gefüllten Seiten verwendet, kann mehr Speicherplatz verbraucht werden, als es beim Laden mit einem Anwenderprogramm der Fall wäre.

Es kann vorkommen, dass Eingabedaten, BINILOAD-Anweisungen und Angaben bei Schema-DDL und SSL unvereinbar sind. Daher bietet BINILOAD die Möglichkeit, die Daten der Eingabedatei zu prüfen bevor sie endgültig gespeichert werden.

Durch die Angabe EXECUTION WITH CHECK wird diese erste Phase beim Einspeichern mit BINILOAD, die Tabellenaufbauphase, einmal durchlaufen, ohne Änderungen in der Datenbank vorzunehmen. Dabei werden auftretende Fehler erkannt und entsprechende Meldungen ausgegeben.

Sind keine Fehler aufgetreten, so setzt BINILOAD wieder am Anfang des Laufs auf und die Eingabedaten werden in die Datenbank gespeichert.

Durch die Angabe EXECUTION WITHOUT CHECK wird sofort in die Datenbank geschrieben. Tritt ein Fehler auf, wird der BINILOAD-Lauf abgebrochen, Fehlermeldungen werden ausgegeben und die Datenbank ist inkonsistent.

• Abhängigkeiten zwischen Schema-DDL und BINILOAD-Anweisungen:

  • DUPLICATES ARE NOT ALLOWED und Duplikate vorhanden

    Wenn trotz Angabe von DUPLICATES ARE NOT ALLOWED
    Sätze in der Eingabedatei enthalten sind, die den gleichen Schlüsselwert haben, dann erhalten Sie die Meldung;

    DUPLICATE KEYS OR DBKEYS FOUND / REC REF‘S OR RSQ‘S OUT OF RANGE
SEE PRINTER OUTPUT

    Zusätzlich werden im BINILOAD-Ablaufprotokoll maximal die ersten 60 Bytes des Schlüssels in Zeichendarstellung und maximal die ersten 30 Bytes des Schlüssels in sedezimaler Darstellung ausgegeben. Die Meldung wird für jeden mehrfach festgestellten Schlüsselwert wiederholt. BINILOAD bricht nach Prüfung aller Eingabesätze mit der Meldung ab:

    ABNORMAL END BINILOAD

    BINILOAD kann nur Duplikate innerhalb der Eingabedatei feststellen. Duplikate zwischen Eingabesätzen und Datenbanksätzen werden nicht erkannt.

  • WITHIN-Klausel und RECORD AREA-Anweisung von BINILOAD

    Wenn in der WITHIN-Klausel der DDL mehr als ein Realm definiert wurde, dann müssen Sie den Realm, in den die Sätze zu speichern sind, in der RECORD AREA-Anweisung von BINILOAD angeben.

• Abhängigkeiten zwischen SSL- und BINILOAD-Anweisungen:

  • DATABASE-KEY-TRANSLATION-TABLE-Klausel

    Diese Klausel legt die Größe und Lage der DBTT für eine Satzart fest und bestimmt damit die Anzahl der Sätze, die höchstens in der Datenbank gespeichert werden können. Die Eingabedatei darf daher nicht mehr Sätze enthalten, als freie Einträge in der DBTT der betreffenden Satzart vorhanden sind.

  • PLACEMENT OPTIMIZATION-Klausel

    Bei Verwendung dieser Klausel werden die Membersätze zu diesem Set, entsprechend dem Sortierkriterium, dicht in aufeinander folgende Seiten gepackt; der Member wird nicht in die Seite des Owner gespeichert.

  • SSL-Angaben mit ATTACHED

    MODE IS POINTER-ARRAY ATTACHED

    MODE IS LIST ATTACHED

    INDEX NAME IS indexname PLACING IS ATTACHED

    Die Angabe von ATTACHED in der SSL ist unwirksam.BINILOAD speichert Adresslisten, Listen und Indizes aller Stufen in leere Datenbankseiten; diese Informationselemente werden immer DETACHED innerhalb des Realm des Owner gespeichert.

  • SSL-Angaben mit DETACHED

    Die Angabe DETACHED WITHIN realmname in der SSL bewirkt, dass die Adresstabellen und Indizes in dem angegebenen Realm gespeichert werden. Einzige Ausnahme bilden die verteilbaren Listen. Hier wird der Tabellenteil (Stufen >0) und ein möglicher indirekter Hashbereich in realmname gespeichert.

  • POPULATION-Klausel im Set-Eintrag der SSL und FILLING-Anweisung von BINILOAD

    In der FILLING-Anweisung kann der Füllgrad für Tabellenseiten angegeben werden. Auf diese Weise ist es möglich, ohne eine unmittelbare Erweiterung und Reorganisation für diese Informationselemente zusätzliche Membersätze durch den Database Handler zu laden. Der für diese Tabellenseiten zu reservierende Speicherplatz wird ausschließlich durch den Füllgrad bestimmt und nicht durch die Set-POPULATION-Klausel in der SSL.

Schema-DDL und SSL siehe Handbuch „Entwerfen und Definieren“.