To clear some things up:
I stated that we get DELPND spoolfiles because we invariably have printing
occurring during backups. We do not do a store;purge. The files don't delete
themselves after printing and the backups are done, but remain in the DELPND
state. One cannot print or purge them. A SPOOLF O@;SHOW displays the list of
spoolfiles, but only SPOOLF O@;SELEQ=[STATE=DELPND];SHOW deletes them. They do
not remain in a "READY" state, but are immediately gone from the spooler. (I
didn't try SPOOLF O@;SELEQ=[STATE=DELPND];DELETE, as I found that just "SHOW"ing
them took care of them).
We have never experienced a hung DELPND spoolfile for any other reason than
stores, but the action of SPOOLF O@;SELEQ=[STATE=DELPND];SHOW seemed quirky
enough to suggest it to Marshall. I assumed that the file was intended to be
deleted since it was in a DELPND state.
Russell
______________________________ Reply Separator _________________________________
Subject: Re: delpnd Spoolfile Status
Author: Non-HP-HP3000-L ([log in to unmask]) at HP-Unix
Date: 6/15/95 12:06 PM
From Marshall Medoff:
: I have a spoolfile at DELPND status that doesn't want to print or purge.
: Other spoolfiles are going to the same printer with no problem. I seem to
: remember this being addressed before, so if somebody has the answer or the
: listserv message archive listing, I would greatly appreciate it.
To which Russell Johnson replies:
: I've found that this simple command makes those pesky DELPND spoolfiles
: go away (OP capability needed to access all spoolfiles):
: !SPOOLF O@;SELEQ=[STATE=DELPND];SHOW
: Since opening a DELPND spoolfile will allow it to be deleted, I can only
: guess the SPOOLF command opens the spoolfile to read it's state. We
: have this command in our nightly purge_old_spoolfiles_job to take care
: of all the spoolfiles that printed during backups, and therefore are in
: the DELPND state.
(Sorry for all the impersonal "third person" references below. It seems like
the easiest way to refer to the two snippets above).
A spool file in the DELPND state will not print (must be in the READY
state to be selected), so this aspect is not unexpected. Russell assumes
this is due to the spool file's being stored when someone is trying to
delete it. Maybe so, but Marshall doesn't say either way.
But if Russell's command is doing what he says, I don't understand
that. The command, as shown, does an implied "ALTER". The only effect in
this case is to resurrect files from DELPND and place them in the READY
state. Here's a sample from my system:
One session (not shown) is running SPIFF, and has TEXTed in O8316. So the
spool file is open and cannot be purged. The (edited) display is from a
second session:
:listspf o@;seleq=[state=delpnd]
SPOOLID JOBNUM FILEDES PRI COPIES DEV STATE RSPFN OWNER
#O8316 S81 TEST 1 1 LP DELPND MGR.LB123281
[...]
:SPOOLF O@;SELEQ=[STATE=DELPND];SHOW <-- cut and pasted from above.
SPOOLID JOBNUM FILEDES PRI COPIES DEV STATE RSPFN OWNER
#O8316 S81 TEST 1 1 LP READY MGR.LB123281
Could Russell have meant: :SPOOLF O@;DELETE;SELEQ=[STATE=DELPND];SHOW ?
^^^^^^
If not, then I speculate that Russell's backups include the ;PURGE option.
Because of the way (old) Store works, this would delete the file but leave
the SPFDIR entry. I have not checked SPOOLF code, but it's possible that
Russell's command, finding an entry without a file, would simply delete the
entry.
In any case, the problem (at least as it relates to Store) should be fixed
in C.50.00. The Store team sits next to me, and they tell me that they
have added the following HPCICOMMAND call as part of Store's cleanup:
SPOOLF O@;DELETE;SELEQ=[STATE=DELPND]
This should clean up any old DELPND files (and their checkpoint files).
I have not tried it, however.
None of the above addresses Marshall's original problem, unless he was
storing spool files. So if there are files that SPOOLF ;DELETE can't
delete (assuming the SPOOLF user has the right to delete them, and that
they are not being stored or accessed), we should probably open an SR
for that.
A bit long, but I hope it sheds some light...
Note revised .sig; I now have colleagues in our lab in Bangalore.
-Larry "MPE/iX Spoolers 'R' Us" Byler-
|
