On Aug 2, 3:20 pm, apolanc...@gmail.com wrote:
> We are having a problem when printing largish files (greater than 100
> pages). The print starts OK, but after printing for a while the
> printer goes down. This happens for all the printers we have tried.
> The printers are not running out of paper, loosing power or offlined
> in any other way. We have also tried printing different files. The
> result is the same. If I enable the queue, the file starts printing
> from the beginning.
>
> This is happening to local serial/paralell printers (attached to a RAN
> port).
>
> The /var filesystem was increased to 400MB.
>
> AIX LEVEL = 4.3.2
>
> Thanks
>
> Ambiorix

>From past experience with RANs, the problem you are encountering is
related to a flow control condition. Perhaps there is too much data
coming in to the RAN at one time and the buffer overflows.

My suggeston is to check your printer's buffer and flow control
settings. Set the buffer to its maximum value, and find out if you are
using xon/xoff (software) flow control, or dtr (hardware) flow
control. Make sure that the settings on the port for the device are
the same by verifying the "lsattr -E -l lp1" settings. The ones that
I've had to tweak in the past were:

forcedcd=enable
altpin=enable
flow_disp=???
fastcook=disable

The altpin we set on because we use the RJ45 (8-wire) cabling instead
of the full 10-wire version.
The flow_disp was set the same as the printer setting (either dtr or
xon).
The fastcook seemed to work better for us as it was just sending the
data to the printers without modifying it in any way
The forcedcd was because we wanted the AIX system to always think
there was a device present.

HTH

SteveN

On Aug 3, 7:20 am, apolanc...@gmail.com wrote:
> We are having a problem when printing largish files (greater than 100
> pages). The print starts OK, but after printing for a while the
> printer goes down. This happens for all the printers we have tried.
> The printers are not running out of paper, loosing power or offlined
> in any other way. We have also tried printing different files. The
> result is the same. If I enable the queue, the file starts printing
> from the beginning.
>
> This is happening to local serial/paralell printers (attached to a RAN
> port).
>
> The /var filesystem was increased to 400MB.
>
> AIX LEVEL = 4.3.2
>
> Thanks
>
> Ambiorix

you're in the brown stuff to degree. AIX 4.3.2 was not a "good"
version of AIX even when it was supported. Very buggy.

I can only suggest ramping-up the verbosity of syslog.
have a look at your syslog configuration in /etc/syslog.conf
I'd suggest you take a backup copy of /etc/syslog.conf first
[as root]
cp -p /etc/syslog.conf /etc/syslog.conf.20070803

check that this file exists
ls -l /var/log/messages

if it doesn't
touch /var/log/messages

remove all entries (in /etc/syslog.conf) except this; WARNING, syslog
is really petulant, make sure you use a TAB between the fields!

*.debug /var/log/messages

restart syslog
refresh -s syslogd

then look through the /var/log/messages file for any nastiness.
HTH

"steven_nospam at Yahoo! Canada" wrote in message
news:1186086531.663700.32450@q3g2000prf.googlegrou ps.com...
> On Aug 2, 3:20 pm, apolanc...@gmail.com wrote:
>> We are having a problem when printing largish files (greater than 100
>> pages). The print starts OK, but after printing for a while the
>> printer goes down. This happens for all the printers we have tried.
>> The printers are not running out of paper, loosing power or offlined
>> in any other way. We have also tried printing different files. The
>> result is the same. If I enable the queue, the file starts printing
>> from the beginning.
>>
>> This is happening to local serial/paralell printers (attached to a RAN
>> port).
>>
>> The /var filesystem was increased to 400MB.
>>
>> AIX LEVEL = 4.3.2
>>
>> Thanks
>>
>> Ambiorix
>
>>From past experience with RANs, the problem you are encountering is
> related to a flow control condition. Perhaps there is too much data
> coming in to the RAN at one time and the buffer overflows.
>
> My suggeston is to check your printer's buffer and flow control
> settings. Set the buffer to its maximum value, and find out if you are
> using xon/xoff (software) flow control, or dtr (hardware) flow
> control. Make sure that the settings on the port for the device are
> the same by verifying the "lsattr -E -l lp1" settings. The ones that
> I've had to tweak in the past were:
>
> forcedcd=enable
> altpin=enable
> flow_disp=???
> fastcook=disable
>
> The altpin we set on because we use the RJ45 (8-wire) cabling instead
> of the full 10-wire version.
> The flow_disp was set the same as the printer setting (either dtr or
> xon).
> The fastcook seemed to work better for us as it was just sending the
> data to the printers without modifying it in any way
> The forcedcd was because we wanted the AIX system to always think
> there was a device present.


Steven has got you on the right path. Generally speaking, a locally
attached (RAN) printer queue would go down mid job when the printers buffer
overflows and the printer lowers the DTR signal which, if cabled properly
should run to the DSR and DCD pins on the RAN if you are using a full
10-wire cable. Since few run a 10-wire cable, you will want to use the
alternate RJ45 pinouts if you've got a properly pinned 8-wire cable.

I don't recommend you use the "forcedcd" setting because if the printer's
DTR is connected to the RAN port DCD and you use forcedcd, you'll ignore the
printer's flow control and the result will be dropping chunks of the print
job instead of queues going down.

Another possibility is your printer (like some Okidata line printers) uses
RTS/CTS flow control instead of DTR flow control. If that is your case, I
recommend removing the lp device from the RAN port and configuring the port
with a tty device (with login disabled). You can then set up a queue to the
tty and everything will work just fine with your queues except that the
queue won't go down if the printer lowers the RTS signal which is cabled to
the CTS pin at the RAN end. The tty device driver is much more forgiving
that the lp device driver in my experience and you'll never notice the
difference once you're up and printing.

Here are some additional thoughts to consider:
1) Lower the baud rate. Why shove data at the printer faster than the
printer can put it on paper. This depends on your type and speed of
printer.

2) Use the arrows on the RAN box to arrow over to the ports and see the
serial port signals. What signals change at the moment the queue goes down.
Might be a setting on the printer or something you can cable or the RAN port
settings.

Best regards,
Paul