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 ?
What do I need to do to correct this 0D7 Abend ?
I would appreciate any assistance.
Paul D'Anelo
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
