  Is it OK to use $QIO from an AST? 
 The Question is:
 
Dear Wizard,
 
I have a contractor in here writting code which does multiple disk I/Os
(using qiow() from inside ASTs.  In particular these ASTs are generated
from qio "socket" reads.  I was, and still am unless you tell me otherwise,
under the impression that one shou
ld limit the amount of code executed inside an AST.  I am having trouble
convincing him that this is probably not a good implementation technique.
What are your feelings?
Thanks, John E. Frank frankjo@us.polygram.com
 
 
 The Answer is:
The Wizard commends you for your attitude regarding AST code -- keeping it to
the minimum will greatly improve your odds of success (you obviously had a
proper VMS upbringing).
 
On the other hand, it is valid to perform "well-defined" operations from
within AST code, and your contractor's approach is covered under this.  His
proposal is commonly refered to a "chaining I/Os", whereunder each I/O's
completion requests the next I/O, which results in the process always having
an I/O outstanding on the channel.  [The Wizard is boldly presuming here that
your contractor is using $QIO and -not- $QIOW as your post suggested.]  The
tricky part of this is managing the buffers and IOSBs, and keeping the
mainline code running sufficiently to consume all of the I/Os (or providing
some mechanism for throttling it).
 
Back on the first hand, however, VMS now provides another alternative
mechanism for multiprogramming:  threads.  Your application can create a
thread for each I/O channel, and the threads perform the I/Os using
straightforward synchronous calls (potentally allowing you to use RMS calls
or high level language run-time calls instead of tangling with $QIO).  This
approach requires no ASTs or interrupt-style programming, and the code in
general is much simpler to read and understand.  However, it does require
switching to the multithreaded programming paradigm, with the attendant
learning curve.  Nevertheless, there are additional benefits to using
threads, such as the ability for full parallel execution on SMP machines.
(See "The Guide to DECthreads" in the programming section of the VMS doc
set.)
 
In conclusion, it sounds like your contractor is a good VMS programmer from
the old school, and if that's true his approach should yield a good, high
performance result when used in a non-threaded application.  However, there
now exists better technology which, depending on your requirements, could
yield superior performance with simpler code, and you/he should consider
using threads.
