× 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.



CR's /quoting/ and other (emphasis) is "exhausting"

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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.