I see from another message that the issue was resolved, as the side effect of a latent [left active] override, but FWiW...

The following is a nice way to review any OVRPRTF overrides that exist not only from the requests in the user code, but also for the one produced by the S/36e [to implement the // PRINTER OCL ¿or defaults or FORMS?]; I think the latter may not be generally visible until the PRINT procedure is activated?:

strdbg qspopen updprod(*yes) /* performed by *ALLOBJ user */
addbkp '/1'
/* call interactive printing request */
/* at the bkp at inst/1, F10=CmdLine */
wrkjob option(*filovr)
wrkjob option(*pgmstk) /* or (*actgrp) */
dspovr actgrp( _named_ ) /* for each */
/* f12=previous to return to bkp inst/1 */
/* Enter to continue processing */
/* repeat from "at the bkp" if hit again */
enddbg

The program QSPOPEN is the "spool\print component" _open_ which follows the QDMCOPEN common Data Management open which retrieved and applied all of the relevant overrides prior to invoking the device-specific [in this case, for a /printer file/ with /[device] file/ attribute of PRTF] open processor.

Regards, Chuck

On 15-Mar-2012 05:25 , Jerry C. Adams wrote:
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
correct.

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
normal stuff.




This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].