Anmelden

View Full Version : STRQMQRY mit OVRPRTF läuft auf Fehler



Seiten : [1] 2

ortwin
08-01-24, 15:46
Hallo Forum,

ich habe ein CL-Programm, dass via STRQMQRY eine Abfrage ausführt. Das Abfrageergebnis soll als PDF im IFS ausgegeben werden. Dazu ändere ich das Printerfile entsprechend mit einem OVRPRTF - so wie ich das an anderer Stelle auch tue.

Wenn ich es ausführe, bekomme ich einen Programmabbruch.

Hier das CL:
PGM
DCL VAR(&PARFIR) TYPE(*CHAR) LEN(3) VALUE('001')
DCL VAR(&PDFTIME) TYPE(*CHAR) LEN(20)
DCL VAR(&PDFSTMF) TYPE(*CHAR) LEN(255)
RTVSYSVAL SYSVAL(QDATETIME) RTNVAR(&PDFTIME)
CHGVAR VAR(&PDFSTMF) VALUE('/FIBUORDNER/RGLISTE' +
*CAT &PARFIR *CAT &PDFTIME *CAT '.PDF')
OVRPRTF FILE(QPQXPRTF) DEVTYPE(*AFPDS) PAGESIZE(48 +
120) ALIGN(*YES) TOSTMF(&PDFSTMF) WSCST(*PDF)
STRQMQRY QMQRY(RGSEPABALI) OUTPUT(*PRINT)
ENDPGM

Die Einträge im Jobprotokoll sind:
call rgsepatest
Datei ist vorhanden. (CPE3457)
Datei QPQXPRTF in QSYS nicht geöffnet. (CPF4208)
-> 6 -- Angegebene Datenstromdatei ist bereits vorhanden.
Ausdruck des Berichts fehlgeschlagen.

Da der Dateiname unter Nutzung eines Timestamps erzeugt wird, kann es eigentlich nicht vorkommen, dass die Datei vorhanden ist.

Ich habe Folgendes noch versucht:
- Festen Dateiname im OVRPRTF - gleiche Meldung, Datei ist mit WKRLNK nicht zu finden.
- Ausführung ohne OVRPRTF - funktioniert, dann SCS-Ausgabe (Standard)
- PDF-Angaben manuell im PRTF geändert - funktioniert

Hat jemand eine Idee, warum der OVRPRTF anscheinend zu dem Fehler führt?
System läuft unter V7R4.
Danke.

B.Hauser
08-01-24, 17:08
Auf welcher Ebene erfolgt denn der Override? OVRSCOPE *JOB oder Default *ACTGRP?
ggf. mal mit Override Scope *JOB versuchen.

ortwin
08-01-24, 19:28
Der Override erfolgte auf Ebene Default *ACTGRP. Änderung auf *JOB führt leider nachwievor zum Fehler, ebenso wie *CALLLVL.

Fuerchau
08-01-24, 19:34
Der einzige Hinweis bzgl. des Fehlers den ich finde ist die Ausgabe in QDLS. QDLS unterstützt nur 8.3-Namen.
Ist FIBUORDNER ggf. ein Link ins QDLS? Ältere Fibu-Programme haben damit gearbeitet.

ortwin
08-01-24, 20:28
Nein, das ist ein IFS-Ordner.

Edefauler
09-01-24, 08:24
Arbeitet ihr mit mehreren ASPs?

Fuerchau
09-01-24, 08:32
Dann schau dir mal genau den gebildeten Namen der IFS-Datei an.
Du verwendets unbesehen den Wert QDATETIME. Allerdings enthält dieser den Doppelpunkt als Uhrzeittrenner und das ist ein ungültiges Zeichen im IFS-Pfad.
Die interne Fehlerid wäre eigentlich "Invalid path- or filename".

ortwin
09-01-24, 09:40
Nein, wir arbeiten nur mit einer ASP.

ortwin
09-01-24, 09:49
QDATETIME und Doppelpunkt:
Das scheint dann automatisch "bereinigt" zu werden, jedenfalls nutze ich dieses noch an anderen Stellen genauso. Ich habe auch in der Dumpausgabe geschaut, der Wert für die Variable &PDFSTMF lautet dort z.B. /FIBUORDNER/RGLISTE00120240108181328513946.PDF
Ich bin jetzt gestern hergegangen und habe die Query-Ausgabe als normale Druckausgabe ausgegeben, anschließend mit CPYSPLF in eine Datei geschrieben und diese dann mit CPYF in ein Printerfile kopiert. Die entsprechenden OVRPRTF habe ich mit den gleichen Variablen vorgenommen - läuft tadellos, ist m. E. aber eigentlich unnötig. Den "Umweg" wollte ich eigentlich vermeiden, da das Programm aber kritisch ist, habe ich mir jetzt nur so zu helfen gewusst.

ortwin
09-01-24, 10:04
Nachtrag: Ich hatte das auch mit einem fixen Namen ohne Timestamp probiert, das schlug ebenfalls fehl.