Of course, this can be done with a LISTSPF SELEQ ;DETAIL and then SPOOLF
SELEQ ;DELETE, would you agree?
I'm thinking that creating an output file from the LISTSPF, named
LIST!HPDATE for instance, and then ftping that somewhere handy, would give
me a month's worth. Maybe read that with a script, to produce a CSV with one
record per line.
Now, coming up with a cleaner way to STORE them would be handy! Any
ideas?
Greg
----- Original Message -----
From: "Paul Christidis" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, December 01, 2004 8:30 PM
Subject: Re: Spool files
> 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 *
|