Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: sutton%olin@lanl.gov (John Sutton)
Newsgroups: comp.sys.sun
Subject: Re: usr/ucb/lpr Out of memory problems with Interleaf
Keywords: Software
Message-ID: <8904251348.AA14255@olin>
Date: 6 May 89 14:49:41 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 39
Approved: Sun-Spots@rice.edu
Original-Date: Tue, 25 Apr 89 07:48:12 MDT
X-Sun-Spots-Digest: Volume 7, Issue 272, message 12 of 19

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)