On Mon, Jul 5, 2010 at 10:48 AM, Paul Gilmartin <paulgboul...@aim.com>wrote:
> On Mon, 5 Jul 2010 08:48:38 -0600, Robert Raicer wrote: > > > >You have it just about right. When the sole remaining RB for the TCB > >issues SVC-3 (EXIT), End of Task processing begins. This causes RTM > > > Does an RB issue SVC-3, or is it the task the RB dispatches that issues > SVC-3? All programs run under the control of an RB (there are several varieties of RB, but their differences are irrelevant as far as this discussion goes). RB's are queued on a TCB so it's a bit of a semantic nit to ask whether it is the task or the RB doing the thing. To be precise, the program that is currently running on the TCB (whether it's actually dispatched or not) is running under the control of the current RB. There may or may not be older (suspended) RBs chained up behind it. Each of those will in turn regain control when the RB ahead of it issues SVC 3. And as a piece of syntactic candy, z/OS and its ancestors always arrange it so that on entry to a new RB R14 contains the address of CVTEXIT, which in turn contains X'0A03' which is (drum roll please....) "SVC 3". So the program can exit by saving the address in R14 and "returning" there just like any other program, or it can simply issue SVC 3. > Does the RB remain once it has caused the task to be dispatched? > I would have exepected it would be removed from the queue; deleted. > The RB remains "in control" until either; it completes its processing and issues SVC 3, or it is suspended and replaced by another RB, e.g. via a LINK macro. In the latter case the RB will remain suspended until all of the RBs ahead of it have terminated via SVC 3. The RB is basically (part of) the place where the system saves state when it needs to run another program, e.g. when the current RB issues a LINK macro. > Would it be clearer to say that "When a task issues SCV-3 and no > undispatched RBs remain on its queue ..."? > not really. The task terminates when the last remaining RB issues SVC 3. By definition there cannot be any undispatched RBs remaining on the queue. RTM will take care of that behind the scenes for a task that manages to abend itself into oblivion. > What happens if a task issues SVC-3 while further RBs remain queued? > What SVC 3 really does is terminate the current RB and returns control to the previous RB, so basically "nothing special happens, the previous RB resumes execution". It is only when there are NO remaining RBs that the task gets driven through EOT. > My uncertainty about the SVC number arose when I was unable to find > "EXIT" in "z/OS V1R10.0 MVS Assembler Services Reference ABE-HSP". > Is there no actual service with this name? > Correct, there is no actual service with the name "EXIT". Never has been. Amazing huh? > > >When the ATTACHed module is initially entered, GPR 14 contains the > >address to which it is to branch upon its completion, i.e., this is > >the "Return Address". While not part of the documented programming > >interface, this address is generally the address of an SVC 3 > >instruction contained in the CVT (field CVTEXIT). > > > Are you saying that it is unsupported for a module entered by ATTACH > to exit via R14? Or merely that it is not guaranteed that a module > can CLC 0(2,14),=x'0A03' to determine that it was entered by ATTACH? > <http://bama.ua.edu/archives/ibm-main.html> > No you cannot determine whether you were entered via ATTACH (at least not in that way). R14 will point to CVTEXIT on initial dispatch after an ATTACH, but it will also contain that value on entry for a SYNCH, or a LINK or a XCTL macro and also, in the case where an IRB is scheduled to the task. The interface for SVCs that have RBs (type 2, 3 and 4) is more complicated. The net of it all is, if you needed to know the circumstances in which you were exiting, you could usually determine it programmatically but not by making the above mentioned comparison. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
