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



On 23 May 2013 10:05, Robert Clay wrote:
<<SNIP>>

We've had some jobs (primarily QZDASOINIT jobs) with issues the
past several weeks that are issuing dumps. The spool files for the
dumps are directed to output queue QEZDEBUG where they remain
unprinted. HOWEVER, there are associated spool files (entitled "Work
with Job") that are printing out because they are going to PRT01.
Depending upon the extent of the problem, these reports can run over
25 pages each. Normally, I would just chunk them in the recycle bin.
But, we are wasting trees because no one will ever look at them.

Presumably the issue has been investigated for resolution and\or submitted as an issue to a service provider to investigate.? A preventive fix would provide an effective resolution; at least for those spools no longer being created for that since-resolved or circumvented problem origin.

It hasn't been an issue for the 15+ years that I've been here but
my boss found a few of the reports. I have been tasked with
determining a resolution to this horrible problem which has occurred
8 times in the past 2 weeks (she is a bit dramatic at times).

Per mention of QEZDEBUG in effect for the QPSRVDMP, but not in what sounds to be a QPDSPJOB, a simple /resolution/ [or better, as a /circumvention/ until the dummy printer is put into effect for the System Value QPRTDEV] to effect similar for both, is to issue against the latter, the same request that the request to CHGCLNUP had effected for the former. That is, issue the request:
CHGPRTF QPDSPJOB OUTQ(QEZDEBUG)

Note: If there are more than QSYS/QPDSPJOB, perform the request against those as well. This will have a /potentially negative/ side effect, that user requested WRKJOB [or DSPJOB] which are directed to OUTPUT(*PRINT) will appear also in the QEZDEBUG output queue, whereas previously they likely had been directed to the Output Queue assied to the job [OUTQ(*JOB)].

I think that an easy solution would be to setup a dummy print
device or output queue that wouldn't ever have the print writer
started (say, PRT99) and change the QPRTDEV value to match it.
<<SNIP>>

This was the solution I chose on all of my systems ever since I can remember of post-System/38. Personally I would avoid PRT99; I called my dummy printer JUNK to denote that what goes there might be considered /junk/ and thus anyone finding their output there might want to move it... and perhaps even motivated to investigate why their output has been relegated to an apparent /junk/ status :-)


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.