Running OS 5.0.5. Replaced WYSE terminal w/W2000. This client has an Oki 320 attached to lpt1 and an HP 3330 on a USB port. The Oki is srtictly a forms printer used with Unix only. The HP is strictly for printing from Windows. I have installed several terminal emulation products (installed on client only) in an attempt to test access to the Oki with varying results. Problem 1: The W2000 client can print to the Oki fine. When another client tries to print, the first job prints to the Oki and subsequent jobs print to the screen. OR Problem 2: All print jobs print to the HP3330 which is the default windows printer. The problem is dependent on the emulation software being used at the time. Short of downloading & testing all terminal emulators, can anyone give a suggestion/solution. Thanks.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Terminal emulation software, client print problem
- Thread starter masinc1
- Start date
fredericofonseca
IS-IT--Management
If you are using print screen or transparent printing then you may get that problem
Do you really need it?
If you are doing "normal" printing then drop the print screen bit, and start using it aa a network printer.
Use samba ( or LPR/LPD to do it.
This is offcourse assuming you are connecting using TCP/IP.
If not then I would need to dig my old 92's DBVIEW and give it to you if nothing else works!!
As for emulators.
(and others)
All the above should work fine with your situation.
Regards
Frederico Fonseca
SysSoft Integrated Ltd
Do you really need it?
If you are doing "normal" printing then drop the print screen bit, and start using it aa a network printer.
Use samba ( or LPR/LPD to do it.
This is offcourse assuming you are connecting using TCP/IP.
If not then I would need to dig my old 92's DBVIEW and give it to you if nothing else works!!
As for emulators.
(and others)
All the above should work fine with your situation.
Regards
Frederico Fonseca
SysSoft Integrated Ltd
- Thread starter
- #4
fredericofonseca
IS-IT--Management
macsinc1,
If you have tried any of the emulators I spoke, can you please tell us what was the result with each one of them?
If not try them.
And why not connect the Clients using TCP/IP instead of serial?
Regards
Frederico Fonseca
SysSoft Integrated Ltd
If you have tried any of the emulators I spoke, can you please tell us what was the result with each one of them?
If not try them.
And why not connect the Clients using TCP/IP instead of serial?
Regards
Frederico Fonseca
SysSoft Integrated Ltd
Strictly a matter of setting up the DIGI and tinyterm correctly for passthru printing. And of identifying the emulation you are using and keeping it consistent.
I have had my best results with Wyse60 emulation and no problems printing from other users.
Haven't had as much experience with emulators under 2K but those I have had were no different than the 9x stuff.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
I have had my best results with Wyse60 emulation and no problems printing from other users.
Haven't had as much experience with emulators under 2K but those I have had were no different than the 9x stuff.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
stanhubble
MIS
We have had great results with kermit95. It supports multiple emulations and passthru printing can be defined to a device or a windows print queue.
As far as the problem with 1 job working then others going to the screen.....it is missing the "start of print job escape sequence".
Check your "ditty" settings for onstr and offstr on both the /dev/ttyxxx line that the terminal (or emulator) is attached to AND the /dev/prixxx device that other users would print to. Flow control could also be an issue.
As far as the problem with 1 job working then others going to the screen.....it is missing the "start of print job escape sequence".
Check your "ditty" settings for onstr and offstr on both the /dev/ttyxxx line that the terminal (or emulator) is attached to AND the /dev/prixxx device that other users would print to. Flow control could also be an issue.
- Thread starter
- #8
fredricofonseca:I have tried Tiny Term and spoken with their support. It apparently will not work. I have spoken with Anzio and Kermit95 and will test one or both.
Also will check on suggestions from the other contributors. Thanks to everyone who has taken time to reply.
Also will check on suggestions from the other contributors. Thanks to everyone who has taken time to reply.
fredericofonseca
IS-IT--Management
Being a DIGIBOARD you may also be able to use it's special capabilities of transparent printing if you are not using then already.
What is your DIGI model, how is it setup and how are the printers setup (devices, interface and others that mey help).
Regards
Frederico Fonseca
SysSoft Integrated Ltd
What is your DIGI model, how is it setup and how are the printers setup (devices, interface and others that mey help).
Regards
Frederico Fonseca
SysSoft Integrated Ltd
- Thread starter
- #10
It is now working!!!! I worked with Anzio - very nice people -, Kermit95, and DigiBoard, with no solution. The DigiBoard is XEM AccelePort PCI. The set up in the Digi software was ttya08, type = term, 19200, 8-1-N, software flow = xon/xoff, hwflow = none, fbaud=off. On the printer, pra08, type = term, term type = ansi, onstr & offstr = digi preset parameters for ansi. I did have the term type as WYSE 60, with no solution to the problem. I could probably switch back to to WYSE at this point. In the beginning, the printer model in Digi was "SCO standard" per their instructions. Both Anzio and Kermit95 would print one job to the printer and a subsequent job to the screen of the emulator, requiring a kill to continue use. I tried issuing various ditty commands per advice. The problem remained unchanged. Finally, on a whim, I changed the pra08 printer model to "SCO emulator," a very simple interface. That worked. I would like to understand what is configured in the standard interface that the printer liked when it was attached to a WYSE terminal, but didn't like when it was operating through a terminal emulator.
Much thanks to everyone who responded to this issue. Perhaps it will be of assistance to someone in the future.
Bill McClure
Much thanks to everyone who responded to this issue. Perhaps it will be of assistance to someone in the future.
Bill McClure
The printer on/printer off codes can be somewhat different in different emulations. An ANSI won't work with a Wyse termcap and the reverse also holds true. If you would scan termcap you will see what a wide variation there is.
You can see the actual codes in termcap, codes sent are under PN and PF if I recall.
The printer model used is independent of the printer turn on codes. It is sent before the file and print off is sent after the file.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
You can see the actual codes in termcap, codes sent are under PN and PF if I recall.
The printer model used is independent of the printer turn on codes. It is sent before the file and print off is sent after the file.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
- Thread starter
- #12
I'm afraid my prior remarks were not clear. When I was using the Wyse 60 emulation, I was using the WYSE termcap with the PN and PS. When I was using the ansi emulation I was using the ansi termcap with the correct PN and PS for ansi. This was checked and doubled checked. Which makes me believe it was in the codes sent by printer model, standard vs emulator.
OK. It sounded like you had crossed the signals.
To troubleshoot problems like this I throw a laptop in parallel with the receiving terminal and look at the hex dump actually coming in.
I've also modified the interface scripts to insert the appropriate codes rather than use the different multiport device. That allowed me to use the built in serial ports 1a and 2a in a passthru environment. But this was back in the Xenix days.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
To troubleshoot problems like this I throw a laptop in parallel with the receiving terminal and look at the hex dump actually coming in.
I've also modified the interface scripts to insert the appropriate codes rather than use the different multiport device. That allowed me to use the built in serial ports 1a and 2a in a passthru environment. But this was back in the Xenix days.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
Ok, I've been watching this thread with some interest.
I have been using terminal client printing for a couple of years now, so I am familiar with many of the problems involved.
I myself don't use the PN and PF codes in termcaps because I could never get them to work right. Instead I put the codes in the printer interface script where I have full control of what is actually being sent, and can make modifications as required for my terminal emulation software.
Most likely the reason why you are having problems is because you have moved from an actual terminal device to software that emulates a device on a PC. The thing to recognize is that most terminal emulation software is designed specifically for screen display, and does not support the more obscure terminal features. Your problem with the second job printing to the screen instead of the printer is caused by this incompatibility.
What you are trying to do in switching to a different printer on the terminal end depending on the type of job is not very common. There are very few terminal software packages that support this capability, and even the ones that do don't necessarily use the same commands to do it as work with a real terminal.
What you need to do first of all, is find terminal software that actually allows switching printers through its terminal command language, then create a printer interface script which sends these commands at the appropriate times for the emulation software.
See thread58-530596 and thread58-481117 for information regarding these kinds of interface scripts.
I have been using terminal client printing for a couple of years now, so I am familiar with many of the problems involved.
I myself don't use the PN and PF codes in termcaps because I could never get them to work right. Instead I put the codes in the printer interface script where I have full control of what is actually being sent, and can make modifications as required for my terminal emulation software.
Most likely the reason why you are having problems is because you have moved from an actual terminal device to software that emulates a device on a PC. The thing to recognize is that most terminal emulation software is designed specifically for screen display, and does not support the more obscure terminal features. Your problem with the second job printing to the screen instead of the printer is caused by this incompatibility.
What you are trying to do in switching to a different printer on the terminal end depending on the type of job is not very common. There are very few terminal software packages that support this capability, and even the ones that do don't necessarily use the same commands to do it as work with a real terminal.
What you need to do first of all, is find terminal software that actually allows switching printers through its terminal command language, then create a printer interface script which sends these commands at the appropriate times for the emulation software.
See thread58-530596 and thread58-481117 for information regarding these kinds of interface scripts.
i beleieve that now a days most of term emulators have passthrough printing.
i have used SecureCRT, PowerTerm and now Erics Telnet98. as eumlators' for SCO and i have ever faced any problem in local printingexcept onece when tlong kob was not printed. it was becsue of improper setup of printer in windows
however, i use only ANSI emulation as our ORACLE based application uses function keys and so to keep all terminals with same functin key with same meaning, we stick to ANSI.
ed fair coul u please tell me how u place the laptop in parallel to terminal ? it seems a great ide for such kind of trouble shooting
![[ponder]](/data/assets/smilies/ponder.gif "[ponder] [ponder]")
----------------
ur feedback is a very welcome desire
i have used SecureCRT, PowerTerm and now Erics Telnet98. as eumlators' for SCO and i have ever faced any problem in local printingexcept onece when tlong kob was not printed. it was becsue of improper setup of printer in windows
however, i use only ANSI emulation as our ORACLE based application uses function keys and so to keep all terminals with same functin key with same meaning, we stick to ANSI.
ed fair coul u please tell me how u place the laptop in parallel to terminal ? it seems a great ide for such kind of trouble shooting
----------------
ur feedback is a very welcome desire
Laptop in terminal mode for display. Serial port has 2 wires active on common and receive data and clips on the end. CTS/RTS jumpered, DTR/DSR jumpered. Any 232 signal that shows on the receive line ends up on the screen. Common jumper to 7, RD to 2 or 3, whichever is being monitored.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
Hi efair.
this is what i understand and what still not
pi2 or pin 3 of Terminal to pin 2 or 3 of Laptop
and Pin 5/7 of Termianl to pin 5/7 of laptop depending 9/25 pin connectors
----------------
ur feedback is a very welcome desire
this is what i understand and what still not
Code:
Server --------- Terianl ------ Laptop
RTS/CTS and DSR/DTR on laptop to be jumpered.pi2 or pin 3 of Terminal to pin 2 or 3 of Laptop
and Pin 5/7 of Termianl to pin 5/7 of laptop depending 9/25 pin connectors
----------------
ur feedback is a very welcome desire
Server-------T-------Client
|
|
Laptop
Laptop 3&7 (or 2/5) connect to common and either of the data lines depending on which way you are monitoring.
Handshaking is dummied on the laptop and baud rates must match what is passing on the line.
You would select a display all choice in the terminal emulation software on the laptop so you can see the control codes passing.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
|
|
Laptop
Laptop 3&7 (or 2/5) connect to common and either of the data lines depending on which way you are monitoring.
Handshaking is dummied on the laptop and baud rates must match what is passing on the line.
You would select a display all choice in the terminal emulation software on the laptop so you can see the control codes passing.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
Common is signal ground (7 or 5). I use either microhooks or alligator clips for the connection and to make it easy to connect I have several micropatch adapters that have jumpers installed for ease of connection. These are the 25p to 25s with solder pads for installation of jumpers for quick wiring mods. And I have 9/25 adapters available for both ends or the micropatch.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
Ed Fair
Give the wrong symptoms, get the wrong solutions.
- Status