>>Morale of the story:
>>- somebody will propose a third party tool, which will be incompatible with something else. No go - not because of compatibility with the Windows (which are flawed already), but because I don't want to replace one problem with another.
>>- don't ever let the printer go hungry or you'll waste 20 sheets of paper and about a kilometer of neural tissue
>>- dig up that extra FreeBsd machine and hook it up as a server. Hook the printer to it (dunno if that'd work, this is a winprinter)
>>- remember the RPTI network, Lantastic or any version of Novell, when any print job had the decency to stay shot when it's shot. No Terminator/Krüger/cheap horror resurrections. Reminisce and sigh.
>
>The long wait to delete is a PITA. You can try stopping, then restarting the Print Spooler service while the job says "Deleting ...": http://www.mcse.ms/archive/index.php/t-1660474.html

Nice - stop the service, go to spooler directory, delete a few files (if you know which ones, if not, just kill'em all), restart spooler. The OS should be capable of doing it by itself. Actually, spooler should know which files, and how to delete them. How hard can that be? All the networks I mentioned were capable of that, as early as 1989 or earlier. RPTI in particular took only 20K of memory and ran on XT machines, and I managed to teach even semiliterate operators (with no knowledge of English) to run the spooler control screen.

Thanks for the link - I may remember to do this before I my pressure goes up next time.