Thanks, Chuck. That adds a bit more resolution. It substantiates my
claim that you don't need to set up a dummy device description to have a
target for Query/400 output that you aren't going to print. You can
direct it to outq's unattached to device descriptions.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, January 29, 2010 1:48 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Duplicate Queues
Query/400 was carried from the Query/36 of the S/36. The OV and the
Query features both started with "device", even though it was more
relevant to OV which determined capabilities of the device for how its
output would be generated whereas Query did not. To have adopted a more
AS/400-like aspect, the Query/400 utility should have been modified to
refer a printer file and\or an output queue instead of leaving just the
DEV() for which it even existence checks. The former was not an option,
and the latter was not easily resolved without adding complications to
the navigation of screens in the defining output to *PRINTER [note: even
having OUTTYPE(*PRINTER), rather than the OUTPUT(*PRINT) of the rest of
the system]. The special value *PRINT was the simplest resolution; i.e.
a value that deferred attributes not specified in responses to inputs on
the panels\screens, to the printer file QPQUPRFIL or any override of
parameters on that file [but not to another file name, which was a lame
way to attempt preventing redirect to a file not having the required
external definitions].
So the claim that the Query/400 will just use "the OUTQ of your job"
is also inaccurate. Query/400 [outside of S/36EE] does what the OUTQ
and DEV resolution will effect from the specifications ofn the Open of
the printer file QPQUPRFIL, along with those print\spool attributes from
the job; possibly with value resolution side effects from system values,
user profile specifications, and workstation device settings. Change
the OUTQ() specification of the resolution from printer file QPQUPRFIL,
to something other than OUTQ(*JOB), and the claim may not hold,
depending on further resolution.
As to the help text in Query/400 and its *PRINT for the "Printer",
the text is more dumbed-down more than it is incorrect; i.e. the
spooling on the system is not easily described in a few simple
paragraphs, if even anyone wanted to read that much in help text, so the
text is purposely vague. The PRTDEV() parameter of RUNQRY does a better
job, suggesting that for the value of *PRINT, the "default printer, as
defined by QPQUPRFIL, is used to print the output when this query is
run."
http://archive.midrange.com/midrange-l/200910/msg00788.html
Regards, Chuck
Dan Kimmel wrote:
I haven't used Query/400 in a really, really long time. Probably close
to 10 years.
Makes me wonder why it was done this way. It seems to validate to a
device description list. Internally, it must be using the device
description to come up with an outq name that it uses to override its
own print file. Why couldn't they validate to an outq list? The
interface does allow SPOOL(*NO) which would require a device
description, but that could be handled conditionally.
If you say PRTDEV(*PRINT), it uses the OUTQ of your job (the help text
says something entirely misleading). I have DKIMMEL specified as the
job OUTQ and query puts the output there even though there is no
DKIMMEL device description on my system. So if you have your jobd set
up right, there's no need to have a dummy device description. You can
also do a CHGJOB OUTQ(SOMEOUTQ) and the output will go to SOMEOUTQ if
the query is set up with PRTDEV(*PRINT).
Rob wrote:
Have you ever used Query/400? So, unless they want to wrap every
query they use with a program they have to specify a device.
Screen is pretty basic:
Printer . . . . . . . . . *PRINT
<<SNIP>>
There is no way to specify output queue unless - You use wrapper
programs - You use a device associated with that output queue.
Dan Kimmel" wrote:
I don't see any reason for having a printer device description
you're never going to use. That is, a dummy printer device.
The query doesn't reference a printer, it references a print file.
The printer file names an outq. The outq is attached to the printer
device description by the print writer.
Goes like this:
Program names a print file. Print file may be overridden.
Print file names an outq. Outq is attached to a printer device
description by a print writer.
The only reason to have a reference to an outq in a printer device
description is autostart. QSTRUP goes through the list of printer
device descriptions looking for ones with autostart.
It does a STRPRTWTR for each of those using the defaults, which is
outq(*devd).
--
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
