Yes, and as s consequence, if he does not receive an 0C4, he will probably be clearing someone else's storage.
however the relation with 'the other subsystem' is also interesting. Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Binyamin Dissen > Sent: 06 September, 2019 11:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: MPF Exit calling System REXX - S0C4 abend > > Actually, you are incorrect. > > The code is modifying storage beyond its area. Depending on how storage is > set > up, it is possible that the area will be on a page that is resolvable or > not. > > On Fri, 6 Sep 2019 04:08:37 -0500 Sebastian Welton <sebast...@welton.de> > wrote: > > :>Thanks to everyone who responded and although he tried out all the > options provided, nothing actually worked however it looks like it is > working now. The first step was to implement the original it was based > upon from the Redbook and that worked fine out of the box. I then looked > at what messages he was processing via MPF and saw a couple that looked > familiar as being used by another subsystem which also 'traps' messages. > Once I removed the startup of the STC and all references to it in PARMLIB > (IEFSSN in particular), no more abends occurred. So it basically wasn't > the fault of the code (apparently he has coded MPF exits before, just > wanted to try a different method and to use System REXX) but the > interaction with other subsystems. Personally I could have done this with > System Automation in a couple of minutes but this is a good learning curve > for both of us in particular during the investigation. Once again, many > thanks to everyone who took the time and effort to reply, it > was > much > :>appreciated and did help in furthering our education (particularly me.) > :> > :>Seb. > :> > :>---------------------------------------------------------------------- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen <bdis...@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
