I'll check to see if there are any lingering OVRPRTFs, but I doubt
it. I checked one program (RPG II and OCL) that I know exhibited the
problem in the past; the // PRINTER statement is there and is
Jim Franz on Tuesday, March 13, 2012 7:16 PM wrote:
An override printer file (ovrprtf) in the job stack could do this.
Also, because the // printer statement is optional, is it possible
the printer statement is not functional if the printer output file
in pgm not same as ocl printer name ?
Jerry C. Adams on Tuesday, March 13, 2012 3:16 PM wrote:
Also, meant to say that I did check the job log after the
incident today (when the invoice wanted to print at BB even
though it should have been directed to P7). There were no
messages in the job log, and it shows the // PRINTER OCL
statement explicitly referencing P7, but nothing later except the