Conference marvin::x25psi

3747.0. "NCB with Invalid Buff Length??" by BACHUS::GOOVAERTS () Fri Apr 18 1997 09:04

	<Crossposted X25psi and decnet-osi> 
 Hello,

 I need some assistance with X25 programming on VMS/VAX
 We have a customer who has a program which runs
 on several sites except on one
 They have problems with the  IO$_ACCESS|IO$M_ACCEPT call.
 In the IOSB we get Invalid buffer length,which
 indicates that there is something with the ncb,but on all
 other sites its works.
 Any Hints?
	
 The failing call is :


/*
**      NCB descriptor for accepting incoming calls
*/
static  call_accept_ncb_t ncb     = { { sizeof(struct incoming_call_id_t),
                                        psi$c_ncb_ici,
                                        0 },
                                        { sizeof(struct packet_size),
                                        psi$c_ncb_pktsize,
                                        0 } };

static  struct dsc$descriptor ncb_desc = { sizeof (ncb),
        DSC$K_DTYPE_VT,
        DSC$K_CLASS_VS,
        &ncb };
/*
**  Initialize the NCB descriptor with the incoming call id
*/
    ncb.incoming_call_id.s = g_ppacbs[a_line_no].inc_call_id;
    ncb.pack_size.s        = LN_PACKET_SIZE_512;

/*
**  Make the CALL ACCEPT packet
*/
    status = SYS$QIOW  ( 0,                         /* Issus QIO and wait      
                        a_psi_channel,              /* to network device       
                        IO$_ACCESS|IO$M_ACCEPT,     /* function is make a call 
                        &iosb,                      /* pointer to the I/O statu
                        0,                          /* ast to decode the conten
                        0,                          /* parameter to the ast rou
                        0,
                        &ncb_desc,                  /* call NCB descriptor     
                        0,
                        0,
                        0,
                        0);

 The field status contains : '1',
 but iosb.status contains  :   844 / 0 / 19 / 0 (its 4 words)

 844 => SS$_IVBUFLEN
 



Contents of ncb_desc :

   word    : 14       length
   byte    : 37       type
   byte    : 11       class
   pointer : 2643120  pointer to data


 ncb : call_accept_ncb_t is defined :

typedef struct call_accept_ncb_t
{
    struct incoming_call_id_t incoming_call_id ;
    struct packet_size        pack_size;

}   call_accept_ncb_t;

typedef struct call_clear_ncb_t
{
    struct incoming_call_id_t {                             /* incoming call id
            short len;
            short code;
            int   s;                                        /* integer         
    } incoming_call_id ;

    ...

}   call_clear_ncb_t;

/*
**      NCB for a CALL REQUEST PACKET for PSI
*/
typedef struct call_ncb_t
{
    ...

    struct packet_size {                            /* packet size          */
            short len;
            short code;
            unsigned short s;
    } packet_size ;

    ...

} call_ncb_t;

 ncb contains :

            short len        8
            short code         11
            int   s            507

            short len          6
            short code         21
            unsigned short s   512

    The secondary status is psi$c_err_l3err, which suggests that L3 is
    getting upset for some reason. Try tracing the incoming call at X25L3
    (and maybe at LAPB) and see if that helps.
    
    You don't mention the version of DECnet-Plus which the customer is
    running ... it might matter,
    
    BTW: just because the example programs incorrectly use
    DSC$K_DTYPE_VT/VS (and have done so for the last 15 years or so) is no
    excuse for a customer to do so in production code :-). If they really
    want to specify a type they should use DSC$K_DTPE_T/DSC$K_CLASS_S since
    this is what SYS$QIO will assume regardless of what the caller
    specifies. (Now if they had correctly coded a varying text descriptor in
    their code it would have failed!!)
    
    Antonio

    Thanks for the reply,
    
    		we will take the trace a repost the outcome.
    
    	The problem is the that we will have some delay,
    	because the system is in Spain and we are in Brussels.
    
    
    Rgds
    
    Danny