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:[email protected]] On Behalf Of Robin Atwood Sent: Friday, August 23, 2013 6:47 AM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
