Anmelden

View Full Version : OVRDBF-Problem



Seiten : 1 [2]

andreaspr@aon.at
10-07-13, 20:49
@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
10-07-13, 23:45
Und wenn du den physischen Dateien selbst den passenden Zugriffspfad gibst?

B.Hauser
11-07-13, 06:25
Wenn es dein OS Release zulässt, würde ich es so machen.


Release V5R1M0 sollte inzwischen fast jeder haben ;)

Birgitta

andreaspr@aon.at
11-07-13, 07:50
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
11-07-13, 07:57
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
11-07-13, 10:43
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
11-07-13, 10:58
Mach doch für die HUGOP auch ein CRTDUPOBJ.
Geht doch schneller


Gruß
Ronald