Künstler Burgy Zapp

UDB DataLinks in RPG-Programmen verwenden

von Mike Cravitz

Die Unterstützung von UDB DataLinks ist eine Alternative zu den Large-Object-Spalten (LOBs) in SQL/400. Der Unterschied zwischen SQL/400 LOBs und DataLinks besteht darin, daß mit DataLinks nur Verweise auf Datenobjekte wie Bilder oder Videoclips in der Datenbank gespeichert werden und nicht die Objekte selbst, wie bei SQL-LOBs. Zur Klärung des Begriffs sei hier darauf hingewiesen, daß DataLinks (mit dem Buchstaben “s”) die offizielle Bezeichnung für die DataLink-Unterstützung ist. Wir verwenden also den Begriff “DataLinks” nicht als Plural von “DataLink”, sondern als Bezeichnung des UDB-Konstrukts. Anhand eines RPG-Beispielprogramms, das auf eine verknüpfte Datei zugreift, wollen wir Sie in die Verwendung von DataLinks einführen. Wir werden eine Tabelle mit einer DataLink-Spalte erstellen, die Tabelle mit Daten füllen und die Daten mit einem RPG-Programm lesen. Aber zunächst befassen wir uns kurz mit einigen Grundbegriffen.

DataLinks Grundlagen
DataLinks ist eine UDB-Architektur, die einen DataLinks File Manager (DLFM) beschreibt, der die Verbindungen zwischen den verknüpften Daten und den entsprechenden DataLink-Spalten pflegt. Ein weiterer Bestandteil der Architektur ist der DataLinks File Filter (DLFF), der den Zugriff auf die verknüpften Daten verwaltet. Eine Spalte des Typs DataLink enthält eigentlich nur einen Verweis auf eine Datei auf einem lokalen oder fernen System. Die aktuelle Implementation (V4R5) unterstützt nur das URL-Format (Universal Resource Locator) zur Definition der Verweise. Im Gegensatz zu DataLink-Spalten werden in LOB-Spalten die eigentlichen Inhalte selbst gespeichert. Die Abbildungen 1a und 1b zeigen diesen grundlegenden Unterschied. Normalerweise bezieht sich eine DataLink-Spalte auf eine Byte-Stream-Datei. Auf der AS/400 befinden sich solche Dateien gewöhnlich im Integrierten Dateisystem (IFS), aber eine Datei kann sich auf jedem Comutersystem 0befinden, auf dem ein DLFM/DLFF installiert ist. Derzeit wird DataLinks auf den Plattformen AIX, HP-UX, Linux, NUMA-Q, OS/2, OS/400, Solaris und Windows 95/98/NT/2000 unterstützt. OS/390-Unterstützung soll in nächster Zeit verfügbar werden, so daß jede Plattform, auf der DB2 UDB eingesetzt werden kann, auch DataLinks unterstützt.

Eine Beispiel-Tabelle

Abbildung 2a zeigt ein Beispiel für eine Personal-Tabelle mit einer DataLink-Spalte, und Abbildung 2b zeigt die Create Table-Anweisung zum Definieren der Tabelle. Die Tabelle enthält eine Spalte namens Notes vom Typ DataLink. In diesem Fall ist jeder Zeile in der Personal-Tabelle eine IFS-Datei auf der lokalen AS/400 zugeordnet (die den Systemnamen RISC trägt). Bevor die Tabelle mit Daten gefüllt werden kann, müssen 4 Bedingungen erfüllt sein:

• Die Tabelle muß journalisiert werden (siehe Handbuch Backup and Recovery (SC41-5304) für weitere Informationen über Journalisierung).
• Das Präfix muß registriert werden. Zum Registrieren des Präfix für die verknüpften Dateien in unserem Beispiel wurde der folgende AS/400-Befehl verwendet: AddPfxDLFM Prefix( ‘/myDataLinks’ )
• Die Datenbank und die Collections (bibliotheken) mit verknüpften Tabellen müssen registriert werden. Um verknüpfte Spalten in der in Abbildung 2a verwendeten Collection DLLIB zu ermöglichen, wurde folgender Befehl eingegeben: AddHDBDLFM Hostlib( DLLIB ) HostDb( RISC )
• Die Dateien, die verknüpft werden sollen, müssen bereits existieren. Diese Situation ist entstanden, weil wir bei der Definition der verknüpften Spalte (Abbildung 2b) die Klausel File Link Control angegeben haben. Hätten wir dies nicht getan, so könnten auch Zeilen in die Tabelle eingefügt werden, bei denen die verknüpfte Datei nicht existiert.

Abbildung 3 zeigt die INSERT-Anweisungen, die wir zum Füllen der Tabelle Employee verwendet haben.

Zeigen Sie Ihre Eintrittskarte

Benutzer, die keine Berechtigung für den Zugriff auf die verknüpften Dateien haben, können nur mit Hilfe eines sogenannten Zugriffs-Tokens auf diese Dateien zugreifen. Dieses Token ist nicht Bestandteil des Dateinamens, muß aber zusammen mit dem Dateinamen angegeben werden, wenn versucht werden soll, die verknüpfte Datei zu lesen. Dieselben Benutzer wären nicht in der Lage, die Datei zurückzuschreiben, weil wir beim Erstellen der Tabelle (Abbildung 2b) die Klausel Write Permission Blocked angegeben haben. Die Informationen über Zugriffsrechte für verknüpfte Dateien in der vorhandenen Fachliteratur sind verwirrend bis irreführend. Tatsache ist, daß eine verknüpfte Datei von jedem Benutzer verwendet werden kann, der ausreichende Berechtigung dafür besitzt. Ein Benutzer mit der entsprechenden Berechtigung kann eine verknüpfte Datei lesen oder schreiben, unabhängig davon, was beim Definieren der DataLink-Spalte angegeben wird. Abbildung 4 zeigt die Ergebnistabelle für die folgende SQL-Anweisung: Select DLURL( Notes ) From Employee Die skalare Funktion DLURL gibt den URL-Teil einer DataLink-Spalte zurück. Der Token-Teil jeder Zeile ist in der Abbildung rot dargestellt. Obwohl dieses Token eigentlich nicht Bestandteil des URLs der verknüpften Datei ist, können Sie mit ihm auf die verknüpfte Datei zugreifen, auch wenn Sie eigentlich keine Zugriffsberechtigung haben. Sogar ein Benutzer mit der Berechtigung *EXCLUDE kann den Inhalt der Datei anzeigen, wenn er Zugriff auf ein gültiges Token hat. Wenn wir bei unserem Beispiel aus Abbildung 4 bleiben, könnte ein Benutzer den Inhalt der Textdatei für die Mitarbeiterin Barb Gibbens ansehen, wenn er den in Abbildung 5 dargestellten Befehl eingibt. Auch hier ist das Token rot dargestellt. Dieses Beispiel zeigt, wie einfach ein Benutzer auf verknüpfte Daten zugreifen kann, wenn er ausreichende Berechtigung für die Tabelle mit der DataLink-Spalte hat. Aus diesem Grund stellt es normalerweise eine Sicherheitslücke dar, wenn Benutzer auf diesem Weg auf eine Tabelle wie die in Abbildung 2b definierte zugreifen können. Besser wäre es, auf AS/400-Standardtechniken zurückzugreifen und Benutzern nur ein oder mehrere Programme zur Verfügung zu stellen, die die Berechtigung vom Objekteigner übernehmen. (Weitere Informationen über übernommene Berechtigung finden Sie im IBM-Handbuch OS/400 Security Reference (SC41-5302)). Programme mit übernommener Berechtigung erhalten ein gültiges Token, zeigen es aber dem Benutzer nicht an. Auf diese Weise kontrolliert das Programm den Zugriff auf verknüpfte Daten. Das Programm DSPEMP, das wir nachfolgend vorstellen, demonstriert, wie solch ein Zuugriffsprogramm gestaltet werden kann.

Kontrollierter Benutzerzugriff auf verknüpfte Dateien

Abbildung 6 zeigt den Startbildschirm des Programms DSPEMP. Wie Sie sehen, handelt es sich um eine einfache Subfile-Liste der Personalstammsätze in der Tabelle Employee. Durch Eingabe eines Zeichens in das Auswahlfeld können einer oder mehrere Datensätze zur Detailanzeige ausgewählt werden. Nach dem Drücken der Eingabetaste werden die Bemerkungen zu den ausgewählten Datensätzen in einer zweiten Subfile-Anzeige ausgegeben (Abbildung 7). Sehen wir uns einige technische Details dieses Programms noch etwas genauer an. Abbildung 8 enthält einen Auszug aus dem Quellcode des Programms DSPEMP. Als Erstes fällt auf, daß ein SQL-Cursor für den sequentiellen Zugriff auf die Tabelle Employee eingesetzt wird, weil für Tabellen mit einer oder mehreren DataLink-Spalten die Standard-I/O-Operationen nicht verwendbar sind. Der Cursor wird bei Markierung B in Abbildung 8 deklariert. Die Select-Anweisung für den Cursor enthält alle Zeilen und Spalten der Tabelle Employee. Der Cursor wird bei Markierung H geöffnet. Die Zeilen aus der Ergebnistabelle des Cursors werden bei Markierung G sequentiell gelesen. Bei Markierung I wird der Cursor geschlossen. Dieser Cursor wird verwendet, um die in Abbildung 6 gezeigte Subfile-Anzeige zu füllen. Wenn der Benutzer einen oder mehrere Subfile-Sätze auswählt und die Eingabetaste drückt, muß das Programm die verknüpften Daten aus den entsprechenden Textdateien abrufen. Bevor es das tun kann, muß es den Pfadnamen für die Datei mit dem korrekt in den Namen eingefügten Token ermitteln. Dies geschieht mit der Select Into-Anweisung bei Markierung F. Vor dieser Anweisung liest das Programm mit einer READC-Anweisung einen markierten Satz aus der Subdatei (nicht dargestellt). Die Where-Klausel der Select Into-Anweisung stellt sicher, daß wir die Zeile auswählen, die der Benutzer in Abbildung 6 ausgewählt hat. Nach der erfolgreichen Ausführung der Select Into-Anweisung enthält die Programmvariable Path den Pfadnamen mit dem eingefügten Token. Jetzt kann das Programm die Datei mit der passenden Methode öffnen. Wir haben zur Ein-/Ausgabe der verknüpften Dateien die IFS-APIs open(), read() und close() verwendet, die im IBM-Handbuch OS/400 UNIX-Type APIs V4R4 (SC41-5875-03) beschrieben sind. Die Prototypen für diese drei APIs sind bei Markierung A beschrieben. Die Steueranweisung H BndDir(‚QC2LE‘) in der ersten Zeile des Programms ermöglicht dem Programm zur Bindezeit den Zugriff auf diese APIs. Bei Markierung D in Abbildung 8 wird die verknüpfte Datei geöffnet. Diese Open-Funktion gibt einen Descriptor zurück, der wie ein Datei-Handle bei allen weiteren I/O-Operationen angegeben werden muß.

Beachten Sie, daß das Programm den Pfadnamen (mit dem Token) so weitergibt, wie es ihn von der bei Markierung F dargestellten Select-Into-Anweisung erhalten hat. Das Programm übergibt außerdem ein Flag an die Funktion, das aussagt, daß die angesprochene Datei nur zum Lesen (read-only) geöffnet wird. Das Lesen der verknüpften Datei geschieht bei Markierung C. Der erste Parameter ist der von der Open-Anweisung zurückgegebene Descriptor. Der zweite Parameter ist ein Pointer auf einen Bereich, der die gelesenen Daten aufnimmt. In unserem Fall sollen die gelesenen Daten in einem Feld mit dem Namen CurrChar gespeichert werden. Der letzte Parameter (1) signalisiert der Read-Funktion, daß nur ein einzelnes Zeichen abgerufen werden soll. Die API-Funktion Read() kann auch mehr als ein Zeichen zurückgeben, aber da es sich in unserem Beispiel um eine Byte-Stream-Datei handelt, hat das Programm keine Möglichkeit festzustellen, wo eine Textzeile endet. Deshalb liest es ein Zeichen nach dem anderen in einen Pufferbereich (nicht dargestellt), bis es ein Carriage-Return-Zeichen (X‘0D‘) und ein Line-Feed-Zeichen (X‘25‘) findet. Die Read-Funktion liefert die Anzahl der gelesenen Zeichen zurück (in unserem Beispiel wird nur 1 Zeichen gelesen) Das Programm überträgt die Anzahl der gelesenen Zeichen in ein RPG-Feld namens NumCharsRead. Die Read-Funktion gibt Null (0) zurück, wenn versucht wird, über das Ende der Datei hinaus zu lesen und -1, wenn ein Fehler auftritt. Wir beschreiben hier nicht vollständig, wie das Programm die gelesenen Zeichen in Textzeilen aufbereitet oder wie API-Fehler abgefangen werden. Der Select/EndSl-Block nach der ReadFile-Anweisung bei Markierung C behandelt Fehler-Situationen (NumCharsRead < *Zero), Datei-Ende (NumCharsRead = *Zero) und erfolgreiches Lesen eines Zeichens (NumCharsRead > *Zero). Bei Markierung E wird die verknüpfte Datei wieder geschlossen. Auch bei dieser Operation muß der Descriptor übergeben werden.

Jetzt können Sie DataLinks in RPG-Programmen verwenden

Das Programm DSPEMP dient als Modell für Programme, die auf Tabellen mit einer oder mehreren DataLink-Spalten zugreifen. Laden Sie sich den Programmcode herunter, und experimentieren Sie mit dem Programm. Einer der größten Vorteile von DataLinks ist der kontrollierte Zugriff auf die verknüpften Dateien. Das Programm DSPEMP zeigt Ihnen, wie dieser Zugriff mit einem RPG-Programm realisiert wird.

	Abbildung 6: Startbildschirm von DSPEMP

	Abbildung 7: Textausgabe von DSPEMP

A

B

C

D

E

F

G

H

I

H BndDir( _QC2LE )

           .

           .

           .

           .

           .

           .

     D SqlSttOk        C                   Const( '00000' )

     D SqlSttNoRow     C                   Const( '02000' )

     D SqlSttTooFewHostVars...

     D                 C                   Const( '01503' )

     D Path            S            500A

     D FileDescriptor  S             10I 0

           .

           .

           .

           .

           .

           .

    

     C                   Select

     C                   When      NumCharsRead < *Zero

     C                   Eval      ErrFound  = *On

     C                   Eval      EndOfLine = *On

     C                   Eval      ErrMsg    = pErrTxt( *Omit )

     C     ErrMsg        Dsply

     C                   When      NumCharsRead = *Zero

     C                   Eval      EndOfLine    = *On

     C                   Eval      EofNotesFile = *On

     C                   Eval      Pos          = Pos - 1

     C                   When      NumCharsRead > *Zero

     C                   If        CurrChar  = Lf And PrevChar = Cr

     C                   Eval      EndOfLine = *On

     C                   Eval      Pos       = Pos - 1

     C                   Else

     C                   Eval      Pos                       = Pos + 1

     C                   Eval      %Subst( TxtLine: Pos: 1 ) = CurrChar

     C                   Eval      PrevChar                  = CurrChar

     C                   EndIf

     C                   EndSl

           .

           .

           .

           .

           .

           .

           .

           .

           .

      *= *= *= * = * = * = *= * = * = * = * = *= * = * = * = *= * =

      * GetPath - Obtains the path (including) the token for the

      *           notes file corresponding to the current employee

     C     GetPath       BegSr

     C                   Eval      Path = *Blank

           .

           .

           .

           .

           .

           .

      *= *= *= * = * = * = *= * = * = * = * = *= * = * = * = *= * =

     C     OpenCursor    BegSr

           .

           .

           .

      *= *= *= * = * = * = *= * = * = * = * = *= * = * = * = *= * =

      * CloseCursor - Close the Cursor

     C     CloseCursor   BegSr

           .

           .

           .

Ähnliche Artikel:

SQL: dynamisches Select ohne Cursor

In einem System iNetwork Forum tauchte die Frage auf, ob in SQL eine dynamische Select-Anweisung ausgeführt werden kann, ohne zuvor einen Cursor zu definieren. Birgitta Hauser hatte dazu eine Lösung…

Highlights von IBM i 7.3

Als wichtigste Themenbereiche dieses neuen Releases bezeichnet Steve Will, IBM Chief Architect: 1. Vereinfachung der Informations-Gewinnung, 2. intelligente Sicherheit und 3. Nutzen durch Integration. Hier kurz vor dem Drucktermin ein…

CRTDUPOBJ und logische Dateien

Beim Erstellen von Testbibliotheken verwendet man häufi g den Befehl CRTDUPOBJ in einem CL-Programm, um physische und logische Dateien in einem Testbereich zu erstellen. Da der Befehl CRTDUPOBJ für die…