  parallel sys$qio calls, I/O reordering? 
 The Question is:
 
I thought i had read somewhere, within a VMS manual, maybe
even in the IDSM ?, that you should NOT have more than one
$QIO operation pending on a device at a time.
 
I then found this Q+A paragraph at the TGV site,
 
&gt;&gt; In the "$QIO Interface" sectioni of The MultiNet Programmer's
&gt;&gt;  Guide, a note is listed as saying:
 
&gt;&gt;  If more than one $QIO operation is pending on a socket at any
&gt;&gt;  one time, there is no guarantee that the $QIO calls will complete
&gt;&gt;  in the order the are queued ... the data may be interleaved."
&gt;&gt;  As a curiousity, what is the reason behind this??
 
The supplied answer was:-
 
&gt;&gt; The reason behind this has to do with the design of the BSD
&gt;&gt; TCP/IP kernel on which MultiNet is based on (the kernel is
&gt;&gt; the actual BSD 4.3 code).  In that design what happens on a
&gt;&gt; write is if there is no room in the socket snd buffer then
&gt;&gt; it creates what is known as a "miniprocess" which waits until
&gt;&gt; there is room.  However once a write has been "deferred" as
&gt;&gt; a miniproc then there is nothing to prevent the next write
&gt;&gt; from actually making it into the socket buffer.  Thus an
&gt;&gt; asynch write of "ABC" followed by a asynch write of "DEF"
&gt;&gt; could be seen as a "DEF" followed by "ABC" on the receiving end.
 
&gt;&gt; Please note this can only happen on $QIO's not $QIOW's since a
&gt;&gt; $QIOW will cause you to block until the IRP is posted.
 
 
I normally chain my qio's together. i.e. I maintain a pending
queue per channel (be it DecNet or TCP or UDP). When the AST
completes successfully, the buffer just sent is returned to the
free-pool, I de-queue next buffer from the pending-queue, and
issue a asynchronous qio write.
 
Q) A curiosity ... In respect of a mailbox, LAT, UCX + DECNET,
   is it permissable to issue multiple ASYNCHRONOUS qio writes?,
   or would the possibility of interleaving exist ?
 
   If this can happen, could you explain why
 
   If NOT, is there any likely performance gain
   by issuing multiple qio writes ?
 
thanks
 
 
 
 
 The Answer is:
 
  Under OpenVMS, multiple I/O operations can be outstanding on the same
  device at the same time.  The specific behaviour of the device driver
  and of the application is directly involved here, with factors ranging
  from the driver's ability to process multiple I/O operations to the
  particular (re)ordering of the I/O completions that might occur.
 
  Most drivers operate without explicitly reordering operations, but it
  is certainly possible that reordering can occur -- one example of a
  case where reordering might be of interest involves the performance
  improvements from reordering the disk I/Os operations into seek order.
 
