On 21-Dec-2011 15:15 , Monnier, Gary wrote:
Tracking down the Host Print outq can be interesting. First, it
determines outq from user's job description not the interactive job.
In the jobd the PRTDEV() and OUTQ() parameters come into play in
determining the outq. <<SNIP>>
Although the issue for the OP was apparently attributed to the
idiosyncrasy of a TELNET target 5250 session rerouting host print
request output to a prior [¿the first?] 5250 session, the following
comments may be of interest to anyone wanting to know more about the
Host Print processing....
That describes how those parameter values are set for a job, but as
for the Host Print request, how those parameters are set for the job may
be irrelevant. The host print request resolves spooling different than
the job. Which Display File is active is foremost. That is, the active
DSPF [with a file-level keyword] may define the printer file to be used
for Host Print requests issued while that DSPF is open and active;
PRINT() kwd defining a Printer File instead of the default PRTF QSYSPRT
in *LIBL. Then whatever Printer File is defined for that host print
request, determines the respective spooling parameters such as OUTQ()
and DEV(), though an override can supersede those. If the OUTQ()
parameter on either that printer file or an override does not redirect
to the *JOB [or *DEV], then what was established for those parameters in
the job [as set from a *JOBD or CHGJOB], is moot.
So determining the outq being used by Host Print needs to be
established.
OK. Although realistically if the output already is not being
tracked to the job, that may be assuming too much about the
functionality of the scenario.? I suggested for example that a SPLF
entry might not be tracked to the job perhaps for one of SPOOL(*NO), by
[special] authority a SPLF entry may not be visible to invoker of
WRKJOB, the printer file name were overridden to a database file
[optionally with INHWRT(*YES)], or if the data were redirected to a
stream file. If no SPLF shows FIN nor any other status in WRKJOB
OPTION(*SPLF), then any OUTQ specification would seem to be moot; i.e.
according to the described effect, the output seems never to have found
its way to any Spool File nor any OUTQ.
Bottom line: Use DSPJOB/WRKJOB option 2 to determine the default
outq.
Then use option 15 to see if the printer file has been overridden to
a different outq.
But which printer file is that? As noted above and in a prior reply,
the DDS that defines the active Display File determines the printer file
which determines the OUTQ which may or may not come from the *JOB.
Probably something very similar for use of a UIM display\menu, though I
do not recall the details.
Maybe the client will allow just those 2 outqs to be held while a
test is performed.
Without a good understanding of how the non-spooled and spooling
resolution transpires in the scenario, I do not think some specific "two
output queues" would sufficiently assist. Knowing the printer file
specification in the display active for the Host Print request can
establish exactly which *one* output queue should be the target of the
spooled output; having followed the proper "resolution" for the OUTQ()
from the printer file that should be referenced.
FWiW: The following script confirms the job setup is moot for the
given scenario; i.e. the QPRINT2 output queue which supersedes any
Printer Device specification for the job, is never referenced for the
Host Print request:
<code>
chgjob outq(qgpl/qprint2)
crtprtf *curlib/fred outq(qtemp/barney)
crtdspf *curlib/mydspf /* //data mydspf */
//data file(mydspf) filetype(*src) endchar('//')
A DSPSIZ(24 80 *DS3)
A PRINT(*LIBL/FRED)
A R MYDSPF
A 4 6'Issue Host-Print now'
crtclpgm usemydspf /* //data usemydspf */
//data file(usemydspf) filetype(*src) endchar('//')
dclf mydspf
sndrcvf
//
</code>
The host print request results in the message CPD3322 "The output
queue BARNEY in QTEMP that you specified does not exist. ... The output
queue to be used was changed to QPRINT in library QGPL." which shows
that the printer file FRED was used to resolve the OUTQ().
Regards, Chuck
midrange.com
