Re: Real return address for link and attach
In listserv%201107050830191626.0...@bama.ua.edu, on 07/05/2011 at 08:30 AM, Donald Likens dlik...@infosecinc.com said: This has all been interesting but I don't think my question has been answered (sorry if I missed it). Some said I could get the real return address in the save area trace but I do not think that is correct since the calling program saves the registers and R14 points to LINK(x) or ATTACH(x) when the calling program is called. No. As to the reference to LINK/Attach manuals it simply states that the registers are changed (I had already looked there). It didn't say what it did with the real R14. The return address in your control section is always the instruction following the LINK,; that is not, however, the address that the called load module receives in register 14. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
This has all been interesting but I don't think my question has been answered (sorry if I missed it). Some said I could get the real return address in the save area trace but I do not think that is correct since the calling program saves the registers and R14 points to LINK(x) or ATTACH(x) when the calling program is called. As for the PRB/SVRB discussion application programs run under a PRB. It was my understanding that attach returned to the OS but in my case I am seeing some pretty wierd things going on if the attached task ends immediately. As to the reference to LINK/Attach manuals it simply states that the registers are changed (I had already looked there). It didn't say what it did with the real R14. Any help is appreciated. -- 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
Re: Real return address for link and attach
On Tue, 5 Jul 2011 08:30:19 -0500, Donald Likens wrote: This has all been interesting but I don't think my question has been answered (sorry if I missed it). Some said I could get the real return address in the save area trace but I do not think that is correct since the calling program saves the registers and R14 points to LINK(x) or ATTACH(x) when the calling program is called. The calling program does not save the registers. When the processing of an RB is suspended, the PSW is stored in RBOPSW. LINK and ATTACH both cause an SVC interruption and the RB is suspended. Link creates a new RB. When that RB terminates with SVC 3, the previous RB resumes. ATTACH creates a new TCB and a new RB and returns control to the previous RB. Both TCBs are equally eligible to be dispatched. When the ATTACHed task terminates (SVC 3), task cleanup is performed. It does not return to the attaching task. As for the PRB/SVRB discussion application programs run under a PRB. Correct. Thanks to those who pointed out my error and especially to Shmuel who (I think) provided the best explanation of what happens. -- Tom Marchant -- 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
Re: Real return address for link and attach
Donald, You seem to be asking about what happens to the real R14, is that correct? How do you define real, If you are asking where the contents of R14 at the point the LINK(X) or ATTACH(X) macro is issued in the calling program are stored, the answer is simple, they aren't. Both of these macros (along with most other IBM defined macros) clearly document the contents of the registers when control returns to the caller. For ATTACH(X), R14 is used a work register by the system. For LINK(X), if the LINK(X) is successful, when the target program gets invoked, R14 will contain the return address, which will be the address of the SVC 3 instruction in the CVT. If the link fails, and an ERRET routine was coded, on entry to the ERRET, R14 was used as a work register by the system. Since the system uses R14 (most system macros use without saving Registers 14, 15, 0 and 1) if you care about the contents, it is the coder's responsibility to save them before issuing the macro, and restoring them after the macro expansion (and at any error points that the macro could pass control to). === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Donald Likens dlik...@infosecinc.com To: IBM-MAIN@bama.ua.edu Date: 07/05/2011 08:30 AM Subject: Re: Real return address for link and attach Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu This has all been interesting but I don't think my question has been answered (sorry if I missed it). Some said I could get the real return address in the save area trace but I do not think that is correct since the calling program saves the registers and R14 points to LINK(x) or ATTACH(x) when the calling program is called. As for the PRB/SVRB discussion application programs run under a PRB. It was my understanding that attach returned to the OS but in my case I am seeing some pretty wierd things going on if the attached task ends immediately. As to the reference to LINK/Attach manuals it simply states that the registers are changed (I had already looked there). It didn't say what it did with the real R14. Any help is appreciated. -- 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 -- 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
Re: Real return address for LINK and ATTACH
On July 4, Peter Relson corrected my misstatement that the application program invoked from EXEC PGM= is invoked by a LINK. Charlie Chan would have said foot in mouth come from rust in brain. I should have realized that it is invoked by ATTACH, since it runs under its own TCB, rather than an Initiator TCB. Shmuel Metz also rose to the occasion. Thanks, guys. Dale Miller -- 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
Re: Real return address for link and attach
On 5 July 2011 09:30, Donald Likens dlik...@infosecinc.com wrote: This has all been interesting but I don't think my question has been answered (sorry if I missed it). It's not so much that it hasn't been answered, but that the premises of your question have been denied. What you said originally was this: I have a situation where my subtask terminates and it seems it returns to somewhere in my program and starts executing my primary task (hard to believe isn't it). I want to check out my theory by determining in a dump where the attachx is going to return to after I execute the BR 14 (and return to attachx). Really this makes no sense, as others have pointed out at some length. Your subtask executes in parallel with your main task, except to the extent that you provide means for ensuring that only one runs at a time - something you have not mentioned doing. The subtask's register contents, other than perhaps R1 at entry, are unrelated to those of the main task. You also said: I would also like to know where LINK(LINKX) is returning to when I execute the BR 14 (and return to link). It has been pointed out to you that the BR 14 does not return to link, but to the operating system. LINK behaves on the surface very much as ATTACH does, except that execution of the program issuing the LINK stops, and does not resume until the LINKed to program returns to the operating system. Some said I could get the real return address in the save area trace but I do not think that is correct since the calling program saves the registers and R14 points to LINK(x) or ATTACH(x) when the calling program is called. I really don't know what you are trying to say, even if I try to parse it assuming there are minor typos of the sort we can all make. At entry to your subtask, R14 contains an OS-provided return address that is quite unrelated to the value in R14 at the time your main task issued the ATTACH. (We know that it normally points to an SVC 3 instruction in the CVT, but that is not a documented interface, though it has been that way since 1964 or so, so let's just stick with the idea that the OS provides the address of some code that will do all the right stuff to end your subtask.) You talk of the real return address, but it's not clear what you mean by this. It is utterly implausible that the OS is providing a wrong address in R14 when your subtask gets control. Either your subtask is returning to the address in R14 or it isn't. If it is, then the subtask will end, and various things will happen depending on some of the options on your ATTACH. If it isn't, because it lost or mangled the address, then it is going somewhere else, and executing some unknown code with unknown results, which could include - if things are really messed up - executing code that should be part of your main task. It was my understanding that attach returned to the OS but in my case I am seeing some pretty wierd things going on if the attached task ends immediately. Perhaps you could be specific about these weird things that are going on, and how your attached task ends immediately. As to the reference to LINK/Attach manuals it simply states that the registers are changed (I had already looked there). It didn't say what it did with the real R14. We're back to your notion of a real R14, and I don't think anyone here understands what you mean by that. I don't know if you are merely having trouble putting your question, or if you have some fundamental misconception about how the machine and the operating system work. Tony H. -- 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
Re: Real return address for link and attach
In listserv%201107011418256324.0...@bama.ua.edu, on 07/01/2011 at 02:18 PM, Donald Likens dlik...@infosecinc.com said: I have a situation where my subtask terminates and it seems it returns to somewhere in my program and starts executing my primary task (hard to believe isn't it). In fact, I don't believe it. Perhaps you specified an end-of-task exit. I want to check out my theory by determining in a dump where the attachx is going to return to after I execute the BR 14 (and return to attachx). You're confused. ATTACHX returns to the next sequential instruction as soon as it has added the new TCB to the task tree. R14 in the new task will point to CVTEXIT, a location in the CVT containing an SVC 3. When the subtask returns, the SVC 3 will handle end-of-task processing, including posting an ECB or calling an exit if the ATACHX so specified. I would also like to know where LINK(LINKX) is returning to when I execute the BR 14 (and return to link). Again, R14 will point to CVTEXIT. In this case SVC 3 will remove the new PRB and control will resume under the old PRB, following the LINK(X) macro invocation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In b282be35b5a4494894d4ecfba2bf7847180f25b...@xch-nw-17v.nw.nos.boeing.com, on 07/01/2011 at 12:38 PM, Schwarz, Barry A barry.a.schw...@boeing.com said: If an attached task has terminated, there should be nothing in your dump related to it. Depending on the options, the TCB will persist until you do a DETACH. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In listserv%201107011545301271.0...@bama.ua.edu, on 07/01/2011 at 03:45 PM, Paul Gilmartin paulgboul...@aim.com said: What do LINK and ATTACH respectively pass the child program as a save area pointer? As documented, LINK leaves R2-R13 alone. ATTACH creates a save area for the new task and puts its address in the subtask R13, while leaving the main tasks R13 alone. If the caller ATTACHes multiple subtasks, must it provide a separate save area for each? There's no way to do that. As documented, ATTACH(X) provides the new save area, not the caller. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In listserv%201107011533075067.0...@bama.ua.edu, on 07/01/2011 at 03:33 PM, Tom Marchant m42tom-ibmm...@yahoo.com said: LINK is an SVC and the linked program runs under control of an SVRB. No; SVC 6 creates a PRB for the linked program, and exits before the PRB receives control. The SVC will delete the SVRB The SVRB is freed before the linked program gets control. The SVC 3 from the linked program deletes the PRB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In 1c721f78-b08c-4846-a6d5-c7032f060...@comcast.net, on 07/02/2011 at 11:50 PM, Dale Miller dalelmil...@comcast.net said: In fact (unless this has been rewritten without my consent) programs executing as a result of EXEC PGM= are (normally?) invoked via LINK, and they run under a PRB (or used to). You're both wrong. While link creates a PRB, so does ATTACH, and the Initiator uses ATTACH for the jobstep program, not LINK. At least, that is how it worked from OS/360 R14 on. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In 1309697614.9025.31.ca...@dv7t.johnmckown.net, on 07/03/2011 at 07:53 AM, John McKown joa...@swbell.net said: As I recall, you have a program running on a PRB. It issues a LINK which runs on a SVRB (as do all type 3 and 4 SVCs). The LINK runs the requested program on a PRB. If you abend in the second, the dump will show the TCB (TCBRBP) pointing to the second PRB which points (RBLINKB) to the SVRB which points to the first PRB which points back to the TCB. That's closer, but when SVC 6 creates the new PRB it does not push it on the stack, but rather inserts it below the SVRB, so that EXIT processing for the SVRB will make the PRB current. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
In 1309724814.9025.41.ca...@dv7t.johnmckown.net, on 07/03/2011 at 03:26 PM, John McKown joa...@swbell.net said: This is what I see in my SYSUDUMP. It was not what I was expecting at all. PRB#1 runs pgm1 which issues SVC 6 (LINK) SVRB#1 is for SVC 0x33 SVRB#2 is for SVC 0x78 That says that there was a problem when the second program terminated. Note that you do not show an SVRB for the SVC 6. SVC 51 is the common dump routine for, e.g., SDUMP, SNAP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Real return address for link and attach
On July 1, Tom Marchant wrote: LINK is an SVC and the linked program runs under control of an SVRB. Since when? Perhaps everything has turned upside down while I was retiring, but my memory says that LINK results in the program running under a PRB. In fact (unless this has been rewritten without my consent) programs executing as a result of EXEC PGM= are (normally?) invoked via LINK, and they run under a PRB (or used to). Dale Miller -- 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
Re: Real return address for link and attach
As I recall, you have a program running on a PRB. It issues a LINK which runs on a SVRB (as do all type 3 and 4 SVCs). The LINK runs the requested program on a PRB. If you abend in the second, the dump will show the TCB (TCBRBP) pointing to the second PRB which points (RBLINKB) to the SVRB which points to the first PRB which points back to the TCB. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2d510/57.1.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2d310/211.1.1 On Sat, 2011-07-02 at 23:50 -0700, Dale Miller wrote: On July 1, Tom Marchant wrote: LINK is an SVC and the linked program runs under control of an SVRB. Since when? Perhaps everything has turned upside down while I was retiring, but my memory says that LINK results in the program running under a PRB. In fact (unless this has been rewritten without my consent) programs executing as a result of EXEC PGM= are (normally?) invoked via LINK, and they run under a PRB (or used to). Dale Miller -- 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 -- John McKown Maranatha! -- 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
Re: Real return address for link and attach
On 7/3/2011 8:53 AM, John McKown wrote: As I recall, you have a program running on a PRB. It issues a LINK which runs on a SVRB (as do all type 3 and 4 SVCs). The LINK runs the requested program on a PRB. If you abend in the second, the dump will show the TCB (TCBRBP) pointing to the second PRB which points (RBLINKB) to the SVRB which points to the first PRB which points back to the TCB. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2d510/57.1.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2d310/211.1.1 I strongly suspect that you're mistaken. LINK runs under an SVRB, builds a PRB for the desired program, and exits, causing its SVRB to be removed from the chain. In a dump you will see two consecutive PRBs. Old, old system code tends to be parsimonious, and once the lower PRB is built, there is no need for services requiring the SVRB. Gerhard Postpischil Bradford, VT -- 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
Re: Real return address for link and attach
You are likely correct. I'll try to remember to test this when I get a chance. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Jul 3, 2011 10:13 AM, Gerhard Postpischil gerh...@valley.net wrote: On 7/3/2011 8:53 AM, John McKown wrote: As I recall, you have a program running on a PRB. It iss... I strongly suspect that you're mistaken. LINK runs under an SVRB, builds a PRB for the desired program, and exits, causing its SVRB to be removed from the chain. In a dump you will see two consecutive PRBs. Old, old system code tends to be parsimonious, and once the lower PRB is built, there is no need for services requiring the SVRB. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / si... -- 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
Re: Real return address for link and attach
For LINK and ATTACH, the address in register 14 on entry to the target routine is in common storage and is the address of an SVC 3. As you expect, if your subtask terminates then it would not resume anywhere. Therefore one must suspect that it did not terminate, although it might have intended to. Peter Relson z/OS Core Technology Design -- 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
Re: Real return address for link and attach
This is what I see in my SYSUDUMP. It was not what I was expecting at all. PRB#1 runs pgm1 which issues SVC 6 (LINK) SVRB#1 is for SVC 0x33 SVRB#2 is for SVC 0x78 And that is all. No PRB or CDE for the second pgm at all. Which makes no sense because I added it using an IDENTIFY macro. I'm undoubtedly doing something wrong. On Sun, 2011-07-03 at 11:22 -0500, John McKown wrote: You are likely correct. I'll try to remember to test this when I get a chance. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Jul 3, 2011 10:13 AM, Gerhard Postpischil gerh...@valley.net wrote: On 7/3/2011 8:53 AM, John McKown wrote: As I recall, you have a program running on a PRB. It iss... I strongly suspect that you're mistaken. LINK runs under an SVRB, builds a PRB for the desired program, and exits, causing its SVRB to be removed from the chain. In a dump you will see two consecutive PRBs. Old, old system code tends to be parsimonious, and once the lower PRB is built, there is no need for services requiring the SVRB. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / si... -- 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 -- John McKown Maranatha! -- 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
Re: Real return address for link and attach
On Fri, 1 Jul 2011 14:18:25 -0500 Donald Likens dlik...@infosecinc.com wrote: :I have a situation where my subtask terminates and it seems it returns :to somewhere in my program and starts executing my primary task :(hard to believe isn't it). I want to check out my theory by determining :in a dump where the attachx is going to return to after I execute the BR :14 (and return to attachx). I would also like to know where LINK(LINKX) :is returning to when I execute the BR 14 (and return to link). Please :help. My guess is that the problem is that you are sharing storage without an interlock. Are you aware that the main task may run before the subtask completes? Are you sharing storage between the tasks? -- 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. -- 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
Real return address for link and attach
I have a situation where my subtask terminates and it seems it returns to somewhere in my program and starts executing my primary task (hard to believe isn't it). I want to check out my theory by determining in a dump where the attachx is going to return to after I execute the BR 14 (and return to attachx). I would also like to know where LINK(LINKX) is returning to when I execute the BR 14 (and return to link). Please help. -- 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
Re: Real return address for link and attach
If an attached task has terminated, there should be nothing in your dump related to it. The BR 14 in the task should branch to an operating system routine to post the ECB and perform the appropriate housekeeping. The only thing in your dump should be the ECB. The mother and daughter tasks both compete for execution time independently. The code following the ATTACH(X) macro can execute before or after any portion of the attached task. If you need the mother task to wait on the daughter, it is your responsibility to WAIT on the ECB. If a linked routine follows normal save area conventions, then in the save area you passed it in R13 you should be able to find the contents of R14. This is where the BR 14 instruction should return if you remembered to restore the registers before branching. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Likens Sent: Friday, July 01, 2011 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: Real return address for link and attach I have a situation where my subtask terminates and it seems it returns to somewhere in my program and starts executing my primary task (hard to believe isn't it). I want to check out my theory by determining in a dump where the attachx is going to return to after I execute the BR 14 (and return to attachx). I would also like to know where LINK(LINKX) is returning to when I execute the BR 14 (and return to link). Please help. -- 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
Re: Real return address for link and attach
On Fri, 1 Jul 2011 12:38:53 -0700, Schwarz, Barry A wrote: If an attached task has terminated, there should be nothing in your dump related to it. The BR 14 in the task should branch to an operating system routine to post the ECB and perform the appropriate housekeeping. The only thing in your dump should be the ECB. The exit from an ATTACH is SVC 3. BR 14 takes you to CVTEXIT. If the task was attached with the ECB= or EXTR= operands, it is not removed from virtual storage until a DETACH is issued. I've never looked at a dump at that point in time, but I think that means that the TCB is still there. If a linked routine follows normal save area conventions, then in the save area you passed it in R13 you should be able to find the contents of R14. This is where the BR 14 instruction should return if you remembered to restore the registers before branching. LINK is an SVC and the linked program runs under control of an SVRB. The return from the linked routine also takes you to CVTEXIT, which is an SVC 3 instruction. The SVC will delete the SVRB and return control to the RB that was active when the LINK was issued. -- Tom Marchant -- 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
Re: Real return address for link and attach
On Fri, 1 Jul 2011 15:33:07 -0500, Tom Marchant wrote: LINK is an SVC and the linked program runs under control of an SVRB. The return from the linked routine also takes you to CVTEXIT, which is an SVC 3 instruction. The SVC will delete the SVRB and return control to the RB that was active when the LINK was issued. What do LINK and ATTACH respectively pass the child program as a save area pointer? o The caller's R13? o Other (specify)? If the caller ATTACHes multiple subtasks, must it provide a separate save area for each? -- gil -- 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
Re: Real return address for link and attach
On Fri, 1 Jul 2011 15:45:30 -0500, Paul Gilmartin wrote: What do LINK and ATTACH respectively pass the child program as a save area pointer? I'm not sure about LINK. Attach always provides a 144-byte save area regardless of what was in the attaching program's r13. If the caller ATTACHes multiple subtasks, must it provide a separate save area for each? No. -- Tom Marchant -- 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
Re: Real return address for link and attach
On 7/1/2011 1:45 PM, Paul Gilmartin wrote: What do LINK and ATTACH respectively pass the child program as a save area pointer? o The caller's R13? o Other (specify)? The answer for LINK is fully documented. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a9b0/69.1.4 (Hint: R13 is unchanged.) If the caller ATTACHes multiple subtasks, must it provide a separate save area for each? The answer for ATTACH is fully documented. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7a0/5.1.8 (Hint: R13 points to a system-provided save area.) Please RTFM whenever possible before submitting a query to IBM-MAIN. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: Real return address for link and attach
On Fri, 1 Jul 2011 16:18:33 -0500, Tom Marchant m42tom- ibmm...@yahoo.com wrote: . . . Attach always provides a 144-byte save area . . . Not always. Not when SVAREA=NO specified and condition of supervisor state or system key met. -- 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
