marks@philabs.philips.com (Evan R. Marks) (04/22/89)
Has anyone come across problems printing with Interleaf 4.0 under SunOS
4.0. We had 2 major problems, now down to one.
1. Interleaf displays file sent to the printer but nothing ever came out.
After calls to Interleaf and Sun, we replaced the SunOS 4.0 version of lpd
with SunOS 3.4 version (supplied with Interleaf curiously enough).
This fixed this problem, but the 2nd problem remains.
2. usr/ucb/lpr Out of Memory - happens randomly to all users including the
workstation that the interleaf printer is attached to.
We were informed that a temporary workaround is to open up a terminal in
interleaf then close it. Believe it or not, this fixes the problem 75% of
the time. I would prefer a 100% solution if anyone know one.
If anyone has solved this problem, either e-mail me or post it. It might
be of interest to others also.
--
Evan R. Marks Pratt & Whitney Aircraft
Sr. Sys. S/W Specialist 400 Main St.
m.s. 161-05 East Hartford, CT, 06108
{philabs,utah-gr}!pwa-b!markssutton%olin@lanl.gov (John Sutton) (05/06/89)
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)
zjat02@uunet.uu.net (Jon A. Tankersley) (05/08/89)
Get the lpr patch for 4.x instead. It is available. Interleaf has the Sun problem number to ask for the patch. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
sob@bcm.tmc.edu (Stan Barber) (05/17/89)
The solution (unofficially, but from Interleaf) is to replace the 4.0 lpr
with the 3.4 or 3.5 lpr.
Believe me, it works.
A problem we had involved upgrading and the postscript prologue.
When you upgrade, be sure to cycle power on the printer or the old
prologue will screw things up. Cycling power will cause the old prologue
to be forgotten and a new one will be downloaded.
This reminded me of Macintoshes and LaserPrep...:-)
Stan internet: sob@bcm.tmc.edu Manager, Networking
Olan uucp: {rutgers,mailrus}!bcm!sob Information Technology
Barber Opinions expressed are only mine. Baylor College of Medicine