info-vax@ucbvax.ARPA (03/29/85)
From: Provan@LLL-MFE.ARPA Hello! Me again! I've just noticed that despite the encouraging completion routines, it's not possible to indicate to RMS that an $Open is to be done asyncronously. Normally, of course, one doesn't notice this, but I'm trying to do an $open over DecNet where the delay can be several seconds. Since the program in question has many other things to do while it's waiting, it's really unhealthy for it to sit around twiddling its thumbs even long enough for local IO generated by the $open to complete, let alone wait for the remote process to fire up and all that. First off, am I missing a way to make $open's asyncronous? If not, does DEC recognize this as a deficiency? If so, are they planning on fixing it, or is it not fixable? Since I got jumped on last time for not being specific about what I wanted to know, let me just make it clear that I recognize that there are ways to make the DecNet $open faster (like setting up permanent server processes and such). That's not the issue. If there were no DecNet involved, I'd still be waiting for IO to complete when I don't want to. I'm *only* interested in information about the asycronous question. All other questions I already know the answer to. (If you believe that, you've only been on this list a couple of days....)
info-vax@ucbvax.ARPA (04/09/85)
From: LEICHTER <Leichter@YALE.ARPA>
Date: Wed, 3 Apr 85 13:42 PST
Subject: aborting asyncronous RMS IO
Well, I'm not sure if I seldom get answers because my questions are too
hard or too easy, or just because nobody likes me. But since I
sometimes do get answers....
The reason no one answered was because you asked for something that there is
probably no way to do. Few people are so sure they know all the ins and outs
of VMS that they are willing to make an absolute negative statement. However,
since no one has answered in several days, I'll stick my neck out and give
you the "bad news", as I understand it.
The remaining quotes are from a combination of two messages - the one cited
above and:
Date: Fri, 29 Mar 85 10:21 PST
Subject: asyncronous $open's?
I've just noticed that despite the encouraging completion routines,
it's not possible to indicate to RMS that an $Open is to be done
asyncronously. Normally, of course, one doesn't notice this, but I'm
trying to do an $open over DecNet where the delay can be several
seconds. Since the program in question has many other things to do
while it's waiting, it's really unhealthy for it to sit around
twiddling its thumbs even long enough for local IO generated by the
$open to complete, let alone wait for the remote process to fire up and
all that.
First off, am I missing a way to make $open's asyncronous?
No.
If not, does DEC recognize this as a deficiency?
No. I've never seen this mentioned by anyone as a problem. DECUS puts
together SIR's - System Improvement Requests - which are lists of things
people think ought to be in VMS. DECUS members suggest things for SIR's,
then everyone votes on them to produce a (actually, several, depending on
type of user) rank-ordered list(s). Things that show up high on SIR's tend
to get put into VMS. I have never seen any mention of this as a problem
in any SIR. I think a new one is being produced now, so you could try
and suggest it and see if anyone bites.
If so, are they planning on fixing it, or is it not fixable?
See above and below.
Since I got jumped on last time for not being specific about what I
wanted to know, let me just make it clear that I recognize that there
are ways to make the DecNet $open faster (like setting up permanent
server processes and such). That's not the issue. If there were no
DecNet involved, I'd still be waiting for IO to complete when I don't
want to. I'm *only* interested in information about the asycronous
question. All other questions I already know the answer to. (If you
believe that, you've only been on this list a couple of days....)
See below.
From what I can tell, there are only two ways to "abort" an RMS IO once
it's started. One is by calling Sys$RMSRunDown (a co-worker claims to
be having problems even getting that to abort an outstanding terminal
input wait). The other is to issue a $Cancel on the Fab's channel from
executive mode, which I assume will work although I haven't tried it
yet. Am I missing some normal way of telling RMS to cancel all active
IO for a particular Rab or a particular Fab? I'm not real thrilled
about giving CMExec privs to user programs and Sys$RMSRunDown will
close Fab's I don't want to close.
All RunDown does is issue $CANCEL's on all open channels. You do NOT want to
do $CANCEL's in Exec mode unless you like seeing a lot of RMS bugchecks. See
below.
General Discussion:
The VMS I/O system is layered. The two most important layers are the QIO
layer, which deals with actual devices and runs in Kernel mode, and RMS,
which does device-independent stuff (mainly) and runs in Executive mode.
The QIO level is fully asynchronous and provides access to all the I/O oper-
ations there are. RMS provides an easier-to-use interface (no, I'm NOT about
to say that it's EASY to use!) with a lot of extra functionality, but it does
NOT provide complete access to the underlying QIO level - though you can get
at most of it. (V4, for example, lets you do all the special terminal-related
calls through RMS; previously, you had to go to the QIO level.)
At the QIO level, there are channels to devices and files accessed on those
channels. At the RMS level, there are FAB's, RAB's, and all that junk. RMS
operates by assigning a channel to do I/O on at its own access mode,
executive. You, running in user mode, cannot get at that channel except using
RMS as your agent. (There is an RMS $OPEN option - UFO? - that requests that
RMS open the channel in user mode. Then, you can use the channel for QIO
access, but you can't do any RMS operations on it.) The reason RMS opens files
in exec mode is exactly to prevent you from mucking around with them, since
you have no access to RMS buffering or other state information. If you go
into exec mode and deassign a channel out from under RMS, it will get upset,
bugcheck, and your process will go away. Your system may also crash.
Among the services RMS provides is the ability to access files via directo-
ries. (Don't ask me why this is in RMS; it is.) At the QIO level, files
are accessed by file ID's. The interface between the two levels is provided
by a set of simple-minded directory access calls, described in pre-V4 docu-
mentation as "QIO access to the ACP". ACP's have now generally been replaced
by XQP's, but the interface is pretty much the same.
It is possible, but quite painful, to use the ACP calls to do file access.
These calls access one directory at a time; you have to climb down from the
root. However, you can, if you wish, make the QIO's asynchronous.
An RMS $OPEN does all that junk for you, and more. However, it does it
synchronously. Sorry. RMS also doesn't provide any general way to cancel
uncompleted I/O, except at image rundown. (Note, BTW, that rundown is NOT
usually a cancel, it's a flush.)
For network links, there is another level of access. You can use remote file
access, which goes through RMS. This is known as "transparent access". Or
you can use "non-transparent access". This level provides a message- passing
interface rather than a file-like interface. It's a lot more complex to use,
but for appropriate applications can provide a lot better performance.
There are even lower levels. You can do direct QIO's to the comm devices
(though you then lose DECnet). With a DEUNA or DEQNA on an Ether, you can
share the interface with DECnet and run your own protocol. And so on.
In your design, you will have to trade off the convenience of the RMS
facilities against the potentially higher performance of getting access to the
VMS I/O system at a lower level and producing an interface more closely
matched to your particular problem. RMS is a rather general interface, and
does very well for some kinds of things, not so well for others. The remote
file access facility is EXTREMELY convenient, but it isn't cheap to use.
TANSTAAFL.
-- Jerry
-------