On Fri, Dec 30, 2016 at 7:42 AM, Peter Relson <[email protected]> wrote:
> <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. > Thanks. I use the STIMER REAL a lot, and was just blind guessing about the implementation. > > 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 > -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
