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

On Jan 12, 2014, at 5:18 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.