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: How to find which task has been denied to take a dump?
I mentioned that I had opened a PMR for this. I will post its number tomorrow. Here it is: 60902,113,848 -- 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
AW: Re: How to find which task has been denied to take a dump?
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. Unfortunately, the IEAABD.* profile had been defined with logging for successful and denied UPDATE access. Nothing was found in the RACF SMF records. From reading about the difference between READ and UPDATE permission, I was expecting this result for this case (no library with EXECUTE access involved). 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. -- 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
AW: Re: How to find which task has been denied to take a dump?
To be a bit more specific, I think started task (or job) rather than task is what is wanted. Absloutely correct. I just thought task would be understood from the context. I found system address space or SUB=MSTR started task which did not request a jobid too clumsy ;-) 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. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find which task has been denied to take a dump?
I am not sure what the general setup should be for this facility class. Maybe UACC(READ) to start with? Only if you have no concerns about system integrity. That is somewhat unlikely to be the case for a production system of just about anyone contributing to this forum. 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: How to find which task has been denied to take a dump?
To be a bit more specific, I think started task (or job) rather than task is what is wanted. 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? 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?
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
Re: How to find which task has been denied to take a dump?
SLIP SET,A=SVCD,MSGID=IEA848I,ML=1,ID=M848,END Thanks, Jim, this confirms to me there is no way to find out from the operlog, only. I got this request long after the IPL from our second level. I have not yet looked if it happens regularly. First, I was interested to find out if I'm missing a way to identify the task in retrospect. I will sure consider the SLIP. Another suggestion is that message IEF196I, which has existed for over 40 years, should include the ASID to which it pertains. Good idea. However, this would not help in my case either. In retrospect, you cannot map an ASID to a task. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to find which task has been denied to take a dump?
In the OPERLOG, I see the following messages while system CH02PROD is being shutdown for IPL (more messages in context further down): N 002 CH02PROD 14333 08:01:23.54 0281 IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 000 CH02PROD 14333 08:01:23.54 0281 IEF196I IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF The jobid column is blank which tells me the task is a system task or one which had been started SUB=MSTR. But how do I identify the associated task? From the longer extract, one can see that OAM and SMSVSAM termination has been initiated. The part denoted [snip 1] has a bunch of IGW467I from all systems in the plex. Then come the dump denied messages immediately followed by IGW408I confirming SMSVSAM termination ended. NC000 CH02PROD 14333 08:01:23.51 AWRK03P2 0290 STOP OAM NR400 CH02PROD 14333 08:01:23.51 S0166129 0090 CBR1000I OAM STOP command execution scheduled. NC000 CH02PROD 14333 08:01:23.52 AWRK04P2 0290 V SMS,SMSVSAM,TERMINATESERVER M 800 CH02PROD 14333 08:01:23.52 0090 *IGW572I REQUEST TO TERMINATE SMSVSAM 436 D 436 0090 ADDRESS SPACE IS ACCEPTED: E 436 0090 SMSVSAM SERVER TERMINATION SCHEDULED. M 404 CH02DSYS 14333 08:01:23.52 0090 IGW467I DFSMS SMF_TIME PARMLIB VALUE 825 D 825 0090 CHANGED ON SYSTEM: CH02DSYS D 825 0090 OLD VALUE: YES 5 E 825 0090 NEW VALUE: YES 4 [snip 1] M 404 CH04PROD 14333 08:01:23.53 0090 IGW467I DFSMS RlsAboveTheBarMaxPoolSize 414 D 414 0090 PARMLIB VALUE CHANGED ON SYSTEM: **ALL** D 414 0090 OLD VALUE: 4096 4 E 414 0090 NEW VALUE: 4096 5 N 002 CH02PROD 14333 08:01:23.54 0281 IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 000 CH02PROD 14333 08:01:23.54 0281 IEF196I IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 800 CH02PROD 14333 08:01:23.58 0090 *IGW408I SMSVSAM SUCCESSFULLY TERMINATED AT END OF MEMORY M 404 CH01NSYS 14333 08:01:23.52 0090 IGW467I DFSMS DEADLOCK_DETECTION PARMLIB VALUE 970 D 970 0090 CHANGED ON SYSTEM: CH01NSYS D 970 0090 THIS SYSTEM IS OPERATING AS A LOCAL DEADLOCK PROCESSOR. D 970 0090 OLD VALUE: 15 4 4 E 970 0090 NEW VALUE: 15 4 3 [snip 2] Thanks -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find which task has been denied to take a dump?
For IEA848I it says For USER NOT AUTHORIZED, the security authority can be changed to allow the application programmer to get the necessary dump by permitting the user to have READ or UPDATE access to the IEAABD.DMPAUTH facility as described in the z/OS Security Server RACF Security Administrator's Guide. Do you have IEAABD.DMPAUTH specified in RACF (or your SAF product)? If so, you might need to make it allow more tasks to take dumps. Your installation can control the dumping (with SYSUDUMP, SYSABEND, and SYSMDUMP statements) of address spaces that contain controlled programs by defining a profile to protect a resource called IEAABD.DMPAUTH in the FACILITY general resource class. To control the dumping (with SYSABEND, SYSMDUMP, and SYSUDUMP statements) of address spaces that have tasks running in a task control block (TCB) key of less than 8, a profile protecting a resource called IEAABD.DMPAKEY must be defined in the FACILITY general resource class. Define a profile that protects the resource IEAABD.DMPAUTH in the FACILITY class: RDEFINE FACILITY IEAABD.DMPAUTH UACC(NONE) If you want to give a user an access authority that is different from the one you specified on the RDEFINE command (in this example, an access authority of READ), enter: PERMIT IEAABD.DMPAUTH CLASS(FACILITY) ID(ASMITH) ACCESS(READ) I am not sure what the general setup should be for this facility class. Maybe UACC(READ) to start with? I would also review the software records in LOGREC. They may help in determining what task had an issue. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Saturday, January 17, 2015 8:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to find which task has been denied to take a dump? In the OPERLOG, I see the following messages while system CH02PROD is being shutdown for IPL (more messages in context further down): N 002 CH02PROD 14333 08:01:23.54 0281 IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 000 CH02PROD 14333 08:01:23.54 0281 IEF196I IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF The jobid column is blank which tells me the task is a system task or one which had been started SUB=MSTR. But how do I identify the associated task? From the longer extract, one can see that OAM and SMSVSAM termination has been initiated. The part denoted [snip 1] has a bunch of IGW467I from all systems in the plex. Then come the dump denied messages immediately followed by IGW408I confirming SMSVSAM termination ended. NC000 CH02PROD 14333 08:01:23.51 AWRK03P2 0290 STOP OAM NR400 CH02PROD 14333 08:01:23.51 S0166129 0090 CBR1000I OAM STOP command execution scheduled. NC000 CH02PROD 14333 08:01:23.52 AWRK04P2 0290 V SMS,SMSVSAM,TERMINATESERVER M 800 CH02PROD 14333 08:01:23.52 0090 *IGW572I REQUEST TO TERMINATE SMSVSAM 436 D 436 0090 ADDRESS SPACE IS ACCEPTED: E 436 0090 SMSVSAM SERVER TERMINATION SCHEDULED. M 404 CH02DSYS 14333 08:01:23.52 0090 IGW467I DFSMS SMF_TIME PARMLIB VALUE 825 D 825 0090 CHANGED ON SYSTEM: CH02DSYS D 825 0090 OLD VALUE: YES 5 E 825 0090 NEW VALUE: YES 4 [snip 1] M 404 CH04PROD 14333 08:01:23.53 0090 IGW467I DFSMS RlsAboveTheBarMaxPoolSize 414 D 414 0090 PARMLIB VALUE CHANGED ON SYSTEM: **ALL** D 414 0090 OLD VALUE: 4096 4 E 414 0090 NEW VALUE: 4096 5 N 002 CH02PROD 14333 08:01:23.54 0281 IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 000 CH02PROD 14333 08:01:23.54 0281 IEF196I IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 800 CH02PROD 14333 08:01:23.58 0090 *IGW408I SMSVSAM SUCCESSFULLY TERMINATED AT END OF MEMORY M 404 CH01NSYS 14333 08:01:23.52 0090 IGW467I DFSMS DEADLOCK_DETECTION PARMLIB VALUE 970 D 970 0090 CHANGED ON SYSTEM: CH01NSYS D 970 0090 THIS SYSTEM IS OPERATING AS A LOCAL DEADLOCK PROCESSOR. D 970 0090 OLD VALUE: 15 4 4 E 970 0090 NEW VALUE: 15 4 3 [snip 2] Thanks -- Peter Hunkeler
Re: How to find which task has been denied to take a dump?
The other area I found of interest: IGW467I DFSMS RlsAboveTheBarMaxPoolSize 414 D 414 0090 PARMLIB VALUE CHANGED ON SYSTEM: **ALL** D 414 0090 OLD VALUE: 4096 4 E 414 0090 NEW VALUE: 4096 5 You may need to contact IBM on the values. I am not sure what the value of 4 or 5 indicates after the 4096 in the message. This apar may be of interest OA39904: RLSABOVETHEBARMAXPOOLSIZE CHANGES IF SMSVSAM COMES DOWN ON ANOTHER SYSTEM For 64-bit addressable Data Buffers in z/OS V1R12.0 DFSMS Using Data Sets SC26-7410-10 For each system in a sysplex, the SMSVSAM address space contains all the VSAM RLS data buffers. By default, the data buffers are contained below the 2-gigabyte virtual storage bar in the address space's data space. To avoid possible buffer space constraints and potentially improve performance for high-transaction applications, you can optionally specify that data sets and indexes be assigned to RLS buffers with 64-bit virtual addresses, above the 2-gigabyte bar. This 64-bit virtual buffering option is provided by a combination of data class keyword and settings in the IGDSMSxx member of SYS1.PARMLIB. To provide 64-bit data buffering for a data set with VSAM RLS, all the following must be true: The system must be at level z/OS 1.7 or higher. The data set or index must belong to a data class with the attribute RLSAboveTheBarRLS Above the 2-GB Bar set to Yes. The active IGDSMSxx member of SYS1.PARMLIB must have the keyword RlsAboveTheBarMaxPoolsize set to a number between 500 megabytes or 2 terabytes for the system. In addition, to enhance performance for each named system, whether or not the buffers are above the 2-gigabyte bar, you can set the keyword RlsFixedPoolSize in IGDSMSxx to specify the amount of total real storage to be permanently fixed to be used as data buffers. If you do an D SMS you should look for the following entries and perhaps monitor them: Rls_MaxCfFeatureLevel = Z RlsAboveThebarMaxPoolSize = 500 RlsFixedPoolSize = 50 Here is an interesting RLS Tuning presentation http://tinyurl.com/qjfzk3y Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Saturday, January 17, 2015 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to find which task has been denied to take a dump? For IEA848I it says For USER NOT AUTHORIZED, the security authority can be changed to allow the application programmer to get the necessary dump by permitting the user to have READ or UPDATE access to the IEAABD.DMPAUTH facility as described in the z/OS Security Server RACF Security Administrator's Guide. Do you have IEAABD.DMPAUTH specified in RACF (or your SAF product)? If so, you might need to make it allow more tasks to take dumps. Your installation can control the dumping (with SYSUDUMP, SYSABEND, and SYSMDUMP statements) of address spaces that contain controlled programs by defining a profile to protect a resource called IEAABD.DMPAUTH in the FACILITY general resource class. To control the dumping (with SYSABEND, SYSMDUMP, and SYSUDUMP statements) of address spaces that have tasks running in a task control block (TCB) key of less than 8, a profile protecting a resource called IEAABD.DMPAKEY must be defined in the FACILITY general resource class. Define a profile that protects the resource IEAABD.DMPAUTH in the FACILITY class: RDEFINE FACILITY IEAABD.DMPAUTH UACC(NONE) If you want to give a user an access authority that is different from the one you specified on the RDEFINE command (in this example, an access authority of READ), enter: PERMIT IEAABD.DMPAUTH CLASS(FACILITY) ID(ASMITH) ACCESS(READ) I am not sure what the general setup should be for this facility class. Maybe UACC(READ) to start with? I would also review the software records in LOGREC. They may help in determining what task had an issue. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Saturday, January 17, 2015 8:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to find which task has been denied to take a dump? In the OPERLOG, I see the following messages while system CH02PROD is being shutdown for IPL (more messages in context further down): N 002 CH02PROD 14333 08:01:23.54 0281 IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF N 000 CH02PROD 14333 08:01:23.54 0281 IEF196I IEA848I DUMP SUPPRESSED - USER NOT AUTHORIZED BY SAF The jobid column is blank which tells me the task is a system task or one which had been started SUB=MSTR. But how do I identify the associated task? From the longer extract, one can see that OAM and SMSVSAM termination has been initiated.
AW: Re: How to find which task has been denied to take a dump?
For IEA848I it says For USER NOT AUTHORIZED, the security authority can be changed to allow ... Thanks for the various tips, Lizette. I'm aware of the FACILITY profile. I'll have to think about UACC(READ). 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? I haven't had a look at LOGREC yet. This is surely something to consider (not sure why I have not thought of it myself). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
