From: "Brian K. White" <email@example.com> References: <firstname.lastname@example.org> Subject: Re: Printing from Dial-In Win 2K PCs to SCO UNIX - HELP! Date: Sun, 12 May 2002 19:42:52 GMT "Tom Millington" <email@example.com> wrote in message news:firstname.lastname@example.org... > 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 -- email@example.com -- https://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Got something to add? Send me email.