Re: Weird Printer Issue

[CRPence <CRPbottle@xxxxxxxxx>]

  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.