Would the following approach help? From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask and waits for its completion.
The subtask does all the 64 bit AMODE switching (and return), and establishes an ESTAE exit (or other technique) to handle errors that occur inside the subtask. If errors occurs, you return information about the error to the C/C++ main task (normal return, not percolate), which then can signal the error and activate the LE error handling, as usual, so you can do your garbage collection tasks etc.
Kind regards Bernd Am 29.08.2017 um 19:01 schrieb Charles Mills:
On some further review, a separate "AMODE 64 ESTAE" won't do anything for me (unless I am missing something). My existing ESTAE is working fine. The issue at hand is "how do I get C/C++ to trigger a Signal routine." For you assembler folks, a Signal routine is roughly equivalent to a retry routine. In fact, I guess it is C's implementation of what under the covers is LE's retry routine. My business logic is all in C++ (and man am I happy with that! No more "oh crap, I forgot to clear R2" type problems. But I digress). The problem at hand is "I just S0C4'ed. How do I get into my cleanup logic and clean everything up, write the appropriate diagnostics, etc.?" The answer should be "by driving my Signal routine." So what is failing is not "my" ESTAE, but the percolation to LE's ESTAE, or rather, what happens after percolation in LE's recovery routine. I am not a mind reader, but my guess is that LE is saying "the ABEND took place in AMODE 64 code. That is not my problem. Don't drive the retry (Signal) routine; percolate to MVS." That is the problem I want to solve. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, August 29, 2017 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler? @Peter, thanks as always. I had not noticed SPIEOVERRIDE. It would be a better approach than "remember to turn off SPIE in LE." There's not many AMODE 64 instructions -- basically load up a 64-bit pointer and move the data below the bar. I wonder if perhaps FRR would be appropriate. (Not a question for you; a question for me.) There's little doubt about the behavior I saw, and in fact, I only set off bit 31 in the SDWAPSW16, nothing else. I'm on another problem at the moment but I will repeat the experiments for sure at some point here. L R3,SDWAXPAD Load SDWA extension ptrs L R4,SDWAXEME-SDWAPTRS(,R4) Load ptr to 64-bit regs USING SDWARC4,R4 * NI SDWAPSW16+3,X'FE' * LR R1,R9 SDWA SETRP RC=0 Percolate! * NOSDWA EQU * DROP R9,R4 * RETURN EQU * LR R14,R8 Restore R14 BR R14 Return Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, August 29, 2017 5:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler? I do not pretend to know the answer to the initial question, but when Charles mentioned updating the SDWA, that seems really problematic to me. I tried a simple experiment: -- Mainline sets 2 ESTAEXs -- Mainline blows up -- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the PSWs of SDWAEC1, SDWAEC2, SDWAPSW16 -- That ESTAEX routine percolates -- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all of those PSWs. This is what I expected because, for the most part, RTM builds the SDWA anew for each recovey routine, from a protected copy so that changes made by one ESTAE routine are not visible to the next (there are likely some exceptions, but the PSWs are part of the re-build). I have no explanation for why LE's behavior would change based on setting of some bit that an ESTAE routine changed, unless that routine is itself calling LE providing that SDWA. Oherwise, LE would have no idea that you changed anything. Probably a stupid question: since running AMODE 64 is pretty much outside the bounds of 31-bit LE, have you considered protecting your AMODE 64 code with your own recovery and having that recovery field any problem appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that LE's (E)SPIE does not get control if a program interrupt occurs. ---------------------------------------------------------------------- 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
