SCO UnixWare 7 Release 7.1.1, 7.1.3, 7.1.4 
          SCO Open UNIX Release 8.0.0 (Unixware Release 7.1.2) 

          When I print I can have delays of 5 seconds between prints of LPD
          printers.

          Printing to LPD printers has a number of sleeps between each print
          shown below:

          As per RFC 1179, after sending a printjob, the client has to close
          the connection to the remote printer, then reopen it, and send a
PRINTJOB
          command to get the printer start printing.

          The function s_print_request() that does this has the following
          comments about the sleep statements you are seeing:

    /* We have to close and reopen the connection before we can send
     * the "Print any waiting jobs" (PRINTJOB) command, see rfc1179
     * section 5.
     * Note: the sleep has been added between the close and open to help
     * cope with HP JetDirect printers which start printing as soon as
     * the connection has been broken and will not allow a new one until
     * the job has been printed, otherwise we get a delay of 2 mins between
     * print job (default retry timeout).
     */
    closeRemote();
    sleep( 2);
    if (openRemote())
    {
            /* Wait while remote end sets itself up, before
             * sending message
             */
            sleep(3);
            (void)snd_lpd_msg(PRINTJOB, Printer);
    }

          The same problem does not appear with OpenServer printing.

         

Patches
-------
          Ensure that your server has been patched with the latest Maintenance
          Pack available from:

          ftp://ftp.sco.com/pub/unixware7/uw711pk/

          and:

          ftp://ftp.sco.com/pub/openunix8/ou800pk/

Network Drivers
---------------
          Ensure that your server is using the latest network "nd" driver
          available from:

        ftp://ftp.sco.com/pub/unixware7/drivers/network/

          and:

        ftp://ftp.sco.com/pub/openunix8/drivers/network/

TCP/IP Tuning
-------------
          Ensure that your server has been tuned for TCP/IP.  The details are
          available from:

          Technical Article 113164 for UnixWare 7.1.1

          and:

          Technical Article 114966 for OpenUNIX 8.0.0/7.1.3

Kernel Tuning
-------------
          Ensure that your server's kernel has been tuned in accordance with:

          Technical Article 117343, "I am getting abnormal process termination error messages
          in lpNet. "

          This problem has been reported to SCO Engineering and will be fixed
          in a later release of the Maintenance Packs for UnixWare 7.1.1
          (currently Maintenance Pack 2) and for OpenUNIX 8.0.0 (Currently
          Maintenance Pack 4).

          Should you experience problems with HP JetDirect printers giving 2
          minute delays it is suggested to set the "retry" field to "0" in
          /etc/lp/Systems and stop and re-start the lp scheduler as detailed
          above.

          After a print job is successfully sent to a remote machine, lpsched
          schedules a status request to be sent to this printer after 2
          minutes. lpsched, then after 2 mins, requests a status request. If
          it finds the printer system busy, for example, if another print
          request was in the process of being sent, then the print status
          request waits for another 2 mins.  If the printer is busy, the 
          jobids even though printed, never get recycled.

          What lpsched needs to do is to add the status request to the 
          queue of requests to be sent to the printer. Since status requests 
          have higher priority over print requests, next time the status 
          request should be sent and if printed then removed from the queue.

          This fix will also reduce the likelihood of the print queues filling
          up, because querying the status with the job will ensure that the
          job is removed more rapidly from the queue.

          Should the "lpsched" process die, due to intense printing activity
          then a workaround to ensure that "lpsched" is restarted would be to
          run a script constantly checking the "lpsched" process in the
          "cron":

# cat /local/bin/start_lpsched

:
NUMBER=`ps -ef |grep lpsched|grep -v start_lpsched|grep -v grep|wc
-l`
if [ $NUMBER -le 0 ]
then
        echo "lpsched died - `date` " >> /var/lp/logs/lpsched.`date
+'%y%h%d'`
        exec /usr/lib/lpsched -d -s >> /var/lp/logs/lpsched.`date
+'%y%h%d'` 2>&1 &
 fi

=====================================
Here is the crontab entry:
=====================================
* * * * * /local/bin/start_lpsched
=====================================

          Should you experience "lpsched" hanging with during intense printing
          activity then "lpsched" should be killed using the "-11" option
          which should produce a "core" file in the directory where "lpsched" 
          was started and it should also be present in /usr/lib/lp.

          Should you experience "lpd" printers not printing, "lpstat -t" 
          or "who -b" and "who -r" hanging, check that /etc/utmpx has not been
          removed.

         

Technical Article 117343, "I am getting abnormal process termination error messages
in lpNet."

Technical Article 114966, "Open UNIX 8, My application returns IP SOCKET ACCEPT
failed [errno 63] when I try to open hundreds of sockets per second."

Technical Article 113164, "My application returns SOCKET accept failed [errno 126]
when I try to open over 200 sockets every second."

Technical Article 111121, "How do I configure my UnixWare 7 machine to print to a
Hewlett-Packard network printer?"