Conference 7.286::postscript_printing

7195.0. "Problems with networked DEClaser 5100 (LN09) and Windows 95" by VMSNET::M_SMITH () Mon May 12 1997 14:08

    A customer is having the problem with Win95 and a networked DL5100:
    
     Here are the log traces for ten machines simultaneously printing to a 
     DEClaser 5100 (BIOS v.02.40 E1,PostScript V.2013.109 rev. 163) via TCP/IP 
     (Frame type: Ethernet II), using the DEClaser 5100/Net driver. I
     have done identical tests using DEClaser5100 with BIOS v.03.05 and have
     gotten identical results.
            
    The test are done by printing four Windows95 test prints from each 
    machine simultaneously, for a total of 740 print jobs attempting to
    access  the printer. This seems to accurately simulate the situation
    our users are  encountering where we have up to 40 machines set to
    print direct to the  printer and can send jobs of any size at any time. 
    In the tests that I've done 1-3 machines finish with print jobs in
    their  queue in the "connecting" state, the jobs never print and the
    machine have  to be re-booted in order to clear the queue. Often
    machines get an error  message "Data area passed to a system call is
    too small", but upon hitting  return, these machines continue printing
    all jobs O.K. These are not the  problem. In the test that the attached
    file where generated from, machines 4, 6,  8, & 10 printed all O.K. 1,
    2, & 5 got the "Data area passed to a system  call is too small" error
    (Corresponding to the "BE_E_INVALID_REQUEST"  message in the traces),
    then printed all O.K. after hitting enter.  Machines 3, 9, & 7 all
    locked up in the "connecting" state, the last  message in thier trace
    is"IB_get job state". Machines 3 & 9's trace reads  "SOCK_E_TIMEDOUT"
    just before the last "IB_get job state". This is the  first time I've
    seen that message, and guess that it's due to the printers  BIOS
    version. Machine 7's trace reads "SOCK_E_CONNREFUSED" just before the 
    last "IB_get machine state", which is the normal message in all the
    traces  when the printer is busy with another job.
    
    I can include the captured log files if needed.
    
    Michael
    

    We would recommend that you submit an IPMT case, with the following
    caveats:
    
    Two of the three error messages that you describe herein, sound like
    the NIC (network interface card) has accepted as many network
    connections of which it is capable of handling simultaneously. Additional
    connections will be rejected by the NIC. This is all expected behavior.
    The operating system from which you are printing will respond
    to said lack of connection ports, on the printer's NIC, in whatever 
    fashion it is capable (sock_e_timeout and sock_e_connrefused).
    
    The problem of connecting and staying in the "connecting state" is a
    known problem for which we have just issued a new DECPSMON release. It
    is NOT widely available at this time. But might be made available for
    people who realize that this has NOT received extensive testing.
    
    So if you want to IPMT the problem of staying in the connecting state,
    that is reasonable. The other error messages, do not represent printer
    problems.
    
        jeff