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 am usually scared to experiment without knowing how they work. Your
>explanation opened up thoughts in me.
>Perhaps I will write my first etxr code Monday.
>Thank you
>
>Ludmil
------------------------------
Date: Sun, 15 Mar 2009 16:28:14 -0400
From: "Robert A. Rosenberg" <a...@rarpsl.com>
Subject: Re: Asynchronous Exits:- How do they work?
At 14:08 +0100 on 03/15/2009, Abe Kornelis wrote about Re:
Asynchronous Exits:- How do they work?:
>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...
I think SVC 3 removes the CURRENT RB and thus can connect an IRB
above the current RB to the RB below it. I seem to have the
impression that the RBs are on a double linked chain and thus you can
remove an RB from the middle of the chain by just moving the forward
and backward links to the respective RB's link fields.
------------------------------
Date: Sun, 15 Mar 2009 23:43:23 +0200
From: Binyamin Dissen <bdis...@dissensoftware.com>
Subject: Re: Asynchronous Exits:- How do they work?
On Sun, 15 Mar 2009 16:28:14 -0400 "Robert A. Rosenberg" <a...@rarpsl.com>
wrote:
:>At 14:08 +0100 on 03/15/2009, Abe Kornelis wrote about Re:
:>Asynchronous Exits:- How do they work?:
:>>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...
:>I think SVC 3 removes the CURRENT RB and thus can connect an IRB
:>above the current RB to the RB below it.
?????
SVC 3 removes the current RB and makes the previous RB active (if one exists)
or terminates the task (if one does not).
:> I seem to have the
:>impression that the RBs are on a double linked chain and thus you can
:>remove an RB from the middle of the chain by just moving the forward
:>and backward links to the respective RB's link fields.
RB's have a single link (AFAIK) and while I have tried all sorts of tricks, I
have never tried removing an RB in the middle of the chain.
--
Binyamin Dissen <bdis...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
------------------------------
Date: Sun, 15 Mar 2009 18:00:14 -0700
From: Edward Jaffe <edja...@phoenixsoftware.com>
Subject: Re: Asynchronous Exits:- How do they work?
Binyamin Dissen wrote:
> RB's have a single link (AFAIK) and while I have tried all sorts of tricks, I
> have never tried removing an RB in the middle of the chain.
>
When you issue SVC 6, an SVRB is created to run the LINK SVC. A PRB gets
created after the LINK SVRB. Then, the SVRB is removed.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
------------------------------
Date: Sun, 15 Mar 2009 21:06:14 -0500
From: John McKown <joa...@swbell.net>
Subject: Re: Asynchronous Exits:- How do they work?
On Sun, 15 Mar 2009, Edward Jaffe wrote:
> Binyamin Dissen wrote:
> > RB's have a single link (AFAIK) and while I have tried all sorts of tricks,
> > I
> > have never tried removing an RB in the middle of the chain.
> >
>
> When you issue SVC 6, an SVRB is created to run the LINK SVC. A PRB gets
> created after the LINK SVRB. Then, the SVRB is removed.
>
> --
> Edward E Jaffe
Does the XCTL do something similar? Or does it act more like the LINK by
creating a PRB after the SVRB, then removing the SVRB and the previous RB?
I.e. does it "reuse" the current RB or a "new" one? I guess that I could
test that by writing a program which finds its own RB, and does an XCTL to
itself, passing the address of its RB and then compare that RB pointer
with the current RB pointer. I'd need to figure out how to determine if
this was the initial RB or the XCTL'ed to RB, however. Hum ...
Just curious.
--
Q: What do theoretical physicists drink beer from?
A: Ein Stein.
Maranatha!
John McKown
------------------------------
End of ASSEMBLER-LIST Digest - 14 Mar 2009 to 15 Mar 2009 (#2009-72)
********************************************************************
