Hi Greg,

I found myself in a similar situation some years back.  The 'solution'
that I've implemented, using NBSPOOL, is as follows:

1.  A job is run every morning to delete any spoolfiles that based on a
variety of parameters. (priority, outclass, age, etc.)

2.  A record of each spoolfile that qualifies for deletion is written on
the job's $stdlist as follows:
PURGE  DEVICE=NOPRINT,<=TODAY-15;SHOW
25 Spool Files Qualify

SFID    FILENAME  JOB     USER NAME         SECTORS  DEVICE  PRI  WHEN
CREATED
-------------------------------------------------------------------------------
#O12482 $STDLIST #J3018   MANAGER.SYS            64  NOPRINT   8 11/15/04
00:10
#O12483 $STDLIST #J3019   MANAGER.SYS            32  NOPRINT   8 11/15/04
00:10
...
#O12841 $STDLIST #J3072   MANAGER.SYS            48  NOPRINT   8 11/15/04
05:00
#O12887 C6998ALL #J3082   PROG5.VXL             576  NOPRINT   8 11/15/04
06:00
#O12893 C7283ALL #J3085   PROG5.VXL             432  NOPRINT   8 11/15/04
06:10
...

3. The above $stdlist is emailed to myself and another programmer and
archived.

4.  When a specific spoolfile is needed it can be located using the
recorded information.

5.  The restore job can then use the 'SFID' to restore the specific spool
file.

I implemented the above around August of 2001 and have used it a few times
since then.

Regards
Paul Christidis



HP-3000 Systems Discussion <[log in to unmask]> wrote on 12/01/2004
04:34:45 PM:

> We just had an exciting experience... We had some apparently important
> reports that ran on Thanksgiving and did not get printed. We only keep
two
> day's worth of spool files on the system. So, we were restoring our STD
> file, and from that, all of our spool files from Friday. Then we began
to
> get reports of slow system response time, and our N class (MPE 7.0)
> consistently has sub-second response time for the application. After
> checking some of the more obvious possibilities, I called Beechglen. Jon
> Backus and Doug Werth found that the spooler was consuming all available
> CPU. Apparently, the spooler was having trouble both spooling to print,
and
> having restore write files to OUT.HPSPOOL. That sounds like a bug. So,
> beware!
>
> Now, among the many challenges we have with how we handle printing is
how we
> store and restore our spool files, such that getting back some of our
spool
> files means restoring all of them. There has to be a better way. Short
of
> buying a product, what are some better ways?
>
> Greg Stigers
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *