News Group Posts

local printing over internet

From: "Brian K. White" <brian@aljex.com>
References: <1021193585.931734@ananke.eclipse.net.uk> 
Subject: Re: Printing from Dial-In Win 2K PCs to SCO UNIX - HELP!
Date: Sun, 12 May 2002 19:42:52 GMT


"Tom Millington" <tmillington@aavf.co.uk> wrote in message
news:1021193585.931734@ananke.eclipse.net.uk...
> Hi
>
> Firstly, apologies if I have over subscribed this message.
>
> We have a few 'remote access' PC users (running Win98 and Win2KPro) who
dial
> in to our SCO UNIX Server via a modem on the back of the server (tty2A)
to
> access our factory management system (Sage/Tetra CS3) using a standard
> terminal emulation program, NetTerm. So far, so good. This has worked
> sweetly for years.
>
> However, we suddenly need these users to run CS3 reports and to print
them
> out to the printer attached to the parallel port of their remote PCs.
>
> CS3 has its own print management system which runs a background print
which
> then outputs to a named SCO UNIX printer (using the 'lpr' command),
> recognised by IP address. I have managed to get printing to direct to
the
> printer attached to the parallel port of my PC whilst I am on the
network:
> not a problem with Win2K, by sharing the printer and setting up TCP/IP
print
> services and setting up a SCO UNIX printer with the share name I have
given
> it, on the user listed in the 'hosts' file, recognised by IP address.
>
> However, how do I get SCO UNIX to print to the serial port AND for the
PC to
> recognise what is coming in to be 'printing' for the attached parallel
> printer?
>
> I have tried dialling in from my PC, and establishing a connection and
> outputting to a UNIX printer called 'serial' attached to '/dev/tty2A'.
The
> result is that it simply dumps the data on the PC's screen.
>
> We do not have any Windows NT or Win2K servers on site, nor any devices
set
> up for RAS dial-in, nor do we particularly want any.
>
> I have downloaded a demo copy of J Rivers' ICE.TCP Pro but I cannot see
how
> to set this up for remote dialling in, although there are instructions
for
> installing it remotely. I would prefer not to use 3rd party software, if
> possible.
>
> Our priorities are for a couple of Win2K Pro users, but Win98 users
would be
> useful later.
>
> Any ideas anyone, please? Please note that I am neither a UNIX or a
Windows
> guru.
>
> Regards

You have a lot to consider, and unlees you are very lucky with your
application supporting a particular feature, it's going to be a bit of a
chore to get this going.

Three main possible approaches;

1) see if netterm supports the ansi escape sequence for a feature called
"local print" or "passthru print". if netterm doesn't, many other scoansi
capable serial terminal emulators do.

pros: easiest thing to try immediately, no need to change anything on the
remote users PC assuming netterm supports the feature. This is the case I
meant above by "if you are very lucky")

cons: depending on the behaviour of the unix application, you may not be
able to use this method with that application even if netterm supports the
feature, because the application has to know enough to _not send any
characters to the screen at all while printing is taking place_ .

If the _only_ way the application knows how to print is by handing off the
job to lp in the background, this probably won't work, but you should
know: lot's of unix apps have printing setup that appears at first glance
to only use the lp spooler system, but in fact many have built in
knowledge of the concept of "local printing" it's a very old thing.
Usually the app either has some place where you can define "printer on /
printer off" sequences, or maybe "printer init / printer finish" ,
sometimes it is in the form of the app having it's own termcap file, and
you have to add PN and PS capabilities to the definition for your term
type. sometimes all you have to do is add PN and PS to the entry for your
terminal in the system-wide /etc/termcap and the system-wide terminfo
database. I would try hard to find out more about the app because it is
going to be a lot easier to do this than anything else if it's possible.

2) set up incoming PPP on the sco box, and have the remote users dial in
with windows DUN (Dial Up Networking) just like they were dialing up an
internet service provider. Then, use netterm or any other terminal
emulator as a telnet (TCP/IP) client, not direct serial.

pros: when dialed in this way, you can have several telnet windows open
into the application at once. you can use ftp (right in plain old internet
explorer) to move files back and forth between the PC and Unix. you can
share the printer on the PC and print to it from unix much the same way
that you did with the PC that was in the office. Actually, if you install
samba on the unix box, it will be easier to print to the PC printers
because you don't need windows 2000's unix print services stuff, just
regular windows netbios (microsoft file & print sharing) which is
available on all versions of windows.
You would have to tell the users all to "share" their printer using the
same name, and everyone would have to have a printer that can at least
print plain text on it's own (these day there are a lot of ink-jets and
even some lasers that cannot accept a simple stream of characters and
print them, they *only* know how to print from the windows printer driver,
which is not used when unix prints to a shared printer. You can get around
this by using yet another method of "sharing" besides netbios and win2k's
unix print service, 3rd party print server software that can be told to
pass the data to the windows printer driver rather than directly to the
printer. best example: PrintWizard from www.anzio.com this program
actually offers a whole bunch of different spins and twists on how to
print from unix to windows. If you were willing to install it on every
remote pc you could have good reliable tcp/ip printing, properly rendered,
on any printer for which a windows driver exists, the remote users would
not all have to have a certain type of printer, or be above a certain
bottom level of quality.

cons: incoming PPP is kind of difficult to set up and get wirking on the
unix side, then you will have to talk the remote users through configuring
the new dial up networking account, then you will have to talk them
through changing some settings in netterm so that it uses telnet instead
of serial. I'm not going to count the work involved in setting up the
printer sharing as a "con" here, because you will incur that in one form
or another no matter what. It's not really any worse this way. better
actually.

3) connect the server to the internet and have the remote users connect to
the internet instead of directly dialing the server.

pros: easier to set up outgoing PPP on unix than incoming, *extremely*
easy if you just get one of those routers that dials and connects for you
or if you can get cable or dsl. many users can connect at once, and like
above, each one may have any number of open telnet sessions at once. like
above, people can have ftp file transfer, like above, you can print
reliably using tcp/ip using various protocols like lpd (aka "unix print
services") or special printing software like printwizard.

cons: going over the internet means telnet is not safe to use, you had
better use ssh, or something proprietary that happens to also be encrypted
at least for the login & password phase (facetwin, anszio with the SRP
option, etc...) so if netterm doesn't support some form of protected login
method you will have to get a different telnet/ssh client to use on the
PC's.
you will have to set up a script on the unix box that works with another
script on some stable web host so that whenever the unix box connects to
the internet, it's current IP address gets updated on some web page,
otherwise the remote users will never know the servers address and thus
can not connect to it.
you won't be able to use samba (windows file & print sharing) to share the
printers and print to them from unix because most isp's block the tcp port
that that works on so that their idiot customers are minimally protected
from sharing their C: drives with full read/write permissions and no
password to the entire globe, so you will have to use some add-on print
server software at least on windows 9x/me.


in both "2" and "3", it will be possible for the unix application to hand
off the print job to "lp" and continue writing to the screen, meaning it
will work with your application and any application that already works
with the lp spooler.

oh there is another way... if you install a "smart" multi-port serial
adapter, such as equinox or digiboard, and put the modem on that instead
of the plain COM1/COM2 serial port, then the drivers that come with these
cards offer a feature called virtual printer device ports. This uses
passthru print escape codes and requires the terminal emulator (netterm in
your case) to support passthru print, but in this case the serial driver
that comes with the card manages the physical serial device and *it* does
the necessary halting of screen drawing while print data is going through,
so neither the application nor anything else on the unix side needs to
know about the special needs of passthru printing. the driver installs a
bunch of new devices in /dev, usually 2 or three devices for every
physical serial port. when an application sends data to a device, the
driver treats it differently depending on what type of device was used.
example: the card has four serial ports
for port number 1, there is three different devices in /dev,
two of which can actually be used for different purposes at the same time
by different programs. /dev/tty1A1 is a standard serial port with modem
control. this means the driver aknowledges the existance of more of the
flow-control pins in the port. /dev/tty1a1 is a standard serial port
without modem control, this means you can wire up a terminal with as few
as three actual conductors in the wire, and the driver will not think that
the terminal is "offline" just because for example the carrier-detect pin
is not active.
/dev/tty1A1p is a virtual serial port that you use in scoadmin to set up a
printer. any data that is sent to this device is taken in by the driver,
and the driver will intermittently suspend the traffic that is taking
place on /dev/tty1A1, send a "printer on" escape code to /dev/tty1A1
followed by some or all of the print data that came in on /dev/tty1A1p
followed by a "printer off" escape code, and then it restores/resumes the
traffic that was originally going on /dev/tty1A1, it buffers the data that
was coming in while it was suspended so nothing is lost. In this way, you
can use passthru with any application on unix, not just ones that know
about the way passthru print works. On the PC side, this means they can
keep on just dialing directly in like they are now and as long as netterm
supports that escape code, and as long as their printer is not of the
ultra-cheap brainless "windows-only" variety, and as long as you send only
plain ascii text, it will work.

pros: possibly a little easier than either 2 or 3, depending on the
hardware & driver install procedure. definetly a lot easier once the card
is in or if there happens to already be a card installed you didn't think
to tell us about.

cons: none really in my opinion. some people don't "like" passthru
printing because originally it was used to print to serial dumb terminals,
and often people never had flow-control and speed properly configured on
these terminals so the serial connection was actually not reliable. good
enough for screen draws, but not good enough for continuous streams of
data, leading to very unreliable operation when trying to use passthru
printing. also, fo a long time these serial connections were very slow,
limited to 9600 baud or if you were lucky 19.2 or more rarely 38.4. so
even if you had the flow control and other serial settings properly
configured such that the connection was 100% reliable, it was still slow,
so when you printed anything, your screen was locked for however long it
took for the print data to go through. a page might be 2 seconds, a report
might be 3 hours. but with faster serial connections in the form of 33.6k*
modems, and reliable connections in the form of tcp/ip instead of long
unshielded direct serial wires, and much much faster connections if you
are lucky enough to have dsl or cable at bothe ends of the connection,
these issues basically don't exist today and the bias is not really
justified any more. I use passthru in lots of situations and it has been
just great. The concept was never bad, merely the underlying system it
needed to work on top of, or within, was often not implimented well
enough. Today the underlying system is a lot better.

(*) surprise: your 56k modem does *not* work over 33.6 except in the
special case of connecting to special modems that ISP's have, and then
only in the download direction. when your users dial in to your unix box,
whether it is dialup networking or plain direct serial login, it is only
33.6, albeit somewhat enhanced by the transparent compression and error
correction

--
Brian K. White  --  brian@aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.