OVRDBF-Problem

[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?

[B.Hauser]

Wenn es dein OS Release zulässt, würde ich es so machen.

Release V5R1M0 sollte inzwischen fast jeder haben

Birgitta

[andreaspr@aon.at]

Release V5R1M0 sollte inzwischen fast jeder haben

Birgitta

Hast natürlich recht! Habs mit dem Parameter *EXTDESC im Schlüsselwort EXTFILE verwechselt, den es erst ab 6.1 gibt

[Robi]

Wenn du Einflus auf die Datei nehmen kannst, erweitere die PF und nimm JJMM in die Datei und den Key mit auf.

Gruß
Robi

[KaFi]

Vielen Dank für eure Antworten.

@Andreas:
Diese Fehlermeldungen kamen dadurch, dass ich mit dem OVRDBF-Befehl die logische Datei mit der physischen "überschrieben" habe. Dies erschien mir dann aber auch zu abwegig, so dass ich diesen Post, 30 Sekunden nachdem ich ihn geschrieben habe, wieder geändert habe. Du warst zu schnell beim lesen. Sorry ;-)

@Birgitta:
Das ist wohl eine gute Lösung. Das dass in der Art möglich ist, wusste ich bisher auch nicht.

So, ich habe das Problem aber nun anders lösen müssen (leider keine Zeit mehr zum probieren). Und zwar so:

/**********************************************************************
/*  Dateien nach QTEMP kopieren                                        
/**********************************************************************
             RMVLIBLE   LIB(QTEMP)                                     
             ADDLIBLE   LIB(QTEMP) POSITION(*BEFORE &BIB)              
             CHGVAR     VAR(&FILE01) VALUE('HUGO' *CAT &JJMM)        
             CPYF       FROMFILE(&BIB/HUGOP) +                       
                          TOFILE(QTEMP/HUGOP) MBROPT(*NONE) +        
                          CRTFILE(*YES)                                
             CRTDUPOBJ  OBJ(HUGOL1) FROMLIB(&BIB) OBJTYPE(*FILE) +   
                          TOLIB(QTEMP)                                 
             CPYF       FROMFILE(&BIB/&FILE01) TOFILE(QTEMP/HUGOP) + 
                          MBROPT(*ADD) CRTFILE(*YES)
/**********************************************************************

Im CL stelle ich sicher, dass die Bibliothek QTEMP vor meiner Verarbeitungsbibliothek in der LIBL-List steht. Dann kopiere ich die Datei HUGOP, auf die auch die logische zeigt, ohne Daten nach QTEMP.
Dann kopiere ich mit CRTDUPOBJ die logische HUGOL1 nach QTEMP - diese zeigt jetzt auf QTEMP/HUGOP.
Dann kopiere ich noch meine eigentliche Datendatei HUGO1307 nach QTEMP/HUGOP.

Das hat jetzt aber nix mehr mit dem OVRDBF-Befehl zu tun, aber so funktioniert jetzt das CL und das Verarbeitungsprogramm.

MfG
Karlo

[malzusrex]

Mach doch für die HUGOP auch ein CRTDUPOBJ.
Geht doch schneller


Gruß
Ronald