Nachdem im vorherigen Artikel  die wesentlichen Schritte beschrieben wurden, die zur Konvertierung von DDS-beschriebenen Dateien in die SQL-definierten Äquivalente notwendig sind, werden in den nächsten Artikeln diese Schritte anhand eines Beispiels detaillierter erklärt. In diesem zweiten Artikel der Reihe werden zunächst die DDS beschriebenen Beispiel-Dateien sowie ein kleines RPG-Programm, das auf die DDS-Dateien zugreift, vorgestellt.

Um das Beispiel einfach und überschaubar zu halten, umfasst die Beispielanwendung lediglich eine einzige physische Datei mit mehreren logischen Dateien, sowie ein einfaches RPG-Programm.

Quelle: Hauser

Abbildung 1: DDS-Beschreibung für die physische Datei SALESP

Die Abbildung 1 zeigt die DDS-Quelle für die physische Datei SALESP. In dieser Datei sind lediglich zwei alphanumerische Felder (SLCUST und SLITEM) sowie zwei numerische Spalten (SLDATE und SMAMNT) definiert. Zusätzlich ist für die physische Datei ein Schlüssel mit den Feldern SLCUST, SLITM und SLDATE) definiert.

Zu der physischen Datei wurden insgesamt die drei logischen Dateien definiert, die jeweils alle Felder der physischen Datei beinhalten, sich jedoch durch unterschiedliche Schlüssel-Felder unterscheiden:

  • SALESL01 mit den Schlüssel-Feldern SLDATE, SLCUST und SLITEM
  • SALESL02 mit den Schlüssel-Feldern SLCUST, SLDATE und SLITEM
  • SALESL03 mit den Schlüssel-Feldern SLITEM, SLCUST und SLDATE.

Die DDS-Beschreibung der logischen Dateien wird in der Abbildung 2 gezeigt.

Über die Catalog-View SYSTABLES in der Bibliothek QSYS2 können alle physischen und logischen Dateien, Quellen-Dateien, Tabellen, Views, Materialzed-Query-Tables (MQT) und Alises angezeigt werden.

Quelle: Hauser

Abbildung 2: Logische Dateien zu der physischen Datei SALESP

Über die folgende Abfrage (siehe Abbildung 3) wird die physische Datei SALESP, sowie die logische Dateien SALESL01, SALESL02 und SALESL03 angezeigt. Aus der Spalte TABLE_TYPE kann entnommen werden, dass es sich bei der Datei SALESP um eine DDS-beschriebene physische Datei handelt (TABLE_TYPE = P).

TABLE_TYPE = L besagt, dass es sich bei den Dateien SALES01, SALES02 und SALES03 um DDS-beschriebene logische Dateien handelt.

Sowohl die physische Datei als auch die logische Datei SALESL02 werden in dem folgenden RPG-Programm verwendet. Die Datei SALESL02 ist als Input-Datei definiert und wird über Schlüssel positioniert und gelesen.

Es werden alle Umsätze (Feld Amount) für den Kunden 10002 und in dem Zeitraum zwischen dem 01.01.2009 und dem 31.12.2009 aufaddiert und das Ergebnis über DSPLY angezeigt.

Weiterhin wird ein neuer Satz in die physische Datei, die als Ausgabe-Datei definiert wurde, geschrieben.

Ein Programm für die weiteren Teile

Quelle: Hauser

Einträge der Beispiel-Dateien in Catalog-View SYSTABLES, Bild 3

Dieses kleine Programm wird in den folgenden Artikeln, jeweils vor und nach der Konvertierung der Dateien, in dem gleichen Job aufgerufen und ausgeführt.

Es erfolgt dabei weder eine Änderung des Quell-Codes noch eine erneute Kompilierung des Programms.

Vor dem wiederholten Aufruf muss man lediglich die Aktivierungsgruppe SALESP02, in der das Programm ausgeführt wird, mit RCLACTGRP (Aktivierungsgruppe zurückfordern) zurückgesetzt (siehe Code in Abbildung 4, unten) bekommen.

Damit wäre die Beschreibung der Beispielumgebung in den groben Zügen erfolgt. Interessant wird es dann auch im nächsten Artikel, denn dort werden wir über Reverse Engineering den Source Code für diese DDS-beschriebenen Dateien ermitteln.

 

Birgitta Hauser

Quelle: Hauser

Abbildung 4: RPG-Programm mit Zugriff auf die Beispieldateien