× 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 1/26/11 10:52 AM, James H. H. Lampert wrote:
For technical support purposes, we have accounts on a number of our
customers' systems.

On some of them, we're set up so that any spool files we create go to
a live printer.

We don't do that around our OWN office (let's face it, repeated
hardcopy compilation listings of 23K-line MI programs do nobody any
good!), and we CERTAINLY don't want our spool files printed instantly
at some printer we don't have access to, so that we never get to see
them, and just waste the customer's paper.

But it seems like every time I try to do this, it takes forever, and
I'm never quite sure what I actually did.

What is the quickest, easiest way to alter our account so that the
spool files we create never get printed unless we explicitly send
them to a live printer, and instead just sit in their output queues
indefinitely?


Whenever I would sign-on to a customer system, one of the first things I would do, would be to issue the following command to be sure to avoid any accidental printing and that the spool files should remain without some explicit attempt by the customer to purge them:

OVRPRTF *PRTF HOLD(*YES) SAVE(*YES) SPOOL(*YES)
OVRSCOPE(*JOB) SPLFOWN(*JOB) OUTQ(QPRINTS)
MAXRCDS(*NOMAX) USRDTA('My Debug')
PRTTXT(*BLANK) RPLUNPRT(*NO) COPIES(1)
SCHEDULE(*IMMED) USRDFNOPT(*NONE) USRDFNOBJ(*NONE)
/* only the first two or three lines mostly */

Perhaps it was QPRINT2 instead.? Regardless, another means was to effect the "same" override, but directing to a *IP output queue that routed all the data back to my source system. That was ideal for fast connections, and for when...

At some point I recall having had problems with TELNET causing some spools to appear on the wrong system [prior to the current target], but that effect was irrespective of having used the above command string; i.e. unfortunately, not even that command string seemed to prevent some spools from going back to the home or an intermediate system. IIRC the data always came all the way back to the home\support system whence the original TELNET was initiated.

Regards, Chuck

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.