Well, yeah. The fix for the S0C4? Stop accessing invalid storage! :-) It is super-complex, super-high-performance code. Very tricky and difficult. FWIW, it is a read-type access.
There are no S0C1's except in my intentional test code -- I just mentioned S0C1 as an example of an exception. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, August 30, 2017 6:46 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? On Wed, Aug 30, 2017 at 8:22 AM, Charles Mills <charl...@mcn.org> wrote: > This problem is still in flux and I have other priorities at this instant. > > But having kinda sorta said @Peter was wrong I wanted to get back here > and say there is something going on that I do not understand. > > Yes, LE worked as desired when I set off the AMODE 64 bit as I wrote > the below. But I also had it work as desired in one test yesterday > when I did > *not* set off that bit. So yes, perhaps setting off that bit is > irrelevant and the success was coincidental. > > More research required. Something (in my code?) is having unintended > side effects. Pretty simple code and hard to see what might be wrong, > but that's what makes programming fun, right? > Coming in out of far left field (as is my wont), the original message mentioned S0C4 & S0C1 abends in your AMODE 64. Given that the best exception is no exception, for the S0C4 case, perhaps validating your addresses via VSMLOC could avoid the S0C4 in the first place. If the S0C4 is an true PIC 4 (attempt to store where you aren't allowed), perhaps checking the key using IVSK would be helpful as well. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
