LP as shared resource for 3B2s

LCDR Michael E. Dobson rdc30 at nmrdc1.nmrdc.nnmc.navy.mil
Wed Feb 6 02:39:40 AEST 1991


In article <1991Feb04.165638.3212 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>In article <1991Feb1.142335.19594 at nmrdc1.nmrdc.nnmc.navy.mil> rdc30 at nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:
>>In article <1991Jan31.020837.15416 at eci386.uucp> woods at eci386.UUCP (Greg A. Woods) writes:
>>>In article <30300001 at inmet> pcasey at inmet.inmet.com writes:
>
[my original comment deleted]
>
>In what way are you using RFS to access the printers?  Are you writing
>to the remote-mounted device from a different machine or writing to
>a remote spool directory or something else?  In what way is it better
>than uux'ing to the remote machine?
We write to the spool directory on the remote machine(s) since otherwise there
would be device contention problems.  To the applications, the printers appear
to be just like any local printer.  Data throughput is much faster (but yes,
mostly irrelavent with a spool) since we use Ethernet speeds.  But mostly it
is better because it was the easiest to implement, no special shell scripts,
no uucp over TCP/IP or setting up a uucp connection, everything was done via
the sysadm rfsmgmt scripts.
>
>>On top of that, they are also advertised as netbios resources so
>>from my PC I can say "use lpt3: \\host\rmtprint1" and print from my PC to
>>a printer on another 3B2 across campus that is mounted via RFS on my 3B2.  We
>>couldn't do this via UUCP over WIN3b.
>
>Why not?  You should be able to send your PC printouts to an arbitrary program
>or shell script (at least you can in the previous DOS SERVER release - I hope
>this hasn't gone away in the LM/X upgrade).  In any case you could set up
>an lp queue on the local machine whose interface program actually executes
>uux to the destination machine.
How do you advertise a shell script or program as a netbios shared resource
easily?  Yes it can be done with custom scripts and hacks but why go to the
effort when the RFS solution is (for me at least) much easier to implement?

>
>>I can also print to that printer from
>>applications on the local 3B2.  Very useful for sending finished documents
>>across campus ;-).
>
>Again, I don't see that RFS is needed for this.  I do it with uux, sometimes

It isn't really needed, just perhaps easier to implment for us.

>over a network, sometimes over dialup links.  There is perhaps a bit
>more overhead this way but it will work even when you can't get an
>immediate connection to the destination machine.

Now this is a reason to use uux versus RFS, at least with uux, if the job
fails, it just stays in the queue, with RFS when the link goes down things can
get rather unpleasant.

Les, I'd like to carry this on further in e-mail because I am really not to
clear on the how's of the uux implementation for all the above and I don't
want to put out bad information to the net.  THe RFS solution works very well
in our environment, but I am always interested in viable alternatives.

-- 
Mike Dobson, Sys Admin for      | Internet: rdc30 at nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30
AT&T 3B2/600G Sys V R 3.2.2     | BITNET:   dobson at usuhsb or nrd0mxd at vmnmdsc
WIN/TCP for 3B2                 | MCI-Mail: 377-2719 or 0003772719 at mcimail.com



More information about the Comp.sys.att mailing list