<snip> For example, a STIMER REAL request expires. I.e. a "timer pops", which is set to drive some user code in the application. The STIMER has created an IRB. The timer pop has already saved the status of the running program in the RB, so the "pop code" uses the SCHEDIRB macro to schedule the IRB. This simply places the IRB onto the RB chain. When the TCB is next dispatched, the values in the IRB (regs & PSW) are loaded and the asynchronous exit runs. <e-snip>
This isn't really correct. The thought is pretty close. SCHEDIRB is not used by the system to schedule the IRB. And IRBs are never placed simply onto an RB chain. When the "timer pops", the system creates an IQE/IRB. The system queues that IQE/IRB to an address-space-related queue. The IQE/IRB has information that identifies to which TCB it applies. When the system goes to dispatch a TCB in an address space, it may look to see if there are IRB's pending for that space and, in particular, pending for that TCB. When there is a suitable IRB, that is when the IRB is placed onto the RB chain and the dispatch processing proceeds. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
