That's a really good explanation - thanks!
-Branston DiBrell, Jr - b.dibrell@xxxxxxxxxxxxxxxxxx
Peerless Tires, IT Department, Denver CO - 720-274-0632
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Sunday, January 12, 2014 3:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
--
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.
midrange.com
