Print Job Stuck in Queue, Must Reboot Server
Jay Chan
stuck in a print queue. I need to reboot the computer in order to
force the print job to start printing. I am wondering whether there
is anything we can do to prevent this from happening.
Some Facts:
- The operating system is SCO OpenServer Release 5.
- The computer is a Pentium-II PC.
- The printer is an Okidata dot-matrix printer that is connected to
the PC using a long serial cable.
- Print jobs are plots that have things like lines/circles,
rectangles. Print job files contain many binary info that I don't
know how to read.
- I cannot find a pattern of print-jobs that got stuck and print-jobs
that went OK. The problem seems to occur randomly in an
once-every-4-print-jobs ratio.
- Another server that runs the exact same programs and operating
system also has this problem. But in a much lower frequency (like
once every two weeks).
I choose to reboot the computer instead of canceling the print job for
the following reasons:
1. I don't know how to remove a print job.
2. Even if I know how to cancel it, I will prefer not to do so
because I will have to re-print the print job if I cancel it (not that
easy to do because the print job is generated from an application
program), and I am afraid that re-printing it will have it getting
stuck again. Rebooting the computer is easier.
I am wondering whether there is a way to fix this problem.
Thanks in advance for any info on this problem.
Jay Chan
Tony Lawrence
First:
You can run /usr/lib/lpshut and /usr/lib/lpsched. Print jobs will restart.
Second:
Print files are in /usr/spool/lp/temp
See http://pcunix.com/SCOFAQ/scotec7.html for general info about
printers etc.
Third:
It sounds like you are having problems with the printer and or the
serial line and it may be wiring, flow control or who knows. Articles
like http://pcunix.com/Unixart/printers.html may get you started.
>
> I am wondering whether there is a way to fix this problem.
>
> Thanks in advance for any info on this problem.
>
> Jay Chan
--
Please note new phone number: (781) 784-7547
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Free Unix/Linux Consultants list: http://pcunix.com/consultants.html
Jeff Liebermann
>- The printer is an Okidata dot-matrix printer that is connected to
>the PC using a long serial cable.
I'm always impressed when someone can write a detailed trouble report
without using a single number. You'll get better results if you
supply exact model numbers, version numbers, and cable lengths.
How long is a "long serial cable" and what kind of cable?
Is the cable shielded (i.e. lots of capacitance to ground)?
What speed are you running the printer?
What model Okidata?
Built in serial interface or external adapter?
Hardware flow control or xon/xoff (or both)?
Are you using the servers "standard" serial port or some intelligent
serial card? If intelligent, are you using any 3rd party drivers?
It's almost certainly some kind of flow control or handshake problem,
but without details, it's hard to tell from here. You should be able
to run:
lpstat -t
to get a list of print jobs, followed by:
cancel job-id
to kill the print job.
For how to setup serial printing, see:
http://www.cruzio.com/~jeffl/sco/serial_print.txt
http://pcunix.com/Unixart/printers.html
http://www.pcunix.com/Unixart/serial.art.html
http://www.cruzio.com/~jeffl/sco/flowcontrol.txt
I would recommend hardware flow control for long cable runs. It's
also easier to check with a serial test box ($10 at Radio Shock), and
doesn't make a mess when trying to print while the printer is offline
or turned off.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jay Chan
> You can run /usr/lib/lpshut and /usr/lib/lpsched. Print jobs will restart.
First for the info on those two commands, I will try them as a
stop-gap solution before I find a permanent fix to this problem.
> See http://pcunix.com/SCOFAQ/scotec7.html for general info about printers etc.
> http://pcunix.com/Unixart/printers.html may get you started.
Thanks for the pointers to those two articles. I will print them and
read them carefully.
Thanks again.
Jay Chan
Jay Chan
> How long is a "long serial cable" and what kind of cable?
> Is the cable shielded (i.e. lots of capacitance to ground)?
> What speed are you running the printer?
> What model Okidata?
> Built in serial interface or external adapter?
> Hardware flow control or xon/xoff (or both)?
> Are you using the servers "standard" serial port or some intelligent
> serial card? If intelligent, are you using any 3rd party drivers?
- The model number of the Okidata printer is GE7000A.
- It is connected to a serial card in the Unix box through a 100-ft
cable. The serial card is called Arnet digi board.
- We are running the serial connection in 9600 baud rate with
XON/XOFF flow control, no-parity, 8-data-bits.
The length of the cable probably is not the cause of this problem
because the cable in the other printer that has fewer problem is much
longer than the one that has problem (250 ft vs. 100 ft).
After saying this I must add that I have just discovered that the
cable in the printer that is causing problem is different from the
cable of the printer that is working mostly fine. Instead of a
standard serial cable, we use a CAT-5 network cable and make it to
serve as a serial cable. I am wondering whether this is the source of
the problem.
> cancel job-id to kill the print job.
Thanks for the command to kill a print job that gets stuck.
> I would recommend hardware flow control for long cable runs. It's
> also easier to check with a serial test box ($10 at Radio Shock), and
> doesn't make a mess when trying to print while the printer is offline
> or turned off.
This seems to be a way to reduce the problem.
Thanks.
Jay Chan
Tony Lawrence
> Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<std3qu0vnbs5lrcvq...@4ax.com>...
>
>
>>How long is a "long serial cable" and what kind of cable?
>>Is the cable shielded (i.e. lots of capacitance to ground)?
>>What speed are you running the printer?
>>What model Okidata?
>>Built in serial interface or external adapter?
>>Hardware flow control or xon/xoff (or both)?
>>Are you using the servers "standard" serial port or some intelligent
>>serial card? If intelligent, are you using any 3rd party drivers?
>
>
> - The model number of the Okidata printer is GE7000A.
> - It is connected to a serial card in the Unix box through a 100-ft
> cable. The serial card is called Arnet digi board.
> - We are running the serial connection in 9600 baud rate with
> XON/XOFF flow control, no-parity, 8-data-bits.
>
> The length of the cable probably is not the cause of this problem
> because the cable in the other printer that has fewer problem is much
> longer than the one that has problem (250 ft vs. 100 ft).
Maybe- but 100 feet *can* a long way for weak serial hardware, and Arnet
is definitely old..the other printer may have a better card, or the
cables themselves may be different (you said below that they are). For
good serial equipment/wiring 9600 at 100 feet should be fine, but who
says it's all good?
As the printer probably can't even come close to printing 960 cps
(somebody will surely point out that my math is only an approximation
but that's just nit-picking- divide baud by 10 is close enough), you
might also just drop the baud (of course at the Arnet and the printer).
Even 2400 is probably much faster than the thing can actually print,
so you don't lose anything and it might help.
HW flow control is a better idea too..
Rainer Zocholl
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message
>news:<std3qu0vnbs5lrcvq...@4ax.com>...
>> How long is a "long serial cable" and what kind of cable?
>> Is the cable shielded (i.e. lots of capacitance to ground)?
>> What speed are you running the printer?
>> What model Okidata?
>> Built in serial interface or external adapter?
>> Hardware flow control or xon/xoff (or both)?
>> Are you using the servers "standard" serial port or some intelligent
>> serial card? If intelligent, are you using any 3rd party drivers?
>- The model number of the Okidata printer is GE7000A.
>- It is connected to a serial card in the Unix box through a 100-ft
>cable. The serial card is called Arnet digi board.
>- We are running the serial connection in 9600 baud rate with
>XON/XOFF flow control, no-parity, 8-data-bits.
Are you printing plain ASCI text or somekind on graphics?
(pfd's etc.)
If plain ACSI (too):
Did your users ever complain about characters being printed false?
If there is only one single complaint, the Serial Board
is not able to drive the cable or you have ground loop problems.
Or something on the way of the cable influences it.
But you wrote:
> - Print jobs are plots that have things like lines/circles,
> rectangles. Print job files contain many binary info that I don't
> know how to read.
So you have lots of data to transfer and one single false
bit in the can hang the printer.
In this cases a "serial tracer" would be valuable to see
what's was going wrong. (There are "software" solutions using 2 serial
ports).
The mentioned shack plug box may help to see if is the
printer, if you used hardware handshake. But you use only
software handshake.
The disadvantage of software HS: If only one single XON is lost,
the printing stops forever.
Advantage: You only need 3 wires.
>The length of the cable probably is not the cause of this problem
>because the cable in the other printer that has fewer problem is much
>longer than the one that has problem (250 ft vs. 100 ft).
Wow. Wider Aera Network with serial cables? ;-)
Do i calculate right:
Almost 75 meters with a normal V.24 serial wire?
No opto couplers to isolate the ends plain copper?
Surpring that you get mostly correct printings.
(Today a dedicated ethernet printer spooler would be used).
>After saying this I must add that I have just discovered that the
>cable in the printer that is causing problem is different from the
>cable of the printer that is working mostly fine. Instead of a
>standard serial cable, we use a CAT-5 network cable and make it to
>serve as a serial cable. I am wondering whether this is the source of
>the problem.
As long as you NEVER see a single character printed false
you are a real lucky guy.
But with so long signal cable you get "ground loops" causing
any kind problems.
>> cancel job-id to kill the print job.
>Thanks for the command to kill a print job that gets stuck.
Maybe the fault is caused by escape sequences in that
print job?
Does it print clean if your reschedule it or schedule a copy of it?
Jeff Liebermann
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<std3qu0vnbs5lrcvq...@4ax.com>...
>
>> How long is a "long serial cable" and what kind of cable?
>> Is the cable shielded (i.e. lots of capacitance to ground)?
>> What speed are you running the printer?
>> What model Okidata?
>> Built in serial interface or external adapter?
>> Hardware flow control or xon/xoff (or both)?
>> Are you using the servers "standard" serial port or some intelligent
>> serial card? If intelligent, are you using any 3rd party drivers?
>
>- The model number of the Okidata printer is GE7000A.
The GE7000A is an Okidata 320A with a serial card. Programming the
serial card is a bit trick. Since you have others that work, I
suggest you dump the printer settings, using the front panel menu, on
each printer and compare. My guess(tm) is that they're different.
>- It is connected to a serial card in the Unix box through a 100-ft
>cable.
100ft of serial cable is not long at 9600 baud is you use unshielded
cable. 100ft of shielded cable is long. I would reduce the baud rate
to 2400.
> The serial card is called Arnet digi board.
That's fairly old if it says Arnet on the box. Some Arnet interface
boxes required setting a zillion jumpers on the bottom of the box.
Unfortunately, the jumpers tended to fall out after a while. Shake
the black box. If it rattles, you found the problem. Otherwise,
check the settings.
>- We are running the serial connection in 9600 baud rate with
>XON/XOFF flow control, no-parity, 8-data-bits.
You don't need 9600 baud. The printer might run 180 chars per second
on a good day. 2400 baud is good enough and will eliminate a
substantial number of xon/xoff cycles. If you have the ability to
switch to hardware flow control, I would suggest that as a better
option.
>The length of the cable probably is not the cause of this problem
>because the cable in the other printer that has fewer problem is much
>longer than the one that has problem (250 ft vs. 100 ft).
Please see my list of questions at the beginning of my response that
you have only partially answered. Is this cable shielded?
>After saying this I must add that I have just discovered that the
>cable in the printer that is causing problem is different from the
>cable of the printer that is working mostly fine. Instead of a
>standard serial cable, we use a CAT-5 network cable and make it to
>serve as a serial cable. I am wondering whether this is the source of
>the problem.
No. I use CAT5 for everything. However, you have to be careful in
selecting which wire to use for what purpose. If you selected a
twisted pair to act as RX and TX lines, you will get the worst case
crosstalk with a general loss in reliability. Out of 8 wires, I
suggest you pick one of a pair for RX, one out of another pair for TX,
and ground the unused wires from the RX and TX pairs for the signal
ground. Do NOT wire the common "protective" ground (pin 1) as you
will probably end up with a ground loop full of AC 60Hz crud.
Good luck. By comparing the working and non working printers, this
should be a fairly easy repair.
Dan Martin
> On 8 Oct 2002 11:38:02 -0700, jayk...@hotmail.com (Jay Chan) wrote:
>
> >Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<std3qu0vnbs5lrcvq...@4ax.com>...
.
.
> No. I use CAT5 for everything. However, you have to be careful in
> selecting which wire to use for what purpose. If you selected a
> twisted pair to act as RX and TX lines, you will get the worst case
> crosstalk with a general loss in reliability. Out of 8 wires, I
> suggest you pick one of a pair for RX, one out of another pair for TX,
> and ground the unused wires from the RX and TX pairs for the signal
> ground. Do NOT wire the common "protective" ground (pin 1) as you
> will probably end up with a ground loop full of AC 60Hz crud.
>
.
.
Yikes! I've always gone out of my way, when using cat5 in a serial
application, to be sure that Rx and Tx were on the same twisted pair.
This is true of cat 5 network cable, is it not? pins 3 & 6, tx/rx,
usually green/white-green. No?
I assumed that a signal on Blue would not adversely affect the
White-Blue wire
since they are twisted. (Blue/White-Blue being 4 and 5 on the rj45;
the center pins being rx and tx for rs-232?)
I think I'm right. But if so, it will be the first time I've seen
that
Jeff is wrong!
Best to all,
Dan
Jeff Liebermann
wrote:
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<ce18qu4s9s9r1197p...@4ax.com>...
>> On 8 Oct 2002 11:38:02 -0700, jayk...@hotmail.com (Jay Chan) wrote:
>> >Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<std3qu0vnbs5lrcvq...@4ax.com>...
>> No. I use CAT5 for everything. However, you have to be careful in
>> selecting which wire to use for what purpose. If you selected a
>> twisted pair to act as RX and TX lines, you will get the worst case
>> crosstalk with a general loss in reliability. Out of 8 wires, I
>> suggest you pick one of a pair for RX, one out of another pair for TX,
>> and ground the unused wires from the RX and TX pairs for the signal
>> ground. Do NOT wire the common "protective" ground (pin 1) as you
>> will probably end up with a ground loop full of AC 60Hz crud.
>Yikes! I've always gone out of my way, when using cat5 in a serial
>application, to be sure that Rx and Tx were on the same twisted pair.
>This is true of cat 5 network cable, is it not? pins 3 & 6, tx/rx,
>usually green/white-green. No?
Well, there's no real standard for RJ-45 serial connections. I tended
to use whatever Digiboard used for their RJ-45 to RS-232 adapters on
their C-Con/16 concentrators.
>I assumed that a signal on Blue would not adversely affect the
>White-Blue wire
>since they are twisted. (Blue/White-Blue being 4 and 5 on the rj45;
>the center pins being rx and tx for rs-232?)
>
>I think I'm right. But if so, it will be the first time I've seen
>that Jeff is wrong!
Well, I've been wrong more times than I care to admit. That's what
Learn by Destroying is all about.
In this case, the problem is one of load capacitance versus crosstalk.
CAT5 is 15PF per foot for the twisted pair. There's no spec for the
capacitance between pairs, but my capacitance meter measures about
4-7PF per foot. If you used seperate pairs for TX and RX, with the
matching pair as a signal ground, 100ft of cable will yield 1500PF of
load capacitance. That's right at the bitter edge of non-functional
for the typical 1488 and 1489 transceiver pair at 38400. However, it
will work at 9600 and not be any problem at 2400.
However, if you connect a 1500PF capacitor between the TX and RX lines
on the same serial port pair, you're going to have considerable
crosstalk. If your driver is half-duplex and turns off the receiver
while transmitting, there's no problem. That worked well for me until
I ran into a system that had a full duplex serial port on a data
collector. What I got was data plus garbage until I broke the TX and
RX lines apart into seperate pairs. I also suspected that crosstalk
was the cause of some rather weird problems with some terminals I had
to deal with. However, I haven't seen a serial terminal in several
years.
In my never humble opinion, crosstalk is a potentially bigger problem
than line length. With xon/xoff, only 3 out of the 8 wires are
needed. Therefore, you could use 1 wire from each of 3ea seperate
pairs, to do the job. That would be the minimum load and crosstalk
capacitance solution.
However, I like to use hardware flow control for everything. That
requires a total of 5 wires out of 8 in the cable. The two flow
control wires could be paired with the signal grounds, and leave the
TX and RX pairs with the corresponding twisted pair wire unconnected.
I wish I could say that I did like that, but I didn't think of it at
the time.
None of the above makes much difference with slow speeds (2400 baud)
or short cable lengths (< 25ft). However, as the speeds increase, and
cables get longer, crosstalk and load capacitance become problems.
Dan Martin
D'0h!
No surprise here--Jeff is right and I am wrong!
And before reading Jeff's post I had a look at the cat 5 spec. 4/5
isn't
tx/rx it's rcv+/rcv- (or vice versa).
I'm remindend of Abraham Lincoln: "It is better to remain silent and
be
thought a fool than to open one's mouth and remove all doubt." How
embarrassing to think that the Great Emancipator was anticipating me!
Best to all,
Dan
Jay Chan
to carefully digest. I probably only know 25% of what is being
discussed. I will print all the messages out and give it to my
hardware guy who likes to work with cable.
Thanks a lot!
Jay Chan
Bill Vermillion
Dan Martin <dcma...@affinitycorp.com> wrote:
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<ce18qu4s9s9r1197p...@4ax.com>...
>> On 8 Oct 2002 11:38:02 -0700, jayk...@hotmail.com (Jay Chan) wrote:
>> >Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<std3qu0vnbs5lrcvq...@4ax.com>...
>> No. I use CAT5 for everything. However, you have to be careful in
>> selecting which wire to use for what purpose. If you selected a
>> twisted pair to act as RX and TX lines, you will get the worst case
>> crosstalk with a general loss in reliability. Out of 8 wires, I
>> suggest you pick one of a pair for RX, one out of another pair for TX,
>> and ground the unused wires from the RX and TX pairs for the signal
>> ground. Do NOT wire the common "protective" ground (pin 1) as you
>> will probably end up with a ground loop full of AC 60Hz crud.
>Yikes! I've always gone out of my way, when using cat5 in a serial
>application, to be sure that Rx and Tx were on the same twisted pair.
>This is true of cat 5 network cable, is it not? pins 3 & 6, tx/rx,
>usually green/white-green. No?
In addition to what Jeff has said let me mention this.
Twisted pair is mostly used in balanced line configuration - eg
there is a positive and negative wire. RS232 does NOT used this
method. There is one wire for each signal and a common return
ground for all signals.
>I assumed that a signal on Blue would not adversely affect the
>White-Blue wire since they are twisted. (Blue/White-Blue being 4
>and 5 on the rj45; the center pins being rx and tx for rs-232?)
In a balanced line that assumption is correct - in single line
no. You could cause more interference on twisted with different
signals than you might with straight parallel wires
Twisted pairs are used to reject common mode [EMF] signals. These
are low frequency signals typically induced by power lines, etc.
The twist means that outside inteference will be the same for both
sides of the line and cancel itself out.
The other side of the wiring world is shielded. That reject the
high-frequency components.
--
Bill Vermillion - bv @ wjv . com