Re: How come I can't use a single OVRPRTF?

On 10-Jan-2014 13:47 -0800, Branston DiBrell wrote:

I'm having a problem getting OVRPRTF to work in the following
instance:
<<SNIP; the request is: OVRPRTF with the following parameters>>
FILE(QPQXPRTF) TOFILE(PRTLSTK) DEV(WRKPRT3) MULTIUP(1) DUPLEX(*YES)
OUTQ(WRKPRT3) COPIES(1) PAGERANGE(1 *END) HOLD(*YES) SAVE(*YES)
DRAWER(2) FORMTYPE('test form')

<<SNIP>> uses STRQMQRY to run the SQL statement.

What happens is, my output doesn't get put on hold and doesn't get
saved. Is does get printed on the WRKPRT3 printer (which is how the
PRTLSTK PRTF is defined). I tried adding OVRSCOPE(*JOB) to the
OVRPRTF command - that didn't work. I also tried running each command
interactively from the command line - that didn't work either.

What DID work is when I separated the OVRPRTF command into two
OVRPRTF commands:

ovrprtf FILE(QPQXPRTF) TOFILE(PRTLSTK)

ovrprtf FILE(PRTLSTK) DEV(WRKPRT3) MULTIUP(1) DUPLEX(*YES)
OUTQ(WRKPRT3) COPIES(1) PAGERANGE(1 *END) HOLD(*YES) SAVE(*YES)
DRAWER(2) FORMTYPE('test form')

Either use "OVRPRTF FILE(QPQXPRTF) TOFILE(*FILE) ..." to override just the parameters for the open of that printer file, or use the dual override technique if directing to an alternate printer file is desirable.

My Question is: How come I can't use a single OVRPRTF?

One override is possible, if using TOFILE(*FILE); or the equivalent effect, whereby the file _name_ is unchanged, irrespective the library-qualifier.

IIRC the inability to use one Override with Printer File request to _override to a separate printer file_ is a side-effect of /improper/ coding [or at least deemed /undesirable/ coding] by the QM Query feature, since its inception; and pointed out as effectively a defect during early testing, but the coding was never /corrected/ due to some design choices. I do not recall the details, but I believe the issue originates from the use of secured printer file parameters established for the open, as implementation of the OUTPUT(*PRINT) for a Start Query Management Query (STRQMQRY) request [or QM procedural PRINT REPORT request]. Secured parameters\attributes is not to be confused with a secured override, per OVRPRTF SECURE(*YES). FWiW: The fact that the product even allows an alternate printer file is somewhat atypical from what I recall; i.e. as I recall most products prevent specifying a different TOFILE() name entirely, by issuing a failure message when the condition is detected.

FWiW: If all of those specified parameters [shown] encompass the full scope of the intended values to be overridden [over what is established in\from the QPQXPRTF printer file], then the original OVRPRTF request [shown in the quoted text above] can suffice, by changing to use TOFILE(*FILE) and adding SPLFNAME(PRTLSTK); the latter parameter specification, if the eventual spool file name of PRTLSTK is important. Otherwise, just use the dual overrides, just as shown was able to circumvent the ignored override. Of course, always best to explicitly specify additionally, at least the Override Scope (OVRSCOPE), to avoid changed defaults from negatively impacting the CLP... due to failed assumptions, of what are the defaults.

FWiW: The documentation ignores discussing the flaw :-( merely by alluding to the ability to direct to a TOFILE() that has the printer file attributes established; i.e. the docs do not inform that including both the TOFILE() *and* the other overridden attributes does not function, nor inform of the alternative means to establish the desired SPLF attributes by using two overrides. I see in another past discussion that Charles Wilt discovered the same issue and the same resolution by utilizing two overrides, plus a reply that informed of the SPLFNAME() capability:
http://archive.midrange.com/midrange-l/200810/msg00869.html
http://archive.midrange.com/midrange-l/200810/msg00901.html

Other topics going way-back, showing the issue has effectively always existed; the 1st got by with effective TOFILE(*YES), the 2nd apparently was unresolved because even OVRSCOPE(*JOB) is fruitless:
http://archive.midrange.com/midrange-l/200205/msg00592.html
http://archive.midrange.com/midrange-l/200111/msg02688.html