From: brad@grok40.ColumbiaSC.NCR.COM (brad.rasmussen)
Subject: Re: lpNet
Organization: NCR MCPD Columbia
Date: Fri, 09 Oct 92 13:15:29 GMT

In article <AJLILL.92Oct8212244@riipsdev.riipsdev.Waterloo.NCR.Com>, ajlill@riipsdev.riipsdev.Waterloo.NCR.Com (Tony Lill) writes:
|> Has anyone actually managed to get remote printing using lpNet
|> working, or is it some collosal practical joke on all NCR customers.

No joke Tony.  I am the first one to admit that remote printing has caused more
than one headache.  I hope the information below helps you out, and restores some
of your confidence in remote printing.  We have been using remote printing in this
plant for some time now, and we also have many customers who have been successful
in getting it working.

|> 
|> The problems I've had are:
|> 
|> - lp totally ignores the retry timeout in the lpsystem file. If the
|> one of the hosts is down and the other lpNet wants to talk, it will
|> respawn just as fast as it can. 30,000 respawns in an hour, not bad
|> for a 486/33 that's also a file server and has a dozen people trying
|> to compile!

What release of software are you currently using?  The respawning was a problem
in the 1.0x releases, but has since been fixed (as far as I know) in the 2.0x
releases.

|> 
|> - I've managed to get it set up and send one job through. That's it
|> though. On the local system, the job status is filtered, and on the
|> remote it is "finished printing". An that's how it will stay. It's
|> never worked again after this point. I've restarted the scheduler,
|> I've rebooted both systems, no help.

This has to do with a breakdown in communication between the local and remote
systems during printing of the jobs.  We have seen that happen here as well.  To
get lp out of that situation, on both machines, go to /var/spool/lp/requests/
system-name and /var/spool/lp/tmp/system-name, where system-name is the name of
the machine that originated the print job.  In those two directories, you will
find files that correspond to the print job that is in the strange state.  The
files have, as part of their name, the same print-id as the job in the strange
state.  Remove these files in both places on both machines, then stop and restart
the lp scheduler on both machines.  This will get rid of the job so that more
print jobs may be sent to the remote printer.  Once the scheduler gets in this
state, no print more print jobs can be serviced, because lp wants each job to 
finish and get removed from the queue before printing the next one.  By the way,
we have put some fixes into the scheduler for these types of situations in
2.00.03 and 2.01, and also into 1.03.  There is a patch for 1.03 called p1-lp.  I
am not sure about patch availability in the 2.0x releases. 

|> 
|> - lp constantly goes into "bit bucket" mode, where all print jobs just
|> vanish. You can't clear it up by stoping and restarting the scheduler
|> either. No, you have to reboot the *&^%ing machine. Real nice if it's
|> your file server, pause the whole department just to get a printout.
|> This problem is not unique to using lpNet, it can happen at any time.

I do know that postscript printers are very sensitive about the data they
receive.  If _any_ strange data gets to the printer (like 2 print jobs colliding
per your observation below), then the printer will just throw the print jobs into
the bit bucket.  In these cases, the printer needs to be reset.  When we first
had postscript printers set up in our plant, I got many complaints like this.
Users need to be sure that the data that is ending up at the printer is in the
postscript format.  If it isn't, nothing will print.

|> 
|> - The documentation doesn't tell you to set up a port monitor on the
|> system without the printer, but it's vital since the other system may
|> want to talk to your system, and it then goes into mega-respawn mode.

Could you explain this one a little more.  What kind of communication are you
referring to here?  There is communication between the two lp services on the
machines without having a port monitor on the system without the printer.  If
there wasn't, the system without the printer would never know the status of the
print jobs.

|> 
|> - If you set up both printers as postscript, then the local printer
|> will turn plain ascii into postscript, and the remote printer will do
|> the same, so you get a nice printout of the postscript version of your
|> original file. So you need to set up a second, fake, printer
|> definition to fix it, then do your own file locking in the interface
|> script 'cause the scheduler is too stupid to realize you can't feed
|> two print jobs to the same device at the same time!

On the system without the printer, don't set up the printer as postscript.  I have
found that it is a good idea to let the system with the printer do all the work
of figuring out what to filter and what not to filter.  So, you can have a single
printer defined on the system without the printer (printer type = unknown,
content type = simple), and have the two printer definitions on the machine with
the printer attached.  And yes, you are correct about the stupidity of the
spooler in the case of having 2 logical printers going to the same physical port.
We have been putting up with that problem, but to date, no code changes have been
implemented to fix it.  Your fix sounds like a pretty straight forward way of
handling it. 
|> 
|> HELP!

I have some instructions for setting up remote printing that goes beyond what was
included in the documentation.  I have also included some debug tips in helping
figure out why remote printing may not be working, but due to the length, I am
not posting it here.  If you would like it, e-mail me, and I will e-mail you the
instructions back.  I hope this helps, and good luck.

|> 
|> --
|> Tony Lill,                                 Tony.Lill@Waterloo.NCR.COM
|> President, A. J. Lill Consultants                 (519) 650 0660
|> 539 Grand Valley Dr., Cambridge, Ont.             (519) 653 9732
|> presently at E&M Waterloo, NCR Canada Ltd.        (519) 884 1710 x624
|> 					     voice plus 643 1624
|> 
|> "Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"

________________________________________________________________________________
Brad Rasmussen               |Phone: (803) 791-6961  
Systems Management Software  |VoicePlus: 632-6961
MCPD Columbia                |Email: brad.rasmussen@ncrcae.columbia.ncr.com
3325 Platt Springs Road      |
West Columbia, SC  29169     |
--------------------------------------------------------------------------------