Re: Clarification of SAC7 Abend
Paul (o) Where is your SRBWORK block located? (from your description, it needs to be in storage that is shared between the two ASIDs) (o) Have you dumped the contents of SRBWORK and validated the contents? (o) Does the value in SRBSTOKEN match the value in the ASSBSTKN field of the target ASID (o) What is the contents of offset 8 into the IEAMSCHD parameter list? (This should match the ASSBSTKN of the target ASID) (o) Is the target ASID still active ? Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: 20 October 2013 19:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Clarification of SAC7 Abend Hi, I need a better understanding of a SAC7 Abend when using IEAMSCHD to schedual an SRB to another program that resides in another Address Space. I issue this macro from my schedualing address space: IEAMSCHD EPADDR=SRBRTN@, PRIORITY=LOCAL, PARM=SRBPARM@, ENV=STOKEN, TARGETSTOKEN=SRBSTOKEN, KEYVALUE=INVOKERKEY, FEATURE=NONE, SYNCH=YES, LLOCK=NO, RMTRADDR=RTMRTN@, FRRADDR=FRRRTN@ DS 0DAlignment SRBWORK EQU *.SRB Routine Work Areas SRBRTN@ DS A.Address Of Target SRB Routine RTMRTN@ DS A.SRB Recovery Termination Routine FRRRTN@ DS A.SRB Functional Recovery Routine SRBPARM@ DS A.Parameters For SRB Routine SRBSTOKEN DS XL8 .Target/Home Address Space Token SRBRETCODE DS A .Return Code From IEAMSCHED DS A .Reserved * I would like to have the above IEAMSCHD schedual an SRB to another Program in another Address Space (the Target Address Space). The Target Address Space previously made available the SRBWORK structure (above) to the Scheduling Address Space: The Address Of SRB Routine SRBRTN@ was Previously loaded by the Target Address Space. TARGETSTOKEN SRBSTOKEN obtained by ALESERV EXTRACTH,STOKEN=SRBSTOKEN in the Target Address Space. The Recovery Routines (FMTADDR and FRRADDR) were previously loaded by the Target Address Space and contain the Address Of the Recovery Routines. When I issue the IEAMSCHED macro, and Abend SAC7 occurs without any dump. I looked up ABEND=SAC7 with REASON=00080001 in messages and codes. It refers to an inappropriate Space Token. So did I incorrectly obtain the Space Token Of The Traget Address Space ? I used the ALESERV EXTRACTH,STOKEN=SRBSTOKEN, I thought that was correct. Can anyone point me in the right direction to resolve this. Paul D'Angelo * -- 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
Clarification of SAC7 Abend
When I issue the IEAMSCHED macro, and Abend SAC7 occurs without any dump. Since this is a user error, taking a dump is your responsibility (whether by recovery with SDUMP(X) or via DD statements if your task and/or job will terminate due to this error). While it does not always do it this way, the system intends to take dumps for its own problems, not for yours. So did I incorrectly obtain the Space Token Of The Traget Address Space ? I used the ALESERV EXTRACTH,STOKEN=SRBSTOKEN, I thought that was correct. The approach is fine. The reason code indicates that the STOKEN passed to the service was structurally not valid (and by that I don't mean no longer valid, I mean could never have been valid). Therefore I conclude that the data referenced by SRBSTOKEN in the IEAVSCHD issuer is not the data extracted by ALESERV EXTRACTH, in whatever way that happened. provided you know the ASCB address, you can acquire the STOKEN as follows: R1 has ascb address of target address space for SRB L R1,ASCBASSB-ASCB(,R1) MVC SRBSTOKEN,ASSBSTKN-ASSB(R1) Unless you have proper serialization against the termination of this space, or knowledge that it will never terminate, you should not do this. Even having recovery is possibly insufficient (as it is conceivable that the storage pointed to by R1 could be reused for some other purpose with unintended consequences to your code). You could possibly have the SRB itself make sure when it gets control that it is in the right space if there are control structures available to do so. If R1 is the address of the home or current primary address space's ASCB, this sequence is safe to do. For P H S, it may also be safe for the current secondary address - the space could go away but if it does, your code will be abended. In the OP's case, the target address space could have used this approach to save its STOKEN. The scheduling address space would fall into the unless that I mentioned earlier. 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: Clarification of SAC7 Abend
Since you're using ALESERV EXTRACTH, I'm assuming you want to schedule and SRB into the home address space. IEAMSCHD is expecting the address of the STOKEN. So if you were to do this, LA R2, SRBSTOKEN IEAMSCHD EPADDR=SRBRTN@, PRIORITY=LOCAL, PARM=SRBPARM@, ENV=STOKEN, TARGETSTOKEN=(R2), change this line KEYVALUE=INVOKERKEY, FEATURE=NONE, SYNCH=YES, LLOCK=NO, RMTRADDR=RTMRTN@, FRRADDR=FRRRTN@ I'm also assuming the parms marked with an @ are the address of the actual parm. If you want to schedule an SRB into any address space, provided you know the ASCB address, you can acquire the STOKEN as follows: * R1 has ascb address of target address space for SRB L R1,ASCBASSB-ASCB(,R1) MVC SRBSTOKEN,ASSBSTKN-ASSB(R1) Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, October 20, 2013 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Clarification of SAC7 Abend Hi, I need a better understanding of a SAC7 Abend when using IEAMSCHD to schedual an SRB to another program that resides in another Address Space. I issue this macro from my schedualing address space: IEAMSCHD EPADDR=SRBRTN@, PRIORITY=LOCAL, PARM=SRBPARM@, ENV=STOKEN, TARGETSTOKEN=SRBSTOKEN, KEYVALUE=INVOKERKEY, FEATURE=NONE, SYNCH=YES, LLOCK=NO, RMTRADDR=RTMRTN@, FRRADDR=FRRRTN@ DS 0DAlignment SRBWORK EQU *.SRB Routine Work Areas SRBRTN@ DS A.Address Of Target SRB Routine RTMRTN@ DS A.SRB Recovery Termination Routine FRRRTN@ DS A.SRB Functional Recovery Routine SRBPARM@ DS A.Parameters For SRB Routine SRBSTOKEN DS XL8 .Target/Home Address Space Token SRBRETCODE DS A .Return Code From IEAMSCHED DS A .Reserved * I would like to have the above IEAMSCHD schedual an SRB to another Program in another Address Space (the Target Address Space). The Target Address Space previously made available the SRBWORK structure (above) to the Scheduling Address Space: The Address Of SRB Routine SRBRTN@ was Previously loaded by the Target Address Space. TARGETSTOKEN SRBSTOKEN obtained by ALESERV EXTRACTH,STOKEN=SRBSTOKEN in the Target Address Space. The Recovery Routines (FMTADDR and FRRADDR) were previously loaded by the Target Address Space and contain the Address Of the Recovery Routines. When I issue the IEAMSCHED macro, and Abend SAC7 occurs without any dump. I looked up ABEND=SAC7 with REASON=00080001 in messages and codes. It refers to an inappropriate Space Token. So did I incorrectly obtain the Space Token Of The Traget Address Space ? I used the ALESERV EXTRACTH,STOKEN=SRBSTOKEN, I thought that was correct. Can anyone point me in the right direction to resolve this. Paul D'Angelo * -- 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: Clarification of SAC7 Abend
Paul's code snippet is correct. Example 4 from the IBM manual shows that his coding is correct. The ALESERV will work fine if that's the ASCB where he wants to run the SRB. I would suggest looking at the SRBWORK and make sure it's in shared memory or being correctly passed. My gut feeling is that it's not referencing the correct area and that it is actually invalid. Or maybe the area is not aligned with the passed area. I don't think it's using the STOKEN you think it's using. Jon Perryman. From: Kenneth Wilkerson redb...@austin.rr.com Since you're using ALESERV EXTRACTH, I'm assuming you want to schedule and SRB into the home address space. IEAMSCHD is expecting the address of the STOKEN. So if you were to do this, LA R2, SRBSTOKEN IEAMSCHD EPADDR=SRBRTN@, PRIORITY=LOCAL, PARM=SRBPARM@, ENV=STOKEN, TARGETSTOKEN=(R2), change this line KEYVALUE=INVOKERKEY, FEATURE=NONE, SYNCH=YES, LLOCK=NO, RMTRADDR=RTMRTN@, FRRADDR=FRRRTN@ -Original Message- Behalf Of esst...@juno.com I need a better understanding of a SAC7 Abend when using IEAMSCHD to schedual an SRB to another program that resides in another Address Space. I issue this macro from my schedualing address space: IEAMSCHD EPADDR=SRBRTN@, PRIORITY=LOCAL, PARM=SRBPARM@, ENV=STOKEN, TARGETSTOKEN=SRBSTOKEN, KEYVALUE=INVOKERKEY, FEATURE=NONE, SYNCH=YES, LLOCK=NO, RMTRADDR=RTMRTN@, FRRADDR=FRRRTN@ DS 0D Alignment SRBWORK EQU * .SRB Routine Work Areas SRBRTN@ DS A .Address Of Target SRB Routine RTMRTN@ DS A .SRB Recovery Termination Routine FRRRTN@ DS A .SRB Functional Recovery Routine SRBPARM@ DS A .Parameters For SRB Routine SRBSTOKEN DS XL8 .Target/Home Address Space Token SRBRETCODE DS A .Return Code From IEAMSCHED DS A .Reserved * I would like to have the above IEAMSCHD schedual an SRB to another Program in another Address Space (the Target Address Space). The Target Address Space previously made available the SRBWORK structure (above) to the Scheduling Address Space: The Address Of SRB Routine SRBRTN@ was Previously loaded by the Target Address Space. TARGETSTOKEN SRBSTOKEN obtained by ALESERV EXTRACTH,STOKEN=SRBSTOKEN in the Target Address Space. The Recovery Routines (FMTADDR and FRRADDR) were previously loaded by the Target Address Space and contain the Address Of the Recovery Routines. When I issue the IEAMSCHED macro, and Abend SAC7 occurs without any dump. I looked up ABEND=SAC7 with REASON=00080001 in messages and codes. It refers to an inappropriate Space Token. So did I incorrectly obtain the Space Token Of The Traget Address Space ? I used the ALESERV EXTRACTH,STOKEN=SRBSTOKEN, I thought that was correct. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
