Jim Mulder wrote > Your ATSET does a stacking PC-cp. The ATSET service routine >removes secondary authority for your server's AX to your >User space. ATSET tries to return via PR, but since you invoked >ATSET in cross memory mode, this is PR-ss, and secondary >authority checking is done. The resulting SASN would be >your User spaces's ASN, and the ATSET has just removed that >authority. So the PR-ss results in a program check code x'025', >which z/OS turns into a 0D7-025 abend. >
Does this mean a Space Switching PC cannot be used to remove the users access ? Paul D'Angelo ---------- Original Message ---------- From: Jim Mulder <d10j...@us.ibm.com> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 0D7 with ATSET Date: Sun, 20 Jan 2013 22:19:14 -0500 IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> wrote on 01/20/2013 05:08:06 PM: > From: "esst...@juno.com" <esst...@juno.com> > To: IBM-MAIN@listserv.ua.edu, > Date: 01/20/2013 09:53 PM > Subject: 0D7 with ATSET > Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> > > Im trying to understand why a 0D7 Abend occurs With ATSET. > > Im on a zos 1.7 System, developing some sample cross memory routines. > I am provideing 3 sample Routines (Connect, Disconnect, and a > Stacking Space Switching Service Routine) > > > > The Server Address Space > The Server Address Space sets up the Cross Memory Environment for > Selected Users as outlined in MVS Extended Addressability. > > All routines provide then minimum functionality, they have no real function. > > The Server Address Space creates a Name Token Pair, for passing the > Space Token of the Server Address Space, the reserved Linkage Index > (LX), and the Address Of the Cross Memory Service Block which > resides in the Server Address Space. > > The Service Block contains all the Lists and Work Areas used to > Establish the Cross Memory Environment (AXL, LXL,TXL) as described > in MVS Extended Addressability. > > All progrms in the Entry Table have SASAN=OLD Specified. > > > > User Address Space > The User program is bascialy a Driver facility to exercise, debug, > and verify the implementaion of the Cross Memory Envoronment. > > I began by using Two of the three Routines (The Connection And > Dsiconnect routine) as local programs. > Initially, the "User Program" Loads the connect & disconnet programs. > A modeset is issued prior to issung a BASR 14,15. > The connection routine would latter be converted to a Non Space > Switching PC Routine and the > > Disconnect Routine would latter be converted to a Stacking Space > Switching Routine. > > > The User Code performs the following: > Retrieve the Name Token Pair created by the Server Address Space. > Load the Conection Routine > Switch To Supervisor State > BASR 14,15 to the Connection Routine > Switch To Problem State > > Issue a Stacking Space Switch PC Instruction to invoke PC Routine #3 > (the pseudo service) > > Load the Disconnect Routine > Switch To Supervisor State > BASR 14,15 to the Disconnect Routine > Switch To Problem State > > > The Connect And Disconnect Routines are Initially Loaded,ensuring > that theses programs perform the proper functionality. Its basicaly > an easy to debug. > > The "User Routine" Functions properly as outlined above. > When The Connection And Disconect routines are invoked via a BASR > 14,15 they function properly. > > The Service Routine when called by a PC instruction also executes properly. > > > > The Connection Routine - Establishs Access and Sets Up PT & SSAR Authority > for the User Address Space > The connection Routine issues: > OBTAIN STORAGE > ALESERV ADD > SAC 512 Swicth To Access register Mode > > Our PC Service Block contains all the Lists used to Establish > the Cross Memory Environment AXL, LXL,TXL > The program copies the The Service Block to the STORAGE OBTAIN area. > > SAC 0 Swicth to Primary ASC mode > ALESERV DELETE > > ATSET AX=AXVALUE,PT=YES,SSAR=YES > ETCON TKLIST=TKL,LXLIST=LXL > STORAGE RELEASE > PR > > > The Disconnect Routine - Removes Access and Removes PT & SSAR Authority > on behalf of the user address space. > The disconnect Routine issues: > STORAGE OBTAIN > ALESERV ADD > SAC 512 Swicth To Acess register Mode > > The PC Service Block contains all the Lists used to Establish > the Cross Memory Environment AXL, LXL,TXLT > The program copies the The Service Block to the STORAGE OBTAIN area. > > SAC 0 Swicth to Primary ASC mode > ALESERV DELETE > > ATSET AX=AXVALUE,PT=NO,SSAR=NO <======= > ETDIS TKLIST=TKL > > > > The Third Routine executes as a Stacking Space Switching Service Routine > The Service Routine executes the follwoing: > OBTAIN STORAGE > MVCP 0(R15,R1),0(R14),R0 > > MVCS 0(R15,R1),0(R14),R0 > RELEASE STORAGE > PR > > > As I stated earlier I am on a zos 1.7 system. > All three modules provide the minimal functionality. > > Initialy The Connect and Disconnect Routines were loaded by the > "User calling program" and a Modeset Supervisor State was issued > prior to issuing a BASR 14,15. > > When The Connection and Disconnect Routines complete and Return to > the "User Calling program", A modeset is issued again to return to > problem state. > > > Now That I Am satisfied that the disconnect routine is error free I > want to convert it to a Stacking Space Switching PC Routine. > > > The issue is: when converting the Disconnect Routine to a Stacking > Space Switching PC Routine it Abends with a 0D7 abend and 025 Reason > code when ATSET is issued ???? > What Am I doing wrong ? > > The Disconnect Routine is slightly different when it is converted to > a Space Switching PC routine. > The Converted Disconnect Routine looks like this: > STORAGE OBTAIN,LENGTH=STORLGTH,CALLRKY=YES,LOC=31 > MVCP 0(R15,R1),0(R14),R0 > > The Latent Parameter List holds the address of the Our PC Service Block > The Cross Memory Service Block conatins all the Lists used to Establish > the Cross Memory Environment AXL, LXL,TXL > The program copies the The Service Block to the STORAGE OBTAIN area. > > ATSET AX=AXVALUE,PT=NO,SSAR=NO,RELATED= <====== 0D7 ==== > ETDIS TKLIST=TKL,RELATED= > > MVCS 0(R15,R1),0(R14),R0 > STORAGE RELEASE,LENGTH=STORLGTH,ADDR=(R2) > PR > > > The Converted Disconnect Routine does not use AR mode to access > Storage in the Servers Private Address Space. The Service Block used > to hold the Cross Memory Lists(AXVALUE & TKL) reside in the Server > address space and chained from the Latent Parameter List. > > The Space Switching PC routine that Disconnects the Users from the > Entry Tables Abends with a 0D7 abend and 025 Reason code when ATSET is issued. > > > So I looked up the 0D7 and 025 Abend/Reason codes. > The explanation of a 0D7 Abend indicates: > The AX is greater than the number of elements in the target address > space's AT. > A program issued the SSAR instruction, but a secondary authority > exception occurred. > The primary address space is not authorized to issue an SSAR > instruction to the target address space. > > > None of the above makes sense to me since I had previously > established addressability to the Server Address Space and then > issued a Space Switching PC. > > In order to execute a Move To Primary instruction, I would have had > PT and SSAR Authority ? > Correct ? Your ATSET does a stacking PC-cp. The ATSET service routine removes secondary authority for your server's AX to your User space. ATSET tries to return via PR, but since you invoked ATSET in cross memory mode, this is PR-ss, and secondary authority checking is done. The resulting SASN would be your User spaces's ASN, and the ATSET has just removed that authority. So the PR-ss results in a program check code x'025', which z/OS turns into a 0D7-025 abend. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- 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
