Printer not recieving full report, file size cap?

[ColumbiaIT]

Howdy folks
we are running a mixed SCO/NT environment.
SCO is R5 enterprise running on a compaq proliant 1800.
Not running X.
Inherited system, users connect to system/application via Tiny term.

My problem exists with a line printer that we use to print reports to is not getting the full report. (lexmark 4557 aka P6). the report gets half printed then stops. mid line I might add.

Normally P1, another line printer outputs this file with out problems.

Looked at a copy of the data from the p6 queue and found that the data present DID in fact represent what was printed, down to the mid line.

This leads me to believe that there is a cap on printing on p6...file sizes of an x amount get truncated then sent to print. where would this memory cap variable be stored? what would the syntax be? excess data is discarded?

I looked at things like the printcap and the lpd, looked through scoadmin printers and and a couple of other shells but I must admit I am still new to SCO. life would be better with GUI, but it has been declared as to much overhead, and hey thats ..o..k.

Also if anyone can recommend agood printer cmd line tool for printing. very bonus

any and all input would be appreciated

Thanks
SSS

sspellac@columbiafuels.com
who's keeping you warm?

 

[pcunix]

The "cap" in printcap would stop ANY output to the printer, not cut it half way (but for future refrence, adding "mx#0" eliminates the restriction)

Are these serial printers? If so, you have a flow control problem. See

http://pcunix.com/Unixart/printers.html

You could also have hardware problems on the specific port; you might try switching them..

It would be POSSIBLE (thought unlikely) for someone to butcher an interface script to deliberately only send so many bytes, but I really doubt it.

So- more information needed if not serial. "lpstat -v" tells you what the printers are connected to. Share that with us, and if it says "/dev/null", explain exactly what sort of network printers these are.
Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[ColumbiaIT]

Tony thanks again.

Good point
P1 is parallel direct connection to the Sco box
p6 is serial via a print server on the network

lpstat -v gives me:

device for p1: /dev/lp0
device for p6: /dev/null

user error took the job to p6 but it got me thinking

SSS

 

[pcunix]

Unless the print server is broken, chance are it's flow control.

One of printer or print server isn't set the same as the other, or they are both set for hardware and it isn't wired right.

Or the serial port (either place) is defective.

Is this an OKI? The hardware handshake wiring is weird for these..

http://pcunix.com/Unixart/rs232diagram.html

Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[ColumbiaIT]

Thanks for the links.
reading...

coming to think of it.
Both printers are parallel, sorry my mistake
P1 is attached to the sco Box
p6 connected to the server via IP to parallel print server

investigating the flow control side of life right now

SSS

 

[pcunix]

No, if it's parallel, there's no flow control to be set (there is of course flow control, but nothing you control).

Cable, print server, printer itself.. shift things around to find out what.
Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[ColumbiaIT]

tony

Thanks for your help.
yeah thought of that as soon as I hit post.

Thinking it is the print server that is the issue perhaps
the original lexmark2000x (2meg buffer 2meg flash).

was replaced with a linksys printserver (128k buffer).

but even still I would think that SCO would be able to do that.

Cables are new Bi directional.

but now I am planning to take the rest of the day off. printers have been playing with my head all week.


Thanks again

SSS

 

[Megabitman]

As a side note to Tony, Oki handshakes can be just four-wire (send, receive, ground, dtr - even dtr is optional); then set the oki protocol to x-on/x-off, set DSR invalid, set baud to 9600 and life is good. As you well know, the only other real caveat is printing directly at the printer versus spooled output. I personally am not a fan of anything Linksys as my DOA rate out of the box is really poor (including the print servers). I would suggest hp jetdirects, D-Links, or get a lexmark and use port 9100.

 

[ColumbiaIT]

mBm

Thanks for the side. Yea I appreciate the linksys debacle. If lexmark were not twice the price my pointy hair managment might go for it.
I have yet to try out a d-link.

When you say printing out directly to the printer rather than spooling being a caveat, What exactly do you mean. bit of a green Unix user. wouls printing directly to the printer chop half a doc if it overwhelmed the print server?
If so then were would I set the config to spool the printer?

All input appreciated

SSS

 

[pcunix]

The articles I had referred him to above do cover 4 wire OKI setup.

As to print servers, I have had good luck with Netgear.

I have no idea what ColumbiaT is asking above.. Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[Megabitman]

Sorry for the delay in responding, To Tony: I use netgear for my DSL routers and have been extremely satisfied with the quality and performance; I've never used their print servers but based on your recommendation, I may give 'em a shot. To SSS: printing directly at the printer would be via a serial or parallel connection passed directly to the port (bypassing the spooler). Some applications prefer to bypass the spooler for an assortment of reasons (ie forms, user sophistication in troubleshooting the spooler, etc). And yes, printing directly at a serial port could cut a document off early if the protocol is not set or wired incorrectly OR if a login was enabled on the serial port.

 

[trunix]

Are we missing something here ?

Columbia say that the data in the print q ends mid line. The printer will only print what is in the q. Therefore it seems that the full data is not being submitted to the queue.

I would suggest disabling the pinter, submitting the file to the q and then checking the q. If all the data is not there, then the problem is not with the printer and you need to look further back.

 

[ColumbiaIT]

MbMan
ahhh, I see. being a bit of a MS slave I just figured all thing got spooled. I stand corrected.
for the interest of the group the application in question is a FoxPro 2.6 database. The same form is used to enact the print command. the only thing different in the user setup (foxpro) is which printer is set to default.

Trunix
Had not considered that line of Troubleshooting. will check it out. Thanks

Thanks to all
for your input

SSS

 

[pcunix]

OK, here's your debugging procedure:
First, get netcat:

http://pcunix.com/SCOFAQ/scotec7.html#getnetcat

# disable printername

Now have app print the troublesome output. To avoid confusion, allow no other printing at this time.

# cd /usr/spool/lp/temp

You'll find the output of the app there. It will be named 123456-1 (123456 will be some other number- the request-id number). There will also be a control file named 123456-0.

First, as trunix suggested, look at it:

# more 123456-1

If it looks complete, now send it raw to the printer.

Let's say your printer is connected to an HP Jetdirect on port 1. You do

# cat 123456-1 | netcat -h printeraddress -p 9100


if that stairsteps, do

# cat 123456-1 | /usr/lib/lponlcr | netcat -h printeraddress -p 9100

See

http://pcunix.com/Jeffl/printports.html

for other print servers.

If that all prints, then something in your interface script is cutting it off. That's VERY unlikely.

But if it works with netcat and not with whatever you are using now, use netcat- there are examples in the links given above.

# enable printername

to restart normal printing. Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com