More on asynch exits
-Original Message-
From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On
Behalf Of Automatic digest processor
Sent: Monday, March 16, 2009 12:04 AM
To: Recipients of ASSEMBLER-LIST digests
Subject: ASSEMBLER-LIST Digest - 14 Mar 2009 to 15 Mar 2009 (#2009-72)
There are 6 messages totalling 247 lines in this issue.
Topics of the day:
1. Asynchronous Exits:- How do they work? (5)
2. Asynchronous Exits:- How do they work? a followup question
--
Date:Sun, 15 Mar 2009 14:08:20 +0100
From:Abe Kornelis a...@bixoft.nl
Subject: Re: Asynchronous Exits:- How do they work?
Ludmil, Tom, all,
A small addition to Tom's original explanation:
IRBs are slightly different. When some function of the operating system
or some code you have written wants to interrupt the current TCB RB, it
creates an IRB (Interruption Request Block), and then calls the
operating system to queue the IRB to the RB chain.
**-- Be aware that the interrupt may be processed on one processor
while your TCB is executing on another one, That's why the TCB
and RB chain must be locked while adding to the queue. I think
it is the local lock that serves this purpose - but do double-check me
on that one as I'm doing this from memory.
If the TCB is
currently not running, then the IRB gets control immediately
**-- or rather, the next time the dispatcher elects the TCB for execution
(the
process represented by the IRB), and when the IRB completes, the TCB is
left in the same state as before.
**-- That is, after the IRB process completes, it returns to the OS
which will issue an SVC 3 to pop the IRB. The RB chain is then back
to its original state and the next dispatch of the TCB will resume the
executing RB where it last ended.
If the TCB was currently running, the
IRB is not actually dispatched until the TCB is interrupted for some
other reason.
**-- Exactly. The IRB is appended to the RB chain, but the RB executing
on behalf of the TCB will carry on, until it is interrupted itself.
Then,
as soon as the dispatcher next selects the TCB for execution on an
processor, it will find the new IRB on top of the RB chain, so the IRB
gets executed. When it ends, you get SVC 3 to pop the RB and again
the dispatcher will schedule the top RB - which might well be the RB
running when the IRB was first created. Other IRBs might have gotten
in between, though. Anyway, by the time your application RB regains
control, it will be in the usual way - and your app will never be able
to tell whether, where, or when it might have been interrupted.
The exceptional case is when the application RB issues SVC 3 before
the IRB has been scheduled. I do not know what happens in this case.
Could be SVC 3 logic will issue an abend. Or it might process the IRB
before popping the RB that issued SVC 3. It would be hard to imagine
SVC 3 would quietly pop any RB that is not on the top of the RB chain
and quietly discard any unfinished RBs on the chain...
Cheers,
Abe Kornelis.
=
--
Date:Sun, 15 Mar 2009 09:45:12 -0400
From:Jaya Relim jayare...@hotmail.com
Subject: Re: Asynchronous Exits:- How do they work? a followup question
Then as per your note, the state information is stored on the RB.
When ETXR gains control the TCB ID is in Reg1. Fine, I can use Reg1 to
detach the daughter. Then say before I do a BR 14, I need to use a few
regs, can I assume that their contents will be restored by system soon
after the BR 14, without me actually saving the Regs and restoring them.
Yes, but you do need to restore R14 (which should end up pointing to an
SVC3) or you could simply invoke SVC3 instead of BR14.
On Sat, 14 Mar 2009 19:19:11 -0400, Ludmila Koganer
ludmilakoga...@yahoo.com wrote:
Tom,
Thank You so Much for having taken time to clarify. I think I have a
follow up question. Say I have a ETXR on the main task. This gets control
at some time after the daughter ends.
ETXR gets control through a IRB. I follow upto this point clearly and also
the description about RBs in general.
Then as per your note, the state information is stored on the RB.
When ETXR gains control the TCB ID is in Reg1. Fine, I can use Reg1 to
detach the daughter. Then say before I do a BR 14, I need to use a few
regs, can I assume that their contents will be restored by system soon
after the BR 14, without me actually saving the Regs and restoring them.
As a followup, will this work if the main task was executing a
interruptible instruction like a MVCL which had Reg1 as one of its
operands.
If it is true that the system will always restore the current state prior
to the execution of IRB, then ETXR is the best practice to code, isnt it?
unless ofcourse the program really requires wait and post with ecb.
Thanks again for your time as well as others who replied.
I
