Like you I too would balk at holding outqs. It was just a suggestion. I would balk more so at installing a "special" vendor program to check for an error though. Especially if it would impact production in any way.
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.
Printer Device - Help
The name of the printer device or the source for the name of the printer
device that is used for all spooled files created by jobs that use this
job description.
*USRPRF The printer device name is obtained from the user profile of
the job at the time the job is started.
*SYSVAL The value in the system value QPRTDEV at the time the job is
started is used as the printer device name.
*WRKSTN The printer device name is obtained from the work station
where the job was started.
printer-device-name The name of the printer device that is used with
this job description.
Output Queue - Help
The name of the output queue that is used as the default output queue
for jobs that use this job description and the library that contains the
output queue is also shown.
*USRPRF The output queue name for jobs using this job description is
obtained from the user profile of the job at the time the
job is started.
*DEV The output queue with the same name as the printer device
for this job description is used.
*WRKSTN The output queue name is obtained from the device
description from which this job is started.
output-queue-name The name and library of the output queue for this job
Plus, an initial sign on program can perform an override. So determining the outq being used by Host Print needs to be established.
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.
Maybe the client will allow just those 2 outqs to be held while a test is performed.
Gary
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, December 21, 2011 2:07 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
OK. However the point was "to test", to investigate the /failing/ scenario rather than something to resolve or circumvent, and finally to review the results of that test. Something that could be "more agreeable" [and very probably much easier] for a client than to have them "hold all the output queues and then run your test."
I just do not see holding all of the output queues on a customer's system would be very agreeable to most customers, just to let the sfw provider test their code; I know I would hesitate even to have asked a customer to do something like that. The OVRPRTF *PRTF OVRSCOPE(*JOB) could be the first command issued in a job that later did the host-print or puts(). That CL request could be in a routing program based-on specific entry Request Data, even limited to a subsystem setup just for that test; i.e. no requirement to change the program that does the "puts()".
Regards, Chuck
On 21-Dec-2011 13:24 , Monnier, Gary wrote:
But on their new box, while compilation listings and PRTTRGPGM
listings still produce spool files, the "host print" key (wherever
I've tried it) and "puts() in a batch job" don't.
There is no spool file if I do a WRKSPLF; there's no spool file in
WRKJOB option 4; there have been no reports of unexpected pages
coming out of unexpected printers.
"puts() in a batch job" was also an issue wasn't it?
On Wednesday, December 21, 2011 12:39 PM Rob wrote:
Change what program? He was having an issue with Print Key. Enter
that command at the command line and test.
"Monnier, Gary" on 12/21/2011 03:35 PM wrote:
Yea, but who wants to change a program if you don't have to. :)
--
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
