Discussion seems to have died down, and I think that I've got answers to
the questions that I asked.  Some come from offline experiments, some from
the discussion.  In sum:

Conclusions: ``lprm'' and ``lpr -r'' do not work for me; ``lprm'', does,
however, work for some people (at least).  Multiple print-queues for a
single device appear to be both safe and within the design of our printer
software (kudos to the author(s)).  For at least some (one?) of us,
printer-buffers are Bad Things.  (Turning them on/off doesn't seem to much
affect performance on my LQ-850, but correct operation is easier to assure
without the buffer.)

Details:

1) lprm: This command works for some people, but apparently not for
   everyone (myself included).  It has nothing to do with multiple
   print-queues (I removed one of mine, shut off my printer so that
   jobs would definitely queue, queued up a couple of jobs, and
   _tried_ to lprm the jobs; no dice).

   I have just bugrep'ed it via the Web.  (I checked to see if
   there any outstanding bugreports with the substring ``lpr'';
   none showed up).

2) lpr -r: No one here seems to know if it might be a bug or a feature
   to have this not work, but it seems that it does not work for
   anyone who's tried it.  The GNU/LINUX crowd seems to deprecate
   this feature, but no reason is given.  It may be a bug that
   our lpr does not honor ``-r'', or it may be a case of the man-page
   being out of date.

   I have just bugrep'ed this via the Web, as well.

3) Tail-ends of print-jobs being munged by subsequent print-jobs: This
   seems to be caused by a variation on the following sequence of
   events (I would have to walk through the sources to verify exactly,
   so it is part guesswork):

     Print-job (A) goes to the printer.

     Print-job (A) gets the last of its data sent to the printer---
     however, because the printer has a buffer, and is physically
     slow, it may continue printing (A) for an unspecified period of time.

     Print-job (B) is fired up, through GhostScript.  GhostScript prepends
     some agressive printer-reset commands (at least for lq850), and
     starts emitting.

     lpd sends (B) to printer, along with agressive printer-reset
     commands, before (A) is done printing.  Result: (A) has the
     last bits trashed, and (B) starts printing at the bottom of the
     last page of (A), rather than on the top of its own page.


   The exact sequence depends on the scenario.  However, the above
   describes the gist of the problem.

   There IS a delay in lpd switching between print-queues (see (4),
   below).  However, the delay is not sufficient to flush the buffer
   on my LQ-850.  (The printer has a 6K buffer, and is not that fast.)

   An apparent FIX is to disable the printer buffer.  This has been
   LIGHTLY tested, and seems to be okay.  Ideally, there should be a
   way to specify a delay after the end of any given job for any
   printer-queue.  (Or, perhaps there is a way to tone down the
   printer-reset string from GhostScript?)

   As I recall, dvips of back-to-back files does not seem to cause
   a problem, even with the buffer enabled.  Since I have it going
   through my ``ps'' printer, it should operate the same as other
   ``ps'' print jobs.  So, either my memory is faulty, here, or
   else there is more to the story than I see.


4) Multiple printer-queues for single printers work flawlessly, as far as
   I can tell.

   Although UNIX doesn't generally block multiple writers to files or
   devices, BSD does have a cooperative filelocking mechanism, which
   may be what lpd is using.  In any case, while one print-job is
   running, lpd WILL block other queues using the same physical printer.
   (This, in any case, works correctly with /dev/lpt0, on i386 1.3.3.)

   If one queue is actively using the indicated device, and another
   job is trying to run on the same device in another queue, lpc's
   ``status'' command will report the second logical printer is
   down.  The condition automatically clears momentarily after the
   first job completes.  (Exactly how this works, I am not sure.
   lpd could be auto-restarting every minute, say; or it may be
   using some kind of IPC to indicate availability.  The curious
   may consult the source code.  For the moment, I am content that
   it works.  If you try this, note especially what I say about
   buffers, above---although the buffering problem seems somewhat
   independant of multiple queues, I think that it might be exacerbated
   by them.)



Here is an abbreviated version of my /etc/printcap (sans comments):

 /~~~ /etc/printcap

lp|local line printer:\
	:lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:\
	:sh:

ps|PostScript printer:\
	:lp=/dev/lpt0:sd=/var/spool/output/lpd-ps:lf=/var/log/lpd-ps-errs:\
	:sh:\
	:of=/usr/local/libexec/printer-filters/ps:

 \___ /etc/printcap


...where /usr/local/libexec/printer-filters/ps looks something like:

 /~~~ /usr/local/libexec/printer-filters/ps

#!/bin/sh

/usr/pkg/bin/gs -sDEVICE=lq850 -q -sOutputFile=- -

 \___ /usr/local/libexec/printer-filters/ps


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu