[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::pwv50ift

Title:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Notice:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Moderator:CPEEDY::KENNEDY
Created:Fri Dec 18 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4319
Total number of notes:18478

4235.0. "Failed:29 Bind Error" by GRANPA::BARABIA () Mon Mar 31 1997 14:20

    The following appeared in the PWRK$KNBDAEMON_xxxxx.LOG file on 2
    of 3 of our PATHWORKS Cluster nodes following a re-start this
    monring.
    
     Mon Mar 31 07:06:16 1997 PH Address: 08-00-2B-B3-E2-85
     Mon Mar 31 07:06:16 1997 IP Address: 150.148.26.217
     Mon Mar 31 07:06:16 1997 bind_a_port: <netbios/streams/pwipd> t_open
     failed: 29
     Mon Mar 31 07:06:16 1997 Port binding failed
    
    Previous notes I read indicated that possbily this could be caused by
    the PWIP driver not being available when PATHWORKS starts. We are using
    Multinet V3.5 as our TCP/IP stack. I can't find anyting within Multinet
    that would indicate a problem loading the PWIP dirver and the driver
    seemed to be loaded when the system came up.
    
    Any ideas as to what the FAILED:29 status means? We are PW V5.0D ECO3
    on OpenVMS 6.2 on AXP's. All else seems ok. 
    
    The PWIP driver is loaded in the MULTINET_START.COM file. I was
    thinking about taking the commands out of the .COM and creating a
    separate .COM that just loads the PWIP driver and is called by the
    PATHWORKS startup file right before it executes. This is assuming the
    above issue is caused by the PWIP driver not being loaded when PW
    starts.
    
    Thanks for any input provided.
    
    Barry A
T.RTitleUserPersonal
Name		DateLines
4235.1Startup already checks for PWIP driverCPEEDY::VATNEPeter Vatne, PATHWORKS for UNIX Server EngineeringMon Mar 31 1997 17:4113
>    Previous notes I read indicated that possbily this could be caused by
>    the PWIP driver not being available when PATHWORKS starts. We are using
>    Multinet V3.5 as our TCP/IP stack. I can't find anyting within Multinet
>    that would indicate a problem loading the PWIP dirver and the driver
>    seemed to be loaded when the system came up.
    
I rather doubt this is the problem.  The PATHWORKS startup command
procedures explicitly check for the existence of the PWIP device if
TCP/IP is configured as one of the transports.  This check is done
to guarantee the PWIP driver is available before the server starts.

Sorry I can't help you decode the error number, a transport person
will have to jump in here and help...
4235.2GRANPA::BARABIAWed Apr 02 1997 13:1610
    Thanks Peter, I overlooked the fact PW checks for the PWIP before hand.
    Plus, this issue only seems to happen when the whole system is
    re-booted.. Usually, if we get the error 29, we are able to re-start
    PATHWORKS and all is well.
    
    So, how bout it transport folks!!!
    
    thanks,
    
    BA
4235.3UTRTSC::SWEEPI want a lolly...Thu Apr 10 1997 07:218
    #define TPROTO          29      /* XTI protocol error */
    
    doesn't say much huh...
    
    its a sorta accumulate all errors that we can't define
    as protocol errors.
    
    Adrie
4235.4No, not much!!GRANPA::BARABIAThu Apr 10 1997 15:556
    Nope, don't say much at all, other than the PWRK$KNBDAEMON process
    won't start and no TCP/IP connections can be made to the server!!
    
    Any iusses with Multinet 3.5 (101) that we know off?
    
    Barry
4235.5UTRTSC::SWEEPI want a lolly...Fri Apr 11 1997 04:577
    Not that I know off, probably you and paul would
    know best.
    
    I'll walk the t_open code path and see what I can find.
    No promises...
    
    Adrie
4235.6UTRTSC::SWEEPI want a lolly...Fri Apr 11 1997 05:0212
    This is what I found
    
       * or TBADADDR). The XTI spec says that we can return a TPROTO error
    when
       * there is a communication problem between XTI and the transport
    provider
       * for which there is no other suitable XTI t_errno.
    
    Says it all. You have a communication problem with the PWIPdrv
    as you thought.
    
    Adrie