Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdahl!cerebus!ronc
From: ronc@cerebus.UUCP (Ronald O. Christian)
Newsgroups: comp.sys.sequent
Subject: Re: Problem(?) with lp
Keywords: sysV lp BUG?
Message-ID: <929@cerebus.UUCP>
Date: 23 Aug 88 16:03:14 GMT
References: <147@pbseps.UUCP>
Reply-To: ronc@cerebus.UUCP (Ronald O. Christian)
Organization: Fujitsu America, Inc.
Lines: 34


We have seen all these problems on a Vax running SysV from
AT&T, and have seen them also on the Dynix SysV emulation.
One that I would add that I have also seen on both systems
is that sometimes the lpsched daemon fails to start on boot.

I just assumed that Sequent copied the original buggy AT&T
code verbatum to Dynix.

Currently we have both lp and lpr up, but the interface scripts
for lp are diddled to call "ucb lpr" with the appropriate arguments.
The pluses of this arrangement are that (1) you can use lp to access
printers on Ethernet (like our Imagens) or remote printers that the
AT&T code doesn't support, and (2) it gets rid of some of the bugs
in lp.  (The flow control problems, for instance.)  The minuses are
that the lpsched daemon still doesn't always start on boot, and the
lp queue still gets jammed occasionally.  I have considered putting
something in crontab to periodically look at the lpsched deamon and
restart as necessary, but haven't tried it yet.

Most users here use a shell script that calls "ucb lpr $*" and use
the lpr options when they have to perform work in the att universe.
My experience is that lpr is much more robust than lp.  (Dynix 2.1,
Dynix 3.0, and both SysVR2 and 4.3 BSD on a Vax 11/780.)



				Ron
-- 

      Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.)
      {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc

      Calling all Fujitsu Usenet sites!  Contact cerebus!ronc or
      ronc@fai.com to establish uucp connection.