Re: Curious about ATTACH and 'SVCR 0'
The entry we are talking about is written when an SVRB terminates (and also for end of processing for such things as type 1 SVCs) Any record associated with a terminating PRB has nothing to do with this. When you're running your program and look at the RB structure, you'll see that the oldest RB is typically a PRB representing the attached task. But it wasn't always this way. When attach is done, the new task and it's oldest RB are created. This RB is an SVRB. It is under this SVRB that the program is fetched. At this point it is still the only RB. Now contents supervision creates the PRB to represent the fetched module. That would tend to make the RB structure look like (newer) PRB pointing to (older) SVRB. But the system re-orders so that the RB chain looks like (newer) SVRB pointing to (older) PRB. That is done so that when the SVRB ends, normal processing will work, which gets rid of the RB pointed to by TCBRBP and makes current the RB pointed to by that TCBRBP RB (and of course updates TCBRBP to match). Now that SVRB ends. As Barbara Nitz correctly pointed out, typically SVRB termination results in an SVCR trace entry. This is created by looking at the SVC's interrupt code (which was captured in the RB pointed to by the SVRB). At least usually. But here there was no SVC that produced the SVRB, the SVRB was just created. But that SVRB does pont to another RB, and the information in that RB is used. As there was no SVC and that PRB was initialized to 0's, the SVC interrupt code field is 0's, and that's why the SVCR trace entry is for SVC 0. And the PSW in the trace entry shows the address of the loaded program. I don't recall the original post mentioning that the anomalous trace entry not only is for SVC 0 but also indicates that it was issued at the entry point address of the program. 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: Curious about ATTACH and 'SVCR 0'
In listserv%200909210113422136.0...@bama.ua.edu, on 09/21/2009 at 01:13 AM, Barbara Nitz nitz-...@gmx.net said: The system trace table is showing a similar 'anomaly' when a tcb normally terminates. The application program (presumably executing under a PRB) does a BR 14 (or equivalent), and R14 points to the CVT, instruction OAOD (also appropriately called CVTEXIT, and I have always hated that there is no easy way to find out *what* program had just done the cvtexit!). That SVC 3 SVC 3 is 0A03; 0A0D is ABEND. I believe that CVTEXIT contains 0A03. -- 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: Curious about ATTACH and 'SVCR 0'
I am curious, too, how this is addressed in 1.10. (We're not there yet). Here is what I learned *why* this behaviour exists (narrowly looking at only tcbs): When the dispatcher dispatches any tcb, all it does for the system trace entry is take the WLIC's last two byte (from the RB pointed to by the TCB) and interpret it as an svc number. *That* is what you see in the system trace table, *if* the RB pointed to by the TCB is an SVRB! If the RB pointed to by the TCB is a PRB, the trace table usually shows a DSP entry (same as after an EXT entry, for instance). Attach getmains the storage that will become the TCB and the RB. Attach also clears that storage to hex zeroes. Once a freshly attached TCB gets dispatched, the WLIC field in the RB is hex zeroes. Hence the dispatcher generates an svcr 0 entry (as if the RB would return from svc0). Note also that the very first dispatch of a TCB is somewhere in attach code, and it is NOT a PRB that is pointed to by the TCB! The very first dispatch after attach is *always* an SVRB, hence the svcR entry in the trace table. The rest of the attach processing actually goes and turns that SVRB into a PRB. At which point the actual program that was 'attached' gets control. The system trace table is showing a similar 'anomaly' when a tcb normally terminates. The application program (presumably executing under a PRB) does a BR 14 (or equivalent), and R14 points to the CVT, instruction OAOD (also appropriately called CVTEXIT, and I have always hated that there is no easy way to find out *what* program had just done the cvtexit!). That SVC 3 shows up in the trace table. There never is an svcR 3 entry, in some cases the next RB down had done a link in the distant past, so svc 3 is followed by svcr 6. SVC interception works similarly in the sense how it shows up in system trace. Usually two SVC entries with the same number follow each other without a 'closing' SVCR for the same number in between. Depending on how the intercepting program gives control to the original SVC routine, it shows up differently in systrace, either as SVCR something or as a DSP entry. Now, Jim, where did I remember it wrong this time? :-) Best regards, Barbara Nitz PS: Reading a system trace table hold more suspense that any murder mystery! -- 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: Curious about ATTACH and 'SVCR 0'
You remembered the instruction wrong. 0A0D is the SVC for ABEND, not EXIT, which is 0A03. ABEND would be the only way to end a task normally in the Hosed System Architecture which I discussed at SHARE and CMG sessions in the early 1990s. :-) Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, September 21, 2009 1:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Curious about ATTACH and 'SVCR 0' ... The system trace table is showing a similar 'anomaly' when a tcb normally terminates. The application program (presumably executing under a PRB) does a BR 14 (or equivalent), and R14 points to the CVT, instruction OAOD (also appropriately called CVTEXIT, and I have always hated that there is no easy way to find out *what* program had just done the cvtexit!). That SVC 3 shows up in the trace table. There never is an svcR 3 entry, in some cases the next RB down had done a link in the distant past, so svc 3 is followed by svcr 6. ... Now, Jim, where did I remember it wrong this time? :-) -- 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: Curious about ATTACH and 'SVCR 0'
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 09/18/2009 04:41:28 AM: Re: Curious about ATTACH and 'SVCR 0' Steve Austin This is occuring on z/OS 1.10. Is there specific maintenance required? What type of entry will I see when the anomaly is addressed? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: 17 September 2009 19:38 To: IBM-MAIN@bama.ua.edu Subject: Re: Curious about ATTACH and 'SVCR 0' I believe that this anomaly has been addressed in z/OS 1.10. Peter Relson z/OS Core Technology Design I had forgotten the specific case that was addressed in z/OS 1.10, but after a bit of research, it turns out that it was for an IRB exiting. From some comments in the changed code: /* OTHERWISE IF IRB EXITING THEN */ /* TERMINATE IRB */ /* This return address will perform exit prologue and return to the dispatcher, but not create a System Trace SVCR record. Previously IEAVEXP1 was called which creates an SVCR record using SVC # in the current top RB (oftentimes Wait), but that is unrelated to the IRB and the current flow. Consideration was given to creating a SVCR record for SVC3 but this was deemed unnecessary as any SSRV System Trace records could be correctly identified as coming from this routine, and the next System Trace entry for this task will generally be a DSP record. @LHA*/ Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Curious about ATTACH and 'SVCR 0'
You remembered the instruction wrong. 0A0D is the SVC for ABEND, not EXIT, which is 0A03. ABEND would be the only way to end a task normally in the Hosed System Architecture which I discussed at SHARE and CMG sessions in the early 1990s. :-) Wow, someone's actually *reading* my ramblings! :-) Thanks for that correction. (I had just seen another dump, so 0A0D was stuck in my mind!) And thanks to Jim for telling us *what* got changed. I had forgotten about what the IRB case looks like in a trace table, but as that is one of those things that occur asynchronously, the trace entries are slightly unusual. Best regards, Barbara -- 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: Curious about ATTACH and 'SVCR 0'
This is occuring on z/OS 1.10. Is there specific maintenance required? What type of entry will I see when the anomaly is addressed? Thanks Steve -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: 17 September 2009 19:38 To: IBM-MAIN@bama.ua.edu Subject: Re: Curious about ATTACH and 'SVCR 0' I believe that this anomaly has been addressed in z/OS 1.10. 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 - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection system. - - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection system. - -- 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
Curious about ATTACH and 'SVCR 0'
Hello, I have noticed in a number of traces, that for a newly attached TCB there is a 'SVCR0' without a previous 'SVC 0'. Is this really a return from an EXCP SVC or something else masquerading as such? Thanks Steve - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection system. - -- 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
