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



Thanks Chuck.

You proved my point - Tracking down the Host Print outq can be interesting.

Gary

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, December 21, 2011 7:00 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: (see thread on RPG list) Re: Test program calls puts(), creates spool file here, but not on customer box

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