An IRB is an RB while an SRB, despite the name, is not. An SRB oes away once it is dispatched; a page fault schedules a new SRB to resume once the page is read in.
GY28-6659-7, OS Release 21. 7 - IBM System/360 Operating System - MVT Supervisor - Program Number 360S-CI-535, GY28-6659-7, SERVICES INDIRECTLY RELATED TO A TASK CONTROL BLOCK, pp. 43-44, at <https://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/plm/GY28-6659-7_MVT_Supervisor_PLM_Rel_21.7_May73.pdf#page=63> and SCHEDULING A USER EXIT ROUTINE, pp. 64-67 at <...#page=84>, provides a good description that is till relevant to z/OS, although some details have changed. ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Tom Brennan <[email protected]> Sent: Sunday, September 17, 2023 1:58 AM To: [email protected] Subject: Re: Why it's important to take Seymour's advice I've never written code that runs as an SRB, but over the years I've read about them and seen them in action, such as Omegamon poking code into other address spaces to grab data or do things like zap memory. So my simple understanding is an SRB is code that once scheduled, gets run first when the dispatcher comes back around to that address space, and then (I assume) is removed once it has done its work. So what's an IRB - Interrupt Request Block? I've heard the name but know nothing about it other than the manual mentions Asynchronous Exits, but doesn't seem to go into the details. So are we talking about code that gets executed sometime during interrupt processing, such as when an I/O interrupt occurs? On 9/15/2023 10:54 PM, Michael Stein wrote: > On Fri, Sep 15, 2023 at 06:16:59PM -0400, Joseph Reichman wrote: >> I did schedule the irb in the ikjeft01 TCB against Seymour's advice >> for a return code of zero from schedirb > > There are likely many ways to do something like what you are trying > to do and the IRB idea likely wasn't close to the best, however: > > * if you have a test system at your disposal where a dump or crash > won't hurt others > > * and you have the time to do a bit of exploring and learning > > I don't see it as bad, unless you don't learn from it. > >> However the TMP Estae issued an SDUMP > > Which is what I'd expect if the code the IRB tried to run had any sort > of problem (program check? abend?). The resulting abend will be passed > to that tasks (IKJEFT01) ESTAE and most likely it has no idea what to > do about it. So it took a dump and likely got the RB chain for that > task cleaned up (or terminated the task?). > >> I guess it didn't like me scheduling an irb in its TCB > > No, my best guess is that IKJEFT01 has no idea anyone would do such > a thing. And if the IRB code ran and terminated normally the IRB would > go away and IKJEFT01 would still be there and would never know. > > Go read the dump and figure out what happened... > > Find the IJKEFT01 TCB and it's RB chain. Does it show an IRB on the > chain? Where do the PSWs in the RBs on the chain point? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
