Title: | Terminal Servers |
Notice: | See Note 2 for Directory of important notes. Please use keywords. |
Moderator: | LAVC::CAHILL ON |
Created: | Tue May 14 1991 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 3547 |
Total number of notes: | 12300 |
Hi I've some printing problems that I'm experiencing that I just cannot easily isolate. They seem flow control-ish but i've open mind as to what the cause and fix is. The printers are connected to DS90TL, and are serviced by a Digital UNIX LAT connection.(DS900TM controlled printers appear to also have this problem) The printers are set up to do DTR flow control (and some have both XON/Xoff and DTR) - and the DS90TL is set up for DSR/DTR flow control and signal control disabled. in addition the port is set to output flow control enabled (and input curiously). In standard operation the files are put on the queue that then puts to the terminal server. The terminal server port lights up and then the terminal server sends to the printer. If the printer buffer is too full then it "flow controls off" the terminal server port until such time as the printer can cope again and "flow controls on" the TS port. This "seems" to work a treat - particularly from our testing in house it doesn't fail. However, we still have problems. The printers are appearing as offline on the UNIX sytem as so no data is sent to the TS. It is presumably possible that while the ts port is "flowed off" that data is still being sent from Digital UNIX across the LAN. Presumably possible also that there is a limited size buffer in the TS so this would have to "flow control off" and later "on" the data flow from the UNIX system across the lan (and this could happen even if the TS port wasn't "output flow control offed"). What if any flow control mechanisms exists here between the TS and the Digital UNIX and its print queues? (sorry if this is a really dumb question) The problem here occurred on a printer with both xon/xoff and dtr flow set and also a dtr only printer - where the print queues were set to recognise xon/xoff flow control. Normally it all just works fine, but sometimes (once here) and MANY MANY times on customer site the queues just say printer offline. And they're not offline. And no lights appear on the TS ports.. help! any ideas? there are no "known" bugs with the LAT, line printer daemons or anything else related on UNIX... regards Gary
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
3444.1 | IROCZ::D_NELSON | Dave Nelson LKG1-3/A11 226-5358 | Thu Feb 20 1997 09:41 | 12 | |
RE: .0 > What if any flow control mechanisms exists here between the TS and the > Digital UNIX and its print queues? (sorry if this is a really dumb > question) For LAT connetions, this is accomplished by the exchange of LAT "credits". Regards, Dave | |||||
3444.2 | monitorable? | CHEFS::KERRISON_G | Let the skunk drink the Martini! | Thu Feb 20 1997 09:54 | 18 |
re: -1 Aha. are these "credits" monitorable? tunable? configurable? on both the TS and on Digital UNIX? Can I see if one end is waiting for a credit? If LAt on UNIX is waiting for a wake-up credit from the TS, can I determine whether the TS should have issued one (buffer below n% full) ? Can I force the TS to issue a credit? So in this scenario the LAT and not the print queues is stalled - which in turn stalls the data flow from printer queue to LAT...? Gary | |||||
3444.3 | A LAN trace might help | IROCZ::RRICHARD | Thu Feb 20 1997 12:24 | 16 | |
Hi, The credits are not tuneable from the TS side. I don't know about the UNIX end. There's no command to monitor credits or buffer usage on TS or to determine if the TS is waiting for credits. You could use a LAN analyzer such as IRIS or a Data General Sniffer to monitor the credit exchange on the net. It would take some time and effort to walk through the trace and account for all the credits. Have you used the SHOW PORT n STATUS command to verify that it's not a simple matter of the port being XOFF'd? bob richard |