David Peterson from Candle Corporation has published an article in the last two issues of the Candle Computer Report detailing asynchronous processing in MVS. He covered the same material here in some more detail.
An IRB is a control block that represents an asynchronous exit in MVS. Stock application programs are represented as PRBs. When MVS transfers control to a user task, it walks through an RB chain. The presence of an IRB causes MVS to dispatch the associated asynchronous exit rather than the application code pointed to by the PRB.
He talked about how you get an IRB queued on the RB chain and why you would want to do such a thing at all. (Turns out that VTAM is a heavy user of the CIRB facility. When a VTAM request completes, the usual VTAM response is to schedule an asynchronous exit in the task that issued the request to begin with.
I'll be able to use this information in my rewrite of the storage allocator in RJE3270. One of the problems I had was that the VTAM asynchronous exits in NRJE share the same data areas as the mainline code. I didn't want to be executing storage allocation in mainline code, then be interrupted by a VTAM exit that needed to execute storage allocation - this would make a BIG mess.
One solution might be to have storage allocation disable asynchronous exits. This can be done by setting bit TCBFX. I think.