OK you guru's out there, I have one for you!!!! :^)

Platform is D3 Linux 7.4.2

Problem: When spooling hold files to a particular shared printer, the
printer prints part of the job in question, then stops. I can stop it
& restart it a thousand times, & it will stop every time in EXACTLY THE
SAME SPOT!!!! I have converted several of these "problem" hold files
into text files, viewed them with a hex editor, & found...NOTHING at
the spot the jobs stop at. Or at least, nothing unexpected. So, I
kinda "forgot" about the problem. Until it reared its ugly head again
today. This time, I decided it might be something hosed with the port
the printer gets started on. So, I restarted it on a different port,
re-printed the job, & NOW it stops at a DIFFERENT spot!!!! But here's
the kicker: I can spool that same job to a different printer, & it
prints FINE!!!!! And yes, I've tried turning the offending printer off
& back on numerous times. It doesn't matter what you do to the darn
thing.

Sooooooooooooooooooooooooooooooooooo, does ANYONE have any suggestions
for what could be causing this problem?? It's a REAL pain when it
involves a check print job!!!!!

Thanks in advance,

Mark Wright
Eastex Crude Compamy

P.S. All the shared printers in question are HP's, & connected via
parallel port directly to a PC running Windows XP Pro. The one that
has the "problem" is a 5Si, the others are HP 4's.

"mwright" wrote
printed did not make it to the parallel port unmolested. The leading
suspects are
a) windows printer driver,
b) the lpr/lpd backend of Redhat rhel3 cups printer subsystem,
or the smbprint backend if you're using Windows' optional
unix print services
or c) the d3 printer interface

Trap your print data into intermediate files on the linux
box and the windows box. On the linux box do
(tee /tmp/foo | lpr -Pmyprinter) in place of just ( lpr -Pmyprinter)
in your STARTSHP command.

On the windows box employ the 'print to file' choice to trap the data.

Now you can do a variety of reprint tests using the trapped data files
and bypassing a) or b) above. Think Binary FTP sessions and
DOS COPY C:\FOO.PRN LPT1: commands.

If a) turns out to be the culprit, see if you can improve the settings by
lying and telling windows this is a Generic/Text only printer, instead of
an HP 5si -- remember that d3 graciously adds carriage returns to each
line of print, so you really just need XP to send the raw data to the parport.

If b) turns out to be the culprit, you could perhaps get an updated cups
subsystem from redhat, or download and compile latest cups from the
cups web site, or rip out cups and install LPRng from a
Redhat 9 cd set.
{Leave cups-libraries installed though, since samba relies on it for the
part that handles the inbound-to-redhat printer jobs feature -- which will
no longer work, but you may not use that feature anyway}
{The cups uninstall scripts don't rip out the man pages, so later on
rename or delete them yourself to let the LPRng pages show up.
{Other things you might enjoy loading from older redhats are
mc [midnight commander, very nice for looking inside rpm and tar files],
vsftpd [very secure ftp demon]
lynx [text-based web browser]
fortune [fortune cookie humor -- but wasn't on RH9 cd's either] }

Since it works ok on some printers, c) is probably not the culprit, but if
it is you can adjust several things to work around it. Don't waste time
on this until you've ruled out a) and b).

I'l hazard a guess this only fails on multipage print jobs,
say over 5 or 7 pages... That would make b) the likeliest villain.

Frank,

Thanks for the tips. I'll definitely give them a shot & let you know
what I find out.

As to your multi-page question, they ARE multi-page reports, but
strangely enough, it's ALWAYS a small job that fails, say 2-5 pages.
Our HUGE jobs seem to work just fine!!!

MW

Frank Winans wrote:

This sounds like a problem first uncovered in RT-OA over 10 years ago.....

See if this fits:
PICK print jobs go via frames; thus a job will consume anywhere between 1 &
n frames. Unless the job happens to fit exactly into n frames (it won't);
from the end of the job to the end of the final frame, the frame is filled
with nulls. So any print job will have anywhere between 0 and <framesize -
1> trailing nulls. When this is printed; all the job's frames are sent out;
therefore the printer ends up
"seeing" a whole mess of nulls, which it SHOULD discard.

We had printers misbehave much like you describe and found that the serial
i/f buffer would spit the dummy when more than a certain number of nulls
were received in a row. This is because a null is potentially part of a
printer Escape sequence; and so the i/f hardware is looking to the next byte
to see if it is part of a valid escape sequence. If the next byte is null
also, this process repeats and if the string of nulls is long enough it
craps itself. Causing the printer to just stop. Given the flow control of a
printer the i/f is way ahead of the physical print so the event that causes
the printer to stop is ahead of the actual physical print. What I mean is
that the problem is not with the data being printed at the time, but the
data being received.

Our solution back then was to manufacture inline null strippers; however
since you are on Linux, some guru here should be able to write a print
driver that is (say) 4 nulls appear in a row, dump them to drain; else feed
it out. Or you could try a bigger serial i/f buffer.

Different printers will behave differently depending upon capacity of the
i/f buffer, i/f firmware versions. Oh, and parallel ports do not have this
problem!!!

See if that's the issue for you....

Good luck

David Knight

"mwright" <wright.mark (AT) gmail (DOT) com> wrote

David,

It sounds like you could be right about our printer problem, but I have
one comment to make first!!!

This problem DOES happen on a parallel printer. It is a shared
D3/Linux printer started via startshp. The printer is connected to a
Windows XP Pro machine via parallel cable. I'm not sure if this shoots
down your theory, or not, since linux treats all printers like they are
serial devices, or at least I THINK it does!!!

I just ran into the problem again today for the first time since your
response. This job was 3 pages long, & stopped at the end of the first
page.

MW

David Knight wrote:

Mark,
Well it does throw a spanner in the basic theory because our experience was
that it involved the serial interface's inability to handle and buffer an
excessive stream of nulls in a row. Having said that, parallel ports also
buffer; but presumably in our case the firmware was different and so for
some reason it handled it better. Given that frame sizes have increased
markedly since when this first surfaced on the RT-OA [at that time R83 had
512 frames & the RT 2024] I guess it could be happening with parallel
printers.

We proved the problem with a simple non-PICK application which simulated the
problem by creating a text print job of reasonable size, followed by 'x'
nulls. The program prompted for however many nulls we wanted. Set this up on
a [Dos if I recall] PC with the test printer attached; and found in our case
the magic number was up around 800 nulls or so would cause the printer to
totally have a nervous breakdown. 1 less null; and it would print ok.

I'm sure you have the resources to perform a similar test. I recommend Dos
because you can talk directly to to the port, not through a Windows or other
driver.

In your case you have two further areas that could be stuffing up in a
similar fashion: Linux [unlikely] or the XP printer driver which has to
"process" escape sequences as well. Have you tried swapping XP drivers for
another more generic one? Have you tried RAW setting?

Given that the nulls are useless anyway, why don't you filter them out via
the Linux driver? I have not played with Unix for a real loooong time, but
there used to be scripts that process the data print stream that were easily
editable. I presume Linux does the same? If so, modify it so that everytime
there is a sequence of (say) 5 consecutive nulls; dump 'em; else feed the
bytes out. Just see what happens.

Alternatively, if you were very brave, hack the frames containing the print
job & make it one real character longer and send it to the printer again.

Personally I'd try the Linux print script thing if it exists.

Good luck

David

"mwright" <wright.mark (AT) gmail (DOT) com> wrote

I ran into the nulls problem years ago on a shared printer on an AP/SCO
system. The fix was to pipe the print job through the unix 'tr'
(translate) command, removing the null characters. It was done in the
startshp command like this (thanks to Rick Davies @ RD):

startshp 4,4,1,s194,lp.unix,(tr -d '\000' | lp -d hp8150n -onobanner)
(s

That said, I'm not sure this is the cause of your problem, as my
understanding is that sometime after the swtch from AP to D3 the habit
of padding the spooler frames with nulls was kicked? Besides, wouldn't
this only affect the LAST frame of the print job? (not the middle...)
Anyway, worth a try!

Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Hi Scott,
I do not know if spooler frames are still padded or not. I know that the
print jobs themselves is now a file that can be manipulated like any other,
hinting that print jobs have a start and finish delimiter like any other
item; but who knows what happens when it actually shoves it out the door...
perhaps it goes through another set of frames?

Anyway, to answer your question about it affecting the last page, the answer
is NO because of buffering. In our experience the physical symptom occured
when the interface fell over trying to buffer & figure out what the escape
sequence of nulls is supposed to be; causing whatever was printing at that
time to snafu. The buffer is always waaay ahead of what is actually
printing, possibly even a number of full pages. So, the interface could be
on the "last" page so to speak, yet the physical output could be pages
behind.

Interesting that your method of fixing was essentially the same: strip the
nulls. If this can be done in Linux, then you are laughing...

HTH

David

"Scott Ballinger" <scott.ballinger (AT) gmail (DOT) com> wrote

Scott,

With a few mods, your startshp line did the trick!!!!!!!!!!!!!! I owe
you BIG TIME!!!! :^)

Thanks a bunch. Next time I'm out your way, I'm buying dinner, OK???

MW

Scott Ballinger wrote:

Hi David,

When we encountered this problem (like, 5 years ago? when did HP start
shipping the 8150?), it was specific to a new HP 8150 jet-direct
connected printer. There were many printers (parallel, serial, and
network) on the system, but only this one seemed to have the "nulls
problem." Maybe the problem is more printer-related than
interface-related? Interestingly, that same printer does not exibit
this problem since switching from SCO to Linux. Go figure. (lp vs
lpr?)

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006