OVRPRTF-Befehl wird nicht richtig verarbeitet

[herbertfidler]

Ich erlebe dieses Forum immer als sehr kompetent, es gibt , wenn ich darin lese, immer brauchbare Antworten.

Nach Stunden des Herumprobierens melde ich mich daher hier. Sieht zunächst höchst simpel aus.

In meinem neuen Pgm wird OVRPRTF-Befehl nicht richtig verarbeitet.
Folgende Anweisung:
CHGVAR VAR(&DEV) VALUE('PRT01')
OVRPRTF FILE(QSYSPRT) DEV(&DEV) CPI(15) OVRFLW(62) +
CTLCHAR(*FCFC) OUTQ(*DEV) USRDTA(RECHNUNG)

PRT01 ist ein verfügbarer Drucker.
Tatsächlich wird auf QPRINT umgeleitet, USRDDTA ist AUFTRAG.
Ich muss dazusagen, dass ich in diesem Pgm eine in eine DB-Datei kopierte Spool-Datei verarbeiten will.
Das aufrufende Pgm verarbeitet auch bereits einen OVRPRTF-Befehl. vielleicht gibt es da "Überschneidungen"

Besten Dank im Voraus für Unterstützung

[mk]

Hi,

vielleicht mal prüfen ob noch bestehende OVRPRTF gültig sind.
DSPJOB und
15. Dateiüberschreibungen anzeigen, falls aktiv

evtl. fehlt in den vorhergenden Jobs der DLTOVR


Ist es richtig das für den override der Parameter DEV verwendet wird.
Normalerweise wird der Parameter OUTQ verwendet.

Gruß
Michael

[B.Hauser]

Der Default für den Override Scope ist Aktivierungsgruppe. Kann es sein, dass mehrere Aktivierungsgruppen verwendet werden?

Am besten ist es innerhalb von Programmen den Override Scope mit *CALLVL zu belegen, dann gilt der Override für alle im Call-Stack nachgelagerten Programme und Prozeduren.

Birgitta

[cbe]

SECURE(*YES)
wäre auch eine gute Idee, dann schützt man sich vor der Auswirkung anderer ggf. bestehender OVRs aus vorigen Programmen.


Gruß, Christian

[Fuerchau]

Wenn das aufgerufene Programm einen eigenen OVRPRTF ausführt, so kann man diesen nicht ausschalten.
Übergeordnete OVRPRTF können nur Einstellungen zusätzlich überschreiben, die von untergeordneten OVRPRTF nicht selber belegt werden.
Zur Laufzeit des Programmes kann man per DSPJOB sich die Wirkung und Ebenen der OVR's ansehen.