Generally you don't do that. The paradigm is different.

Since all of VMS' I/O is potentially asynchronous (and the cluster locking mechanism is considered I/O, of a sort) and you can attach a custom callback and one piece of custom data to each I/O request, as well as wait for one of a set of general "event done" bits to be set. What's generally done is either:

• Your callback routine initiates the next stage of the task. This is common in bulk copy code such as the VMS backup program--each completed read request has an AST that initiates a write request for the data read, and each completed write request initiates a read for the next chunk. Get a few of these in flight simultaneously and it's easy to get a lot of throughput.
• Your callback inserts a chunk of data into an AST/interrupt/threadsafe queue (and the system has these) and pings the "event done" bit, at which time the mainline code wakes up, drains the queue, then goes back to sleep waiting on the bit again. This is something like select, only sucks much less.

The whole "waiting for input & output & stalling" case generally doesn't arise since there's no sync I/O going on. Unfortunately it is a bit more complex than plain sync I/O.