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