Printing from Dial-In Win 2K PCs to SCO UNIX - HELP!
Tom Millington
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
Tom Millington
IT Manager
AAVF Bideford
tmill...@aavf.co.uk
Brian K. White
"Tom Millington" <tmill...@aavf.co.uk> wrote in message
news:10211935...@ananke.eclipse.net.uk...
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 -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Bob Rasmussen
The easiest method to set up is variously called "transparent printing",
"passthrough printing", "attached printing", "local printing", and who knows
what else. Virtually every terminal emulation program supports this feature
(with varying features), as did the terminals being emulated. A special code
sent from the host turns on passthrough print mode, then data is sent to the
printer, then another code turns it off. Thus it is initiated on the Unix
side, but supported on the Windows side.
To implement this on the host side, check first what "programming environment"
the application is running in. Some, such as filePro and AcuCobol, have
built-in support for this feature and, because it is tightly integrated, it
works very well.
Failing that, check to see how configurable the system is. If you have access
to the Unix command that is run ("piped to") to print, you can set that to run
a shell script or program to do passthrough print, INSTEAD OF going to "lp" or
"lpr".
For more info, see
http://anzio.com/support/whitepapers/printguide.htm
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
Tom Millington
I now know how to implement the escape codes for printing from the shell via
the modem, and they work.
I am still having problems with the application, Sage Tetra CS/3. This is an
Informix-based database application that has its own printing system. I have
spoken to our resellers and it appears the exact 'how it works' is a bit of
a mystery.
CS/3 has its own spooler system. When printing, layout on the page is
controlled by what are known as 'papers'. These papers are assigned to
printers, which are, in turn, assigned to physical devices. It seems that
when a print request is raised by a user, the file to print is formatted
(according to the 'paper') and stored in a spooler directory. The print
sub-system is then called via a command file, known as 'tetra.cmd'. A copy
of our 'tetra.cmd' is shown below.
#echo $@ > /tmp/prout
#Start
case $4 in
itsam_lgl) printfmt $@ |
lp -dITSAMSUNG -ollength8i -olq -olandscape -s;;
itsamsung) printfmt $@ |
lp -dITSAMSUNG -ol66 -oc -s -olpi8 -olandscape;;
itsamsp) printfmt $@
|lp -dITSAMSUNG -ol94 -oc -s -olpi8 -oportrait -on;;
sales6L) printfmt $@ |
lp -dSALES6L -ol66 -oc -s -olpi8 -olandscape -on;;
broth1050) printfmt $@ |
lp -dBROTHER1050 -ol66 -s -oc -olpi8 -olandscape -onb;;
canon) printfmt $@ |
lp -dcanon -ol94 -oc -s -olpi8 -oportrait -onb;;
*) printfmt $@;;
esac
#End
It looks to me like the above simply formats the output, then calls the
physical printer and outputs to it, with standard UNIX print properties.
I was advised that I should be able to create an output line for a serial
port printer that calls a shell script rather than outputting directly to a
printer. However, this does not seem to work. I am also advised that the
'tetra.cmd' file is a bit erratic about what it will or will not do, and
that timing can be an issue and it may need some 'sleep' type commands in
the string to slow it down. This sounds a bit daft to me.
When looking at the print log in CS/3, it reports that it was unable to
create the output. Also, on the SCO server, I noticed that the printer I
created to run via 'tty2a' has disappeared. However, when I try to recreate
it, SCOADMIN tells me it already exists and that there is an error.
When I can get access to the system, I will re-boot it in the hope that it
feels better.
I would really like help on what to put in the 'tetra.cmd' file to get it to
call the shell script successfully. Also, when setting up the printer in
SCOADMIN, do I select a 'local' 'standard' printer via tty2a (the dial in is
via tty2A)?
Regards
Tom Millington
"Tom Millington" <tmill...@aavf.co.uk> wrote in message
news:10211935...@ananke.eclipse.net.uk...
Bob Rasmussen
On Wed, 15 May 2002, Tom Millington wrote:
> ...
It is not clear to me whether the above might have gotten wrapped by the email
process, so bear that in mind.
The desired printer name is apparently in $4. A 'case' statement examines
that, and based on it executes a command 'printfmt $@', with its output piped
to the 'lp' spooler, with appropriate arguments. Now let's assume you can set
your printer variable ($4) to 'local'. Add to the above, after the 'canon)'
line(s), an entry for this new case:
local) printfmt $@ | passthru
In this case, 'passthru' would be the compiled version of our passthru.c
program, as described in
http://www.anzio.com/support/whitepapers/printguide.htm
In other words, you are piping to 'passthru' instead of piping to 'lp'.
> I was advised that I should be able to create an output line for a serial
> port printer that calls a shell script rather than outputting directly to a
> printer. However, this does not seem to work. I am also advised that the
> 'tetra.cmd' file is a bit erratic about what it will or will not do, and
> that timing can be an issue and it may need some 'sleep' type commands in
> the string to slow it down. This sounds a bit daft to me.
Me too.
>
> When looking at the print log in CS/3, it reports that it was unable to
> create the output. Also, on the SCO server, I noticed that the printer I
> created to run via 'tty2a' has disappeared. However, when I try to recreate
> it, SCOADMIN tells me it already exists and that there is an error.
You may be confusing a) printing to a directly attached serial printer, with
b) printing to a passthrough printer (attached to the terminal or emulator). I
thought you wanted to do b). In this case, do NOT define a printer device to
Unix.
> When I can get access to the system, I will re-boot it in the hope that it
> feels better.
>
> I would really like help on what to put in the 'tetra.cmd' file to get it to
> call the shell script successfully. Also, when setting up the printer in
> SCOADMIN, do I select a 'local' 'standard' printer via tty2a (the dial in is
> via tty2A)?
You will need to examine your application, to see how it lets you specify the
printer to be used. It may be an environment variable based on user login.
Hope this helps.