OVRDBF-Problem

[KaFi]

Hallo,

ich habe ein kleines Problem mit dem Befehl OVRDBF.

Folgendes:

In einem RPGLE-Programm wird über eine logische Datei (nennen wir sie HUGOL1) auf eine physische Datei (HUGOP) zugegriffen.

Nun existieren auch noch die physischen Dateien HUGO1301, HUGO1302, ..., HUGO1307.
Diese Dateien sind von der Struktur her alle gleich.

Das RPGLE-Programm wird mittels eines CLs mit Parameter (z.B. '1306') aufgerufen.
Nun möchte ich mittels eines OVRDBF-Befehls die jeweils durch den Parameter angegebene physische Datei ansprechen.
Z.B.:

CHGVAR     VAR(&FILE01) VALUE('HUGO' *CAT &JJMM)
OVRDBF     FILE(HUGOP) TOFILE(TESTLIB/&FILE01)

Jetzt, so der Gedanke, soll im RPGLE-Programm (dort steht HUGOL1) nicht auf HUGOP sondern auf HUGO1306 zugegriffen werden. Das hat leider bisher nicht funktioniert.

Ich hoffe, dass ich den Sachverhalt verständlich beschrieben habe.

Kann mir bei diesem Problem jemand helfen ?

Vielen Dank.

MfG
Karlo

[Pikachu]

Eine logische Datei kann nicht per OVRDBF vorübergehend an eine andere physische Datei gehängt werden. Du brauchst also entweder den passenden Zugriffspfad in den einzelnen physischen Dateien selbst, oder je physischer Datei eine eigene logische Datei mit Zugriffspfad. Und dann muß auf die im RPG-Programm verwendete Datei überschrieben werden.

[andreaspr@aon.at]

Hallo Karlo,

das funktioniert so leider nicht.
Eine Logische hat eine eindeutige Verbindung zu seiner Physischen und kann nicht mittels OVRDBF geändert werden.

So wie du es machst, kannst du im RPG auf die Physische HUGOP zugreifen welche auf das zuvor mit OVRDBF angegebene HUGO1301 (oder was auch immer) verlinkt ist.

Wenn ich mich nicht irre kannst du das gleiche Spiel auch mit Logischen machen.
Also ein OVRDBF auf eine bestimmte Logische die auf dein HUGO13.. verweist.
Du musst dafür jedoch für jedes HUGO13.. das du verwenden willst, auch die entsprechende Logische haben.

Oder SQL

lg Andreas

[KaFi]

@Pikachu:

Die logische lässt sich nicht mit einer physischen Datei überschreiben - das führt zu einem Programmfehler. - Du hast die Antwort ja schon selber geändert. ;-)

@Andreas:

Ich habe leider nur die eine logische - da jeden Monat eine neue HUGOjjmm hinzukommt, hätte ich bald jede Menge logische Dateien.


Gibts da (ausser SQL) sonst keine Lösung ?

[andreaspr@aon.at]

Im JOBLOG sollte noch mehr stehen.
Eventuell ein Definitionsfehler in der F-Zeile.
Oder du verwendest eine Key-Liste die von der Logischen nicht unterstützt wird usw...

[KaFi]

Hallo Andreas,

die entsprechende Zeile im Programm sieht so aus:

FHUGOL1    if   e           k disk

Die Keyliste ist folgendermassen definiert:

C     keyHUGOL1     klist                           
C                   kfld                    feld01

Diese Anweisungen funktionieren einwandfrei.

[andreaspr@aon.at]

Zuerst ist interessant was noch im JOBLOG steht!
Da muss es noch andere Fehlermeldungen geben die auf das Problem hinweisen.

Eventuell stimmt die F-Definition nicht mit dem Aufbau der Logischen.
(z.B. sind Key-Felder in der LF vorhanden usw.)

Aber vorher bitte JOBLOG nochmal unter die Lupe nehmen.

[KaFi]

@Andreas:

Ich bin mir jetzt nicht sicher, ob ich verstanden habe was Du meinst.
Das Joblog sieht so aus:

4 > call testlib/crthugo4c parm('1307')                            
    Bibliothek TESTLIB der Bibliotheksliste hinzugefügt.            
    Inhalt der Teildatei EPPLAP in Datei EPPLAP in TESTLIB gelöscht.
    Bibliothek TESTLIB aus Bibliotheksliste entfernt.

EPPLAP ist die Ausgabedatei, welche im CL gecleart und im Programm wieder mit Daten gefüllt wird.

[Fuerchau]

Berücksichte den OVRSCOPE!
Der ist Default *ACTGRPDFN, versuche es mal mit *JOB.

Das CLP läuft immer in *DEFAULT, das ILERPG, wenn man nichts angibt, in QILE.

Der OVRDBF gilt bei *ACTGRPDFN eben nur für die aktive ACTGRP.

Alternativ gib im ILERPG an:

H DFTACTGRP(*NO) ACTGRP(*CALLER)

Ansonsten kann man alles Überschreiben, also PF mit LF und umgekehrt.
Solange Keys und Aktualitätsid's passen gibts kein Problem.

[B.Hauser]

Und warum machst Du das Überschreibungstrara überhaupt?
Warum verwendest Du nicht das Schlüssel-Wort EXTFILE mit Variable in den F-Bestimmungen, füllst die Variable mit Datei-Namen und öffnest anschließend Deine Datei user controlled?

FHUGOL1    if   e           k disk     ExtFile(MyHugo) UsrCtl

D MyHugo      S                     10A
 /Free
    MyHugo = 'ABC'
    Open HugoL1;

oder übergibst den Datei-Namen als Parameter und verwendest die Parameter-Variable mit ExtFile, dann musst Du die Datei noch nicht einmal user controlled öffnen.

... und es klappt immer mit der Aktivierungsgruppe.

... und übrigens für den Zugriff auf eine Teildatei gibt es das Schlüssel-Wort EXTMBR(MyMember)

Birgitta

[andreaspr@aon.at]

@Andreas:

Ich bin mir jetzt nicht sicher, ob ich verstanden habe was Du meinst.
Das Joblog sieht so aus:

4 > call testlib/crthugo4c parm('1307')                            
    Bibliothek TESTLIB der Bibliotheksliste hinzugefügt.            
    Inhalt der Teildatei EPPLAP in Datei EPPLAP in TESTLIB gelöscht.
    Bibliothek TESTLIB aus Bibliotheksliste entfernt.

EPPLAP ist die Ausgabedatei, welche im CL gecleart und im Programm wieder mit Daten gefüllt wird.

Du hast doch ein paar Beiträge zuvor eine Rxxxxx Fehler-ID gepostet. Diesen Post dürftest du nun geändert haben.
Ich schätze nicht, dass CRTHUGO4C das Programm ist wo du mittels OVRDBF auf das richtige File zugreifen willst?!?

... Egal ... Ich finde die Lösung von Birgitta sehr gut!
Einfach und schnell.
Wenn es dein OS Release zulässt, würde ich es so machen.

lg Andreas

[Pikachu]

Und wenn du den physischen Dateien selbst den passenden Zugriffspfad gibst?