[Info-vax] QIO Writes to a mailbox

[Bob Koehler]

In article <e519cbe4-54bc-480c-8b07-267b9f90edda at q13g2000vbd.googlegroups.com>, Steve Bainbridge <stephen_bainbridge at yahoo.co.uk> writes:
> Hi,
> 
> I have a very simple question, but when looking at the Alpha internals
> manual and talking to colleagues the answer does not seem so obvious.
> 
> We have some old code that issues a QIO WRITEVBLK to a mailbox - the
> return code from the QIO is normal. Another process reads the mailbox
> and never gets the message - this only happens very rarely.
> Unfortunately the writer does not check or report what value the IOSB
> returns and I need to try and understand why these messages are
> getting lost. I can't reproduce this on our test systems and I can't
> easily install updated diagnostic code onto these production systems.

   A normal return only means you have successfully requested an I/O.
   This typically means you don't have bugs in your code like screwing
   up the channel or function code, or forgetting to pass required
   values in P1 ... P6.

   Only the IOSB will tell you if the I/O actually happened the way
   you asked for it.  While you're not likely to have a hardware
   failure on a mailbox, there are other issues that can come up.

> The question I have is when is the data pointed to by P1 (in the QIO
> call) actually copied ? It is always done within the QIO routine or is
> it just scheduled to be done in the QIO call ? Can I re-use the buffer
> pointed to by P1 immediately after the call to the QIO ?
> 

   Mailboxes are buffered I/O devices, so I would expect data to be 
   transfered from your buffer to a system buffer fairly early on.  
   I don't have source listings handy, but I would expect this to be 
   done in the FDT routine, which is before $QIO returns.  But mailboxes 
   may be different since that's all they do anyhow.

   If you could get the IOSB, I'd suspect either the data was
   transfered, or the message is larger than the available space in the
   mailbox.  It's also possible that you're running out of some
   process quota, like the number or volume of buffered I/O.

   Not checking the IOSB is a software bug that should never be put into
   production and production code with that bug should be fixed.

   And if you're really doing a $QIOW, or synchronizing with the I/O
   completion before you reuse the P1 buffer, then you're OK to change
   the buffer content.  Meanwhile, you can't count on the IOSB being
   filled in unless you're doing a $QIOW, or synchronizing with the
   I/O completion, since it gets filled in during I/O post-processing.