Re: Hints needed on abend 0D6-027
Thanks to everyone for their responses, things are much clearer now. The original coder obviously decided to save resources by shutting down the auxiliary ASID after an inactivity period, thus storing up trouble. Hopefully I can reduce the window where the abend can occur; there is already an abend exit, modifying that to suppress the dump should mitigate most of the grief. Thanks, guys -Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 26 August 2013 08:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Hints needed on abend 0D6-027 All of the responses have been on target. One point in the original post was not addressed: The PC number we are calling is X'00017F00' which implies an ET index of X'F00'; is that sane? Nope, this implies an ET index of x'00'. The Entry Index in a PC number is 8 bits. The LX is 17F. The Linkage Index ranges from 12 bits to 24, depending on the availability of the reusable ASN and LX facility (z/OS supports only up to an LX of 16 bits, but does let you indicate that your application supports up to 24 by the LXSIZE operand of LXRES). As was posted, it is probably not possible to fully prevent this abend. A well-written application will make the likelihood as small as possible by having the PC number (or at least the LX) contained in some control block that the PC issuer checks before issuing the PC (to see is the target still available) -- load the LX/PC, check it, and proceed only if it appears valid -- and that the terminating application changes to a value understood by the PC issuer as target is not available as far as possible before termination gets to the point of the invalidation of the LX (a similar protocol involves some availability bit owned by the application that gets tested prior to issuing the PC) 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: Hints needed on abend 0D6-027
All of the responses have been on target. One point in the original post was not addressed: The PC number we are calling is X'00017F00' which implies an ET index of X'F00'; is that sane? Nope, this implies an ET index of x'00'. The Entry Index in a PC number is 8 bits. The LX is 17F. The Linkage Index ranges from 12 bits to 24, depending on the availability of the reusable ASN and LX facility (z/OS supports only up to an LX of 16 bits, but does let you indicate that your application supports up to 24 by the LXSIZE operand of LXRES). As was posted, it is probably not possible to fully prevent this abend. A well-written application will make the likelihood as small as possible by having the PC number (or at least the LX) contained in some control block that the PC issuer checks before issuing the PC (to see is the target still available) -- load the LX/PC, check it, and proceed only if it appears valid -- and that the terminating application changes to a value understood by the PC issuer as target is not available as far as possible before termination gets to the point of the invalidation of the LX (a similar protocol involves some availability bit owned by the application that gets tested prior to issuing the PC) 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: Hints needed on abend 0D6-027
He's absolutely right. I had this problem with our Multi-System notification product and it drove me nuts for a while. My final solution, and it has worked perfectly for over 18 months now, was to create a NTOK and fill it with stuff I wanted to pass between all of the pieces, and when I was going to terminate, I updated the area, then gave myself 7 seconds before I actually ended the owning space to give the other pieces time to see that something was about to change. It's very efficient, and using the NTOK is negligeable overhead. At shutdown, no one complains about the extra 7 seconds, especially since I put out a message telling them about it and it also gives me the ability to stop the shutdown if something important is going on. It's one extra little thing to worry about, but it's far better than having 200+ sites complain about the ABEND. :) Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hints needed on abend 0D6-027
Our application very occasionally (once every few months) abends 0D6-027, which means a PC instruction has caused a Linkage second index translation exception. I am wondering exactly what this is telling me since the auxiliary ASID being PCed to had been active for some time and had processed several requests, ie, the PC had been working perfectly well up until the abend. So what has gone bad? My understanding is that the PC linkage information is kept in system control blocks so that should be OK. The PC number we are calling is X'00017F00' which implies an ET index of X'F00'; is that sane? Any hints gratefully received! Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hints needed on abend 0D6-027
In my experience a S0D6-027 implies that the LX owning address space has terminated (normally or abnormally) but the program(s) issuing PC instructions to that LX continue. I would review your design for terminating the LX owning address space and stopping the PC calls. A simple test case that I use is to cancel the LX owner while driving the programs that would issue the PC calls. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series™ www.kr-inc.com (312)574-0007 On 8/23/2013 06:46 AM, Robin Atwood wrote: Our application very occasionally (once every few months) abends 0D6-027, which means a PC instruction has caused a Linkage second index translation exception. I am wondering exactly what this is telling me since the auxiliary ASID being PCed to had been active for some time and had processed several requests, ie, the PC had been working perfectly well up until the abend. So what has gone bad? My understanding is that the PC linkage information is kept in system control blocks so that should be OK. The PC number we are calling is X'00017F00' which implies an ET index of X'F00'; is that sane? Any hints gratefully received! Robin -- 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: Hints needed on abend 0D6-027
Program calls (PC) is a Z/Architecture feature that has a z/OS server, PCAUTH, ASID 2 to administer it. The ETCON, ETDES, ETDIS, and ETDEF macros are the primary interfaces into that server. It's the first PC numbers defined in the system during IPL in the range of 0 to x. Chapter 5, Program Execution, Subchapter PC Number Translation in Principles of Operations has an excellent description of how PC numbers are defined. And you are right, PCAUTH maintains these system level control blocks (actually hardware defined) in the PCAUTH 31 bit LSQA (has to be fixed real storage). The hardware provides the ability to disable any lookup in these tables by setting the high order bit to 1 in any of these tables. When an address space terminates or it issues an ETDIS or ETDES for the LX, the PCAUTH server is called and it disables any references to the LX This results in a LSX-Translation exception, X'0027' which is translated to a 0D6-027. This is a very simplified explanation of what is in the POM. So why are you getting a 0D6-27? Because the PC defining address space has terminated or disconnected the LX. When the PC defining address space is terminating or just before issuing its LX disconnect, it could indicate so by setting some bit in a commonly addressable control block. This bit could then be turned off when reinitializes and it reconnects the LX. This greatly reduces the likelihood of the D6-027 but it is impossible to completely eliminate it entirely (though the probability is astronomically small). No matter how close to the call that you place the test, the caller could get suspended and the address space could terminate still resulting in a D6-027. So the code should also recognize a D6-027 as an indication that the served has terminated. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Atwood Sent: Friday, August 23, 2013 6:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Hints needed on abend 0D6-027 Our application very occasionally (once every few months) abends 0D6-027, which means a PC instruction has caused a Linkage second index translation exception. I am wondering exactly what this is telling me since the auxiliary ASID being PCed to had been active for some time and had processed several requests, ie, the PC had been working perfectly well up until the abend. So what has gone bad? My understanding is that the PC linkage information is kept in system control blocks so that should be OK. The PC number we are calling is X'00017F00' which implies an ET index of X'F00'; is that sane? Any hints gratefully received! Robin -- 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
