Re: Duplicate Queues

[CRPence <CRPbottle@xxxxxxxxx>]

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