Conference help::decnet-osi_for_vms

>	1 Which event can produce this kind of return code in the AST ?

A completed QIO with an IOSB of zero *ALWAYS* indicates that more than one QIO
is using the same IOSB - in other words, it's a bug in the application code. 
Each QIO should be referencing a unique IOSB - no sharing allowed.  Fix the
application.

>	2 All code is made with non blocking Qio execpt the IO$_ACCEPT
>	  is it the right way to acceprt connection in this kind of server ? 
>	  (perhaps it could takes somes seconds when lot of users are on 
>	  the system)

It's fine.  It could be blocking or non-blocking.  I don't think a blocking
accept will actually block for a long time.  It seems a little inconsistant with
the apparent design philosophy of the application though; that is everything is
non-blocking except the accept.

>	3 When the DECnet mailbox is created the size of Mailbox is 43000
>	  and the size of message is set to 4300
>	  Does it mean only 10 messages could be queued ?

If the size of an actual message was 4300 bytes, then yes, only 10 messages
could be *pending* in the mailbox.  In practice, I don't think I've ever seen a
DECnet mailbox message that large - usually around 100 bytes or so if I recall
correctly (it's been awhile).  The right size of the for the buffer quota on the
mailbox would be a size sufficient to handle a message from every link at the
same time.  if you assume that messages will be no more than 256 bytes and you
plan on having at most 20 active links, then the buffer quota should be 20*256.
Larger buffer quotas don't penalize the application unless the quota is actually
used to hold a message.

AN IOSB of zero scenario usually falls into one of two cases, both of which are
timing related:

The first scenario is when you aren't doing QIO's from within AST routines;
this timing window is hard to hit because it depends on a QIO being done
just before an AST is delivered where both I/O's used the same IOSB.

QIO A issued with IOSB A and AST routine
(remember that the QIO zero's the IOSB right away before doing to I/O)
  :
 <time passes>
         QIO A completes, AST is queued for delivery; IOSB contains valid status
QIO B issued with IOSB A
QIO A AST routine delivered/invoked - whoops.... IOSB is zero

The second scenario is when you are doing QIO's from AST routines - this
is an easy timing window to hit if you spend a lot of time in the AST routine,
as AST delivery for the QIO in question is blocked until the current AST is
complete:

QIO A issued with IOSB A and AST routine
QIO B issued with IOSB B and AST routine
  :
        QIO B completes and AST routine is queued for delivery
QIO B AST routine delivered/invoked and starts processing
        QIO A completes and AST routine is queued for delivery
QIO B AST routine still active and issues QIO C with IOSB A, then rtn completes
QIO A AST routine delivered/invoked - whoops.... IOSB is zero

--Scott

    
    
    Hi,
    
    	Thanks i have found, as you told me a problem with an IOSB wich is
    used for two channel.
    
    Jerome