PRINTER GOES DOWN WHEN PRINTING LARGE FILES - Aix

This is a discussion on PRINTER GOES DOWN WHEN PRINTING LARGE FILES - Aix ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: PRINTER GOES DOWN WHEN PRINTING LARGE FILES

  1. PRINTER GOES DOWN WHEN PRINTING LARGE FILES

    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


  2. Re: PRINTER GOES DOWN WHEN PRINTING LARGE FILES

    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


  3. Re: PRINTER GOES DOWN WHEN PRINTING LARGE FILES

    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


  4. Re: PRINTER GOES DOWN WHEN PRINTING LARGE FILES


    "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



+ Reply to Thread