[comp.protocols.tcp-ip.ibmpc] Spooled LPR/LPQ Support

U0A61@WVNVM.WVNET.EDU ("Bryan, Jerry") (06/09/90)

I think this has been asked before, with the response negative, but
I thought I would try again anyway.

We have various machines including mainframes and PC's on a TCP/IP
Ethernet.  We don't have Novell's or 3Com's or anybody else's
networking software between the PC's, just implementations of
TCP/IP on the PC's.  We have LPR and LPQ support on the PC's.  We
don't have an LPD server on the network, but we could make one
fairly easily.  However, even if we did, we could not print from the
PC's to the LPD server in the manner in which we would like.

Let me explain what I mean.  Many of the PC's are running either
spreadsheet software or word processing software.  If I understand
LPR/LPQ correctly, they would be DOS commands issued at the DOS
prompt on the PC's.  They could be used to print a file from the PC.
What we want instead is to somehow or other remain in the spreadsheet
program or the word processing program, have the programs print
as if they were printing to a printer attached to the PC, but have
the printed output go to the LPD server.

I am not hung up on this being necessarily the LPR/LPQ client and
the LPD client,  so something else might do as well.  However, the
users have to be able to stay in their spreadsheet or word processor
rather making an ASCII file, then exiting to print it.  Most of the
PC's are DOS, but we are beginning to migrate some of the to OS/2.

Thanks in advance for any assistance or advice.

dzoey@TERMINUS.UMD.EDU (06/10/90)

> Let me explain what I mean.  Many of the PC's are running either
> spreadsheet software or word processing software.  If I understand
> LPR/LPQ correctly, they would be DOS commands issued at the DOS
> prompt on the PC's.  They could be used to print a file from the PC.
> What we want instead is to somehow or other remain in the spreadsheet
> program or the word processing program, have the programs print
> as if they were printing to a printer attached to the PC, but have
> the printed output go to the LPD server.

I've seen this problem solved in two ways:

1)  Many (all?) implementations of nfs on the PC have a remote printing
    service which redirects print devices to the nfs server where the
    server's regular print daemon can get at them.   When the spreadsheet
    writes to the printer, the print streams get spooled over the network.

2)  Here's what we do in the labs that don't have transparent network printng.
    We have a small TSR that spools the print output to disk.  When the
    user exits the application he/she is notified that there is print
    output generated.  The user is asked to pick a queue to send the
    trapped output or to discard it.


Method one has the advantage in that the method of printing is transparent
to the user.  Method two has the advantage in that you do not need to keep
TCP/IP loaded in the machine all the time, just a small print spooler.  

I personally feel that method one is more elegant, but it does take up 
resources.

                            Joe Herman
                            U. of Md


disclaimer:  I work on the PC/IP project at Maryland.

dzoey@terminus.umd.edu


   

bambi@kirk.nmg.bu.oz (David J. Hughes) (06/14/90)

From article <9006091845.AA03904@terminus.umd.edu>, by dzoey@TERMINUS.UMD.EDU:
> 2)  Here's what we do in the labs that don't have transparent network printng.
>     We have a small TSR that spools the print output to disk.  When the
>     user exits the application he/she is notified that there is print

What we do here sounds similar.  We have written a TSR that spools
printer output to disk,  waits for a predefined time-out period, and if
the file has not increased in size during this time-out period a
connection is made to the LPD on a UNIX host.  The standard LPR/LPD protocol 
is used to spool the file.

Unfortunately, we have not completed work on this package yet, so it is
not available for public distribution.  Public distribution (to
Universities etc I assume) will be considered when the next revision
(including loading the TSR into EMS memory) is complete.


BTW: this sits on top of FTP's PC/TCP version 2.03



bambi
+----------------------------------------------------------------------------+
| David J. Hughes   (AKA bambi)	 |   bambi@kowande.bu.oz.au                  |
| Systems Programmer		 |   bambi@kowande.bu.oz.au@uunet.uu.net     |
| Network Management Group       |   ..!uunet!munnari!kowande.bu.oz.au!bambi |
| Bond University, Gold Coast    |   Phone : +61 75 951111                   |
| Queensland,  Australia  4229   |   Fax :   +61 75 951456                   |
+----------------------------------------------------------------------------+