🚀 go-pugleaf

We had the same problem running Interleaf 3.0.18 under SunOS 4.0. However,
I thought that the two problems that described were one in the same.  We
discovered it had to to with the fact that Interleaf used lpr -s to print
and there is a bug in the SunOS 4.0 version of lpr.  Ruth Aydt wrote about
the cause of this problem in SunSpots v6n195, copy included.

aydt%guitar.cs.uiuc.edu@a.cs.uiuc.edu (Ruth Aydt):
 > Subject: lpr -s /tmp/file fails on 4.0 clients (with fix)
 > 
 > There is a problem with lpr/lpd on 4.0 clients when you try to print a
 > file with the -s option (use symlink to file rather than copying it into
 > the spool area).
 > 
 > lpr writes the device number as returned from stat to the control file
 > with the S tag using printf %d format.  However, this is a short and with
 > the nfs-mounted filesystems it gets written as -32256 or some such number.
 > When lpd then checks the S line in the cf file to make sure the device and
 > inode numbers match those of the "current" file before printing the match
 > fails and the job is rejected. 
 
 > The solution is to change lpr to use only relevant bits when building the
 > cf file:
 >       (void) sprintf(buf, "%d %d", statb.st_dev&0xffff, statb.st_ino);
 > 
 > For us this first turned up when some text-processing scripts submitted
 > jobs that were rejected by lpd.  The lpr -s was "hidden" within the
 > scripts.
 > 
 >       Ruth Aydt
 >       Department of Computer Science
 >       University of Illinois at Urbana-Champaign

Since I don't have the sources I got fixes from SUN for Sun 2s, 3s, and
4s.  The bug report id is 1011856. They seemed to have fixed the printing
problem and I have not seen the out of memory problem since.

	John Sutton
	Los Alamos Nat'l Lab
	(sutton@olin.lanl.gov)