Conference tuxedo::dce-products

    Don't know if you've settled this already..
    
    You need to see the file cnasgsm.h in the RPC runtime.  Basically,
    you're looking at a current stat of:
    #define RPC_C_ASSOC_GRP_CLOSED                  100
    and an action of:
    #define RPC_C_ASSOC_GRP_REM_ASSOC               102
    
    So I believe an attempt to remove an association from a group that's
    already been closed is happening.  I've not seen this problem before. 
    You should collect as much information as possible on what's happening 
    at the time of the problem.  If you can debug the client, try to get a
    stack of when its calling the illegal state routine.  Find out if
    clients or servers are being abruptly cancelled, we've had some
    problems in that area before.  Also see if they're using authenticated
    RPC's.
    
    I suppose this could be a resource exhaustion issue.  You might make
    sure they plenty of swap space when the problem occurs.
    
    -- brandon

    
    Here's a bit more information on this problem. At some point the
    errors put in the log file change from the client association to 
    the server association. 
    
    (rpc) *** FATAL ERROR "(rpc__cn_grp_sm_protocol_error)" at
    CNASSOC.C;1\5860 ***
    
    (rpc) *** FATAL ERROR "(rpc__cn_network_receiver) Unexpected exception
    is raised" at CNRCVR.C;1\398 ***
    
    (rpc__cn_grp_sm_protocol_error) Illegal state transition detected in CN
            server association group state machine
    
    (rpc__cn_grp_sm_protocol_error) Current state: 103
    
    (rpc__cn_grp_sm_protocol_error) Current event: 102
    
    (rpc__cn_grp_sm_protocol_error) Grp: a517f8
    
    The current state on the server association changed (103) however 
    I noticed that the Grp: a517f8 was the same as the one on the 
    client association. I don't know what this means but hope you can 
    help..
    
    joe
                                                                                                                                       

    
    
    They are using Authenticated RPC's. What does this mean 
    in regards to this problem???
    
    Joe

    Any "illegal state transition" messages mean that we have an internal
    error happening.  The fact that they are using authenticated RPC's help
    us determine which code path is being taken.  We had a recent problem
    on the Unix product with cancels of authenticated RPC's, so that's
    another data point to try to collect from the customer (whether their
    problem is happening during cancels).  Meanwhile, I've also gotten a 
    bug report from one of the OSF members about a problem in this area 
    that I must explore.
    
    I'll update this Note in another day or two when I know a little more.
    
    One cheap, temporary work-around the customer might try is to switch to
    using UDP only for the time-being.  On Unix, this is done by setting an
    environment variable:
    	% setenv RPC_SUPPORTED_PROTSEQS ncadg_ip_udp
    This could be done before starting the application client(s).  I'm not
    sure how to do the same thing on VMS.
    
    -- brandon

> One cheap, temporary work-around the customer might try is to switch to
> using UDP only for the time-being.  On Unix, this is done by setting an
> environment variable:
>     % setenv RPC_SUPPORTED_PROTSEQS ncadg_ip_udp
> This could be done before starting the application client(s).  I'm not
> sure how to do the same thing on VMS.

RPC_SUPPORTED_PROTSEQS is available as a logical name which can be set on
OpenVMS.  Use DEFINE/SYSTEM instead of setenv.

						Wayne 

    
    
    Thanks. Will forward this on as possible workaround.
    
    Meanwhile keep me informed as to the results of the 
    investigation of the problem reported from one of the 
    OSF members about. If there is a problem needing to be 
    fixed in this area the sooner the better.
    
    thanks again
    Joe

    I've examined the OT filed with the OSF that I thought might be in the
    same area.  Unfortunately it does not pertain to this problem.
    
    Your 2nd message about "Illegal state transitions" has the current
    state as 102:
    #define rpc_c_server_assoc_grp_call_wait        103
    while the current action is 102:
    #define rpc_c_assoc_grp_rem_assoc               102
    
    So the association is being shutdown though its still waiting for a
    call to complete.  I think we'd need more information on this problem
    to fix it.  If the customer has test code that reproduces the problem,
    that would be ideal.  If they'd let us login to try to reproduce the
    problem, that would be next to ideal.  At the minimum we should get a
    description of what's going on at the time of the problem.
    
    Personally, I can't do much with a VMS problem, but would be willing to
    help the VMS team debug the problem if they can reproduce it.
    
    -- brandon

The customer upgraded to TCP/IP Services for OpenVMS version 4.1 ECO level 4. The illegal state transitions have
disappeared since the upgrade.

Dave