AW: Re: AW: Re: How to find which task has been denied to take a dump?
As supplied by IBM, the IEESYSAS proc does not contain a DD statement for any of those DDnames. We have not modified the IEESYSAS procedure. There is none of the dump DD statements in there. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: AW: Re: How to find which task has been denied to take a dump?
That seems to me like undesirable behavior. I will discuss this with the owner of the code to see if that could be changed in a future release. Thank you very much indeed, Jim. Much appreciated. I mentioned that I had opened a PMR for this. I will post its number tomorrow. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: AW: Re: How to find which task has been denied to take a dump?
As supplied by IBM, the IEESYSAS proc does not contain a DD statement for any of those DDnames. We have not modified the IEESYSAS procedure. There is none of the dump DD statements in there. I just examined the code, and verified with a testcase, and it turns out that the IEA848I message gets issued even when there is no SYSUDUMP, SYSMDUMP, or SYSABEND DDname allocated. So in that case, it is telling you that we suppressed a dump due to insufficient authorization when the dump was not requested and thus would not have been taken anyway. That seems to me like undesirable behavior. I will discuss this with the owner of the code to see if that could be changed in a future release. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
For those interested: I found an entry in LOGREC that matched in time and STC name (SMSVSAM). I've opened a PMR since I consider an error if a system component tries to document a problem via ABEND dump instead of an SVC dump. SMSVSAM does not initiate an ABEND dump. RTM2 does that when there is a SYSUDUMP, SYSABEND, or SYSMDUMP DDname allocated. SMSVSAM uses proc IEESYSAS. As supplied by IBM, the IEESYSAS proc does not contain a DD statement for any of those DDnames. If your installation modified the IEESYSAS proc to add one of those DDnames, then the attempt to take that kind of dump is your doing, not SMSVSAM's doing. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: How to find which task has been denied to take a dump?
For those interested: I found an entry in LOGREC that matched in time and STC name (SMSVSAM). I've opened a PMR since I consider an error if a system component tries to document a problem via ABEND dump instead of an SVC dump. SMSVSAM does not initiate an ABEND dump. RTM2 does that when there is a SYSUDUMP, SYSABEND, or SYSMDUMP DDname allocated. SMSVSAM uses proc IEESYSAS. As supplied by IBM, the IEESYSAS proc does not contain a DD statement for any of those DDnames. If your installation modified the IEESYSAS proc to add one of those DDnames, then the attempt to take that kind of dump is your doing, not SMSVSAM's doing. I guess I did not choose good wording for what I meant. I was assuming that system code should establish appropriate recovery routines to handle unexpected situations. I was further assuming that this code should document the failure via SVC dump, then retry. This doesn't not seem to be the case since RTM2 was trying to document via abend dump (maybe based on the fact that we indeed added a dump DD statement. I will chek if this is the case.) Am I still on the wrong track? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
I don't like the book said this: RDEFINE FACILITY IEAABD.DMPAUTH UACC(READ). I will rather lower the UACC. We all should agree with not liking that. This was corrected in the z/OS 2.1 publications. In z/OS 1.13 the example incorrectly had this, but the guideline immediately before the example was correct in mentioning UACC(NONE). Also, revise IEAABD.DMPAKEY too, for tasks in key less than 8. I'm not sure what to revise. At least in 1.13 and 2.1, the exapmle for IEAABD.DMPAKEY shows UACC(NONE). 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: AW: Re: How to find which task has been denied to take a dump?
Peter Relson wrote: I don't like the book said this: RDEFINE FACILITY IEAABD.DMPAUTH UACC(READ). I will rather lower the UACC. We all should agree with not liking that. This was corrected in the z/OS 2.1 publications. Thanks. Much appreciated with lots of thanks. Also, revise IEAABD.DMPAKEY too, for tasks in key less than 8. I'm not sure what to revise. At least in 1.13 and 2.1, the exapmle for IEAABD.DMPAKEY shows UACC(NONE). I meant the OP should see if he needs this profile or not. The UACC(NONE) is indeed stated correctly and I did not made a comment about UACC. Thanks for your notes. Much appreciated. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
Peter Hunkeler wrote: For this specific case, wouldn't RACF logging of denied accesses have been a way to capture the data as to which job was denied access? Good point. I'll have a look. You should have records, provided they were logged in the first place. As others said, FACILITY Class profile IEAABD.DMPAUTH could help you, but as Peter Relson said, be careful about system integrity. You should give only a few lucky guys/gals access to it. (Update or Read as needed) I don't like the book said this: RDEFINE FACILITY IEAABD.DMPAUTH UACC(READ). I will rather lower the UACC. Also, revise IEAABD.DMPAKEY too, for tasks in key less than 8. Remember not to do RACF command SETROPTS REFRESH during an actual dump or while you're trying to terminate those tasks. Good luck and look at LOGREC too for additional diagnostics. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
But if the event happened, is there a way to find out what it was. The slip, I think, would only be helpful if you were anticipating the IEA848I. Or is the fact this could happen lead one to always have a slip set for IEA848I in case it happens? ;-D The original poster indicated that this occurred while he was shutting down a system, so I would anticipate that this occurs every time he does that, and I would set the SLIP before starting the next shutdown. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
For IEA848I it says The question was how to find the task that triggered the message because it is not authorized. It is more general and not restricted to this specific message: How to find the task related with a message if ther is no jobid? SLIP SET,A=SVCD,MSGID=IEA848I,ML=1,ID=M848,END Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
But if the event happened, is there a way to find out what it was. The slip, I think, would only be helpful if you were anticipating the IEA848I. Or is the fact this could happen lead one to always have a slip set for IEA848I in case it happens? ;-D Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Saturday, January 17, 2015 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AW: Re: How to find which task has been denied to take a dump? For IEA848I it says The question was how to find the task that triggered the message because it is not authorized. It is more general and not restricted to this specific message: How to find the task related with a message if ther is no jobid? SLIP SET,A=SVCD,MSGID=IEA848I,ML=1,ID=M848,END Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How to find which task has been denied to take a dump?
On 17 January 2015 at 17:02, Jim Mulder d10j...@us.ibm.com wrote: For IEA848I it says The question was how to find the task that triggered the message because it is not authorized. It is more general and not restricted to this specific message: How to find the task related with a message if ther is no jobid? SLIP SET,A=SVCD,MSGID=IEA848I,ML=1,ID=M848,END Another suggestion is that message IEF196I, which has existed for over 40 years, should include the ASID to which it pertains. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
