jdw@hpfijdw.HP.COM (Jeff Wood) (02/06/90)
I am having trouble with the printer spooler using Xenix 2.3.3. When I send a request to the printer, everything works fine and the file is printed correctly. If I queue up more than one file, all files are sent to the printer at once, and the printer pukes. I am using a serial printer with a call to stty in the interface script as follows: stty ocrnl ixon ixoff clocal 0<&1 Communication seems to be ok for one file at a time, but sending more than one flushes all requests in the queue to the printer. I have tried several different serial printers, and it seems to do the same on all. Am I doing something wrong??? Jeff Wood jdw@hpfijdw.hp.com
pmb@sequim.UUCP (Peter Black) (02/06/90)
In article <15030007@hpfijdw.HP.COM>, jdw@hpfijdw.HP.COM (Jeff Wood) writes: > > I am having trouble with the printer spooler using Xenix 2.3.3. > > I am using a serial printer with a call to stty in the interface > > Am I doing something wrong??? > It is my impression that Xenix 2.3.3 means you've installed Upgrade A of VP/ix. I believe I had 2.3.1 before upgrading VP/ix. After the upgrade, hardware and software flow control no longer work right. I fixed the problem by slowing BAUD down to "at or below" the serial printer's maximum rated speed with stty in the interface script and switches in the serial printer. I have seen a system identical to mine running 2.3.1, without VP/ix, that has working flow control. I am considering junking VP/ix. Does anyone have Upgrade B? What about DOSmerge? Is it any different?
karl@ddsw1.MCS.COM (Karl Denninger) (02/07/90)
In article <15030007@hpfijdw.HP.COM> jdw@hpfijdw.HP.COM (Jeff Wood) writes: > >I am having trouble with the printer spooler using Xenix 2.3.3. >When I send a request to the printer, everything works fine and >the file is printed correctly. If I queue up more than one file, >all files are sent to the printer at once, and the printer pukes. > >I am using a serial printer with a call to stty in the interface >script as follows: > > stty ocrnl ixon ixoff clocal 0<&1 > >Communication seems to be ok for one file at a time, but sending >more than one flushes all requests in the queue to the printer. >I have tried several different serial printers, and it seems to >do the same on all. > >Am I doing something wrong??? Duplicate that line as the LAST line of the interface script, right before the "exit 0". The problem will disappear. The problem is that the spooler closes the port before your output drains, and most cards will discard "unused" output when that happens. The "stty" command causes the script to pause until the output has drained. You could also write a 5-10 line "C" program that waited for output to drain (with TCGETA/TCSETAW ioctls) and do the same thing, but the one-line command is simpler. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
jdw@hpfijdw.HP.COM (Jeff Wood) (02/08/90)
If anyone is interested in using smart serial boards and spooled serial printers, take note! I found out that as soon as the system receives xon signal from the printer, it will flush the port. When this happens, all requests that were previously in the queue are dumped to the port at the same time. To prevent this from happening, you must hold the port high. I accomplished this by adding this line to the file "/etc/rc.d/7/udaemons" while :;do sleep 3600;done < /dev/ttya5 & where /dev/ttya5 is the serial port in question. This command will loop forever and keep the port active. An explanation of this solution is in the latest issue of SCO Discovery magazine. Jeff (Sorry I answered my own question) Wood
karl@ddsw1.MCS.COM (Karl Denninger) (02/10/90)
In article <15030008@hpfijdw.HP.COM> jdw@hpfijdw.HP.COM (Jeff Wood) writes: > >If anyone is interested in using smart serial boards and spooled >serial printers, take note! I found out that as soon as the system >receives xon signal from the printer, it will flush the port. When >this happens, all requests that were previously in the queue are >dumped to the port at the same time. > >To prevent this from happening, you must hold the port high. >I accomplished this by adding this line to the file "/etc/rc.d/7/udaemons" > > while :;do sleep 3600;done < /dev/ttya5 & > >where /dev/ttya5 is the serial port in question. This command will >loop forever and keep the port active. An explanation of this solution >is in the latest issue of SCO Discovery magazine. You can also duplicate the "stty" command at the front of your interface script as the last line. This will have the same effect, and is much cleaner (no leaving processes around). We do this with good results under both SCO Xenix and ISC Unix. The problem is that the port actually is cleared to defaults when closed, and apparently the close does not wait for output to drain (boo hiss!). The scheduler, getting control back after the file has been buffered in the smart I/O board, closes the port! Thus, you have the problem. The "stty" apparently does a "TCSETAW" call to set parameters, and thus does wait for output to drain. With a properly designed serial driver, smart or dumb, this works great. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"