× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.