Re: RBOPSW question
Try using the field. Live and learn. On Thu, 3 Dec 2020 15:21:24 -0500 Joseph Reichman wrote: :>EXTENDED CONTROL PSW FROM THE RB :>LEVEL OR LINKAGE STACK LEVEL WHICH :>CREATED THE ESTAE EXIT AT THE TIME IT :>LAST INCURRED AN INTERRUPT OR 0 FOR :>ESTAI. OR PSW USED TO GIVE FRR :>CONTROL :> :> :>Trying to understand this Text this PSW SDWAEC2 is The from the RB which :>created the ESTAE I guess my PRB :>It says at the time it last incurred interrupt (that interrupt was caused by :>SDWARBAD ? ) :> :>-Original Message- :>From: IBM Mainframe Discussion List On Behalf Of :>Binyamin Dissen :>Sent: Thursday, December 3, 2020 2:56 PM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: RBOPSW question :> :>SDWAEC2 :> :>On Thu, 3 Dec 2020 11:56:04 -0500 Joseph Reichman :>wrote: :> :>:>This question is related to recovery routines :> :>:>In the case there is SDWARBAD and SDWANAME is not there :> :>:>So for example my program abended in a SVC :> :>:>So RBOPSW is somewhere in that SVC :> :>:>The rbregs should be my program :> :>:>But my question is would I have an address or could I determine from what :>address in my program I called the SVC -- Binyamin Dissen 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
I appreciate your help regarding what SDWARBAD represents I recall having an abend in a metal C program Which I linked to it may well have been running in supervisor state but it was a user Program I am just trying to just trying to determine the case where the abend happened in a supervisor state program which is not mine ( where I could of passed bad parameters or didn’t hold a required lock ) Since my program is erroneous it would be helpful to know what piece of my code called it Thanks > On Dec 5, 2020, at 9:45 AM, Peter Relson wrote: > > Shmuel and Lennie and I took the time to provide the correct answer. You > apparently choose to ignore. Sad. > > SDWARBAD is valid only for supervisor state cases, as the comment says. > SDWANAME is never valid for that case. If a type 2/3/4 SVC routine blew > up, the RB address will be the address of the RB under which that routine > was running (which will be a newer RB than the RB that issued the SVC; it > is not necessarily the next-newer one for a case where the SVC routine > itself issued an SVC of some sort and that secondary SVC is what abended). > So you still need to find the RB that issued the SVC in order to see the > address of the issuer and the next-newer RB to see the regs at time of > issuance. If you issued a type 1 SVC, things are different. > > IBM would decline an RFE for providing the time-of-last-interrupt regs in > the SDWA which, at best are difficult to explain and use. You of course > are welcome to submit it. > We thought about the value of that when we designed 64-bit support. The > value was insufficient to warrant the cost (and extra storage usage -- and > yes that matters both in terms of just getting the storage and for having > room within the dump header). > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
Shmuel and Lennie and I took the time to provide the correct answer. You apparently choose to ignore. Sad. SDWARBAD is valid only for supervisor state cases, as the comment says. SDWANAME is never valid for that case. If a type 2/3/4 SVC routine blew up, the RB address will be the address of the RB under which that routine was running (which will be a newer RB than the RB that issued the SVC; it is not necessarily the next-newer one for a case where the SVC routine itself issued an SVC of some sort and that secondary SVC is what abended). So you still need to find the RB that issued the SVC in order to see the address of the issuer and the next-newer RB to see the regs at time of issuance. If you issued a type 1 SVC, things are different. IBM would decline an RFE for providing the time-of-last-interrupt regs in the SDWA which, at best are difficult to explain and use. You of course are welcome to submit it. We thought about the value of that when we designed 64-bit support. The value was insufficient to warrant the cost (and extra storage usage -- and yes that matters both in terms of just getting the storage and for having room within the dump header). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
RFE sorry > On Dec 4, 2020, at 12:55 PM, Joseph Reichman wrote: > > You are correct the 64 bit section which has the 128 bit PSW and 64 bit regs > has only the error at time of error not SDWASR00 and SDWASEC2 info wish it > would > > This would be my RFA though the SDWA is big and doesn’t seem to have extra > room > >>> On Dec 4, 2020, at 12:48 PM, Tony Harminc wrote: >>> >>> On Fri, 4 Dec 2020 at 08:47, Joseph Reichman wrote: >>> >>> So to me the way to determine this is look at SDWAEC1 is this in your >>> program ? >>> >>> How would I know this ( talking to my self) >>> Well if the abending RB is a PRB RBTAB1 == zeros >>> Then if RBCDE1 not = zeros get CDE get CDXLJMP extent list and using >>> CDENTPT and module length from xtent list you can >>> determine if the abend is your program >> >> Thing is, there are (at least) two definitions of "in your program": >> 1) the address of the offending instruction is within your code, >> 2) the thread of execution under which the offending instruction was >> executed is that under which your program executes. >> >> Your proposed test will give you the answer to (1), but that may or >> may not be the answer you need. For example, anyone operating under >> any thread of execution can take a (wild or intended) branch to code >> in LPA, or unprotected CSA, or unprotected private storage in your >> address space. In which case discovering that the failure occurred "in >> your program(1)" will at best be wrong, and at worst will mislead you >> as to the cause. >> >> In passing, while I'm not current on this, I believe that the >> traditional way of examining the CDE/XL structures will not support >> code that was either loaded from a UNIX file, or is located in 64-bit >> storage. Even if you don't care about these cases you/your debugging >> code should probably check for them before announcing conclusions. >> >> Tony H. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
You are correct the 64 bit section which has the 128 bit PSW and 64 bit regs has only the error at time of error not SDWASR00 and SDWASEC2 info wish it would This would be my RFA though the SDWA is big and doesn’t seem to have extra room > On Dec 4, 2020, at 12:48 PM, Tony Harminc wrote: > > On Fri, 4 Dec 2020 at 08:47, Joseph Reichman wrote: > >> So to me the way to determine this is look at SDWAEC1 is this in your >> program ? >> >> How would I know this ( talking to my self) >> Well if the abending RB is a PRB RBTAB1 == zeros >> Then if RBCDE1 not = zeros get CDE get CDXLJMP extent list and using CDENTPT >> and module length from xtent list you can >> determine if the abend is your program > > Thing is, there are (at least) two definitions of "in your program": > 1) the address of the offending instruction is within your code, > 2) the thread of execution under which the offending instruction was > executed is that under which your program executes. > > Your proposed test will give you the answer to (1), but that may or > may not be the answer you need. For example, anyone operating under > any thread of execution can take a (wild or intended) branch to code > in LPA, or unprotected CSA, or unprotected private storage in your > address space. In which case discovering that the failure occurred "in > your program(1)" will at best be wrong, and at worst will mislead you > as to the cause. > > In passing, while I'm not current on this, I believe that the > traditional way of examining the CDE/XL structures will not support > code that was either loaded from a UNIX file, or is located in 64-bit > storage. Even if you don't care about these cases you/your debugging > code should probably check for them before announcing conclusions. > > Tony H. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
On Fri, 4 Dec 2020 at 08:47, Joseph Reichman wrote: > So to me the way to determine this is look at SDWAEC1 is this in your program > ? > > How would I know this ( talking to my self) > Well if the abending RB is a PRB RBTAB1 == zeros > Then if RBCDE1 not = zeros get CDE get CDXLJMP extent list and using CDENTPT > and module length from xtent list you can > determine if the abend is your program Thing is, there are (at least) two definitions of "in your program": 1) the address of the offending instruction is within your code, 2) the thread of execution under which the offending instruction was executed is that under which your program executes. Your proposed test will give you the answer to (1), but that may or may not be the answer you need. For example, anyone operating under any thread of execution can take a (wild or intended) branch to code in LPA, or unprotected CSA, or unprotected private storage in your address space. In which case discovering that the failure occurred "in your program(1)" will at best be wrong, and at worst will mislead you as to the cause. In passing, while I'm not current on this, I believe that the traditional way of examining the CDE/XL structures will not support code that was either loaded from a UNIX file, or is located in 64-bit storage. Even if you don't care about these cases you/your debugging code should probably check for them before announcing conclusions. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
Good idea saw presentation. Share 2010 Vic Gottwald how to write your first Estae would like to see how to debug when SDWARBAD is available > On Dec 4, 2020, at 9:29 AM, Seymour J Metz wrote: > > This thread has suggested to me a broader question: has Mr. Ng or someone > else updated his Share diagnostics presentations for z/OS? That would be a > great resource to point people to. > > Debugging can be a "bicycle problem"; there are things that are easy to do > but hard to teach. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Peter Relson [rel...@us.ibm.com] > Sent: Friday, December 4, 2020 8:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RBOPSW question > > If you want to find "what address issued the SVC", the answers are what > Shmuel and Lennie mentioned > > -- for a type 2/3/4 SVC, follow the RB chain from new to old until you > find the RB that issued the SVC (the SVC number is in the RB prefix). > or > -- look in the system trace > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
This thread has suggested to me a broader question: has Mr. Ng or someone else updated his Share diagnostics presentations for z/OS? That would be a great resource to point people to. Debugging can be a "bicycle problem"; there are things that are easy to do but hard to teach. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Friday, December 4, 2020 8:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RBOPSW question If you want to find "what address issued the SVC", the answers are what Shmuel and Lennie mentioned -- for a type 2/3/4 SVC, follow the RB chain from new to old until you find the RB that issued the SVC (the SVC number is in the RB prefix). or -- look in the system trace Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
I got an abend yesterday and I’m focusing on the situation if I have SDWARBAD as opposed SDWANAME If noticed when doing links to a module that I sometimes I get a RB address as opposed to a program name. So it’s not necessarily true if the SDWA has an RB instead of a program name that the abend occurred In a z/os module right ? So to me the way to determine this is look at SDWAEC1 is this in your program ? How would I know this ( talking to my self) Well if the abending RB is a PRB RBTAB1 == zeros Then if RBCDE1 not = zeros get CDE get CDXLJMP extent list and using CDENTPT and module length from xtent list you can determine if the abend is your program Hope this makes sense Thanks > On Dec 4, 2020, at 8:26 AM, Peter Relson wrote: > > If you want to find "what address issued the SVC", the answers are what > Shmuel and Lennie mentioned > > -- for a type 2/3/4 SVC, follow the RB chain from new to old until you > find the RB that issued the SVC (the SVC number is in the RB prefix). > or > -- look in the system trace > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
If you want to find "what address issued the SVC", the answers are what Shmuel and Lennie mentioned -- for a type 2/3/4 SVC, follow the RB chain from new to old until you find the RB that issued the SVC (the SVC number is in the RB prefix). or -- look in the system trace Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
I usually look in the system trace for that information. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 03 December 2020 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RBOPSW question I know for sure I’m going to say something stupid but the PRB for my program is when the program started I’ll look at it up thanks > On Dec 3, 2020, at 12:06 PM, Seymour J Metz wrote: > > From force of habit, I normally look at the RB chain. The PRB for your > program contains the PSW and the SVRB for for the SVC contains the registers. > If you can find a copy of Jerry Ng's excellent diagnostic presentation at > Share, I suggest that you read it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Joseph Reichman [reichman...@gmail.com] > Sent: Thursday, December 3, 2020 11:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RBOPSW question > > Hi > > This question is related to recovery routines > > In the case there is SDWARBAD and SDWANAME is not there > > So for example my program abended in a SVC > > So RBOPSW is somewhere in that SVC > > The rbregs should be my program > > But my question is would I have an address or could I determine from > what address in my program I called the SVC > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
EXTENDED CONTROL PSW FROM THE RB LEVEL OR LINKAGE STACK LEVEL WHICH CREATED THE ESTAE EXIT AT THE TIME IT LAST INCURRED AN INTERRUPT OR 0 FOR ESTAI. OR PSW USED TO GIVE FRR CONTROL Trying to understand this Text this PSW SDWAEC2 is The from the RB which created the ESTAE I guess my PRB It says at the time it last incurred interrupt (that interrupt was caused by SDWARBAD ? ) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Thursday, December 3, 2020 2:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RBOPSW question SDWAEC2 On Thu, 3 Dec 2020 11:56:04 -0500 Joseph Reichman wrote: :>This question is related to recovery routines :>In the case there is SDWARBAD and SDWANAME is not there :>So for example my program abended in a SVC :>So RBOPSW is somewhere in that SVC :>The rbregs should be my program :>But my question is would I have an address or could I determine from what address in my program I called the SVC -- Binyamin Dissen 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
SDWAEC2 On Thu, 3 Dec 2020 11:56:04 -0500 Joseph Reichman wrote: :>This question is related to recovery routines :>In the case there is SDWARBAD and SDWANAME is not there :>So for example my program abended in a SVC :>So RBOPSW is somewhere in that SVC :>The rbregs should be my program :>But my question is would I have an address or could I determine from what address in my program I called the SVC -- Binyamin Dissen 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
I know for sure I’m going to say something stupid but the PRB for my program is when the program started I’ll look at it up thanks > On Dec 3, 2020, at 12:06 PM, Seymour J Metz wrote: > > From force of habit, I normally look at the RB chain. The PRB for your > program contains the PSW and the SVRB for for the SVC contains the registers. > If you can find a copy of Jerry Ng's excellent diagnostic presentation at > Share, I suggest that you read it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Joseph Reichman [reichman...@gmail.com] > Sent: Thursday, December 3, 2020 11:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RBOPSW question > > Hi > > This question is related to recovery routines > > In the case there is SDWARBAD and SDWANAME is not there > > So for example my program abended in a SVC > > So RBOPSW is somewhere in that SVC > > The rbregs should be my program > > But my question is would I have an address or could I determine from what > address in my program I called the SVC > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
>From force of habit, I normally look at the RB chain. The PRB for your program >contains the PSW and the SVRB for for the SVC contains the registers. If you >can find a copy of Jerry Ng's excellent diagnostic presentation at Share, I >suggest that you read it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Thursday, December 3, 2020 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RBOPSW question Hi This question is related to recovery routines In the case there is SDWARBAD and SDWANAME is not there So for example my program abended in a SVC So RBOPSW is somewhere in that SVC The rbregs should be my program But my question is would I have an address or could I determine from what address in my program I called the SVC Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
