The other area I found of interest:
IGW467I DFSMS RlsAboveTheBarMaxPoolSize 414
D 414 00000090 PARMLIB VALUE
CHANGED ON SYSTEM: **ALL**
D 414 00000090 OLD VALUE: 4096 4
E 414 00000090 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
"RLSAboveTheBar""RLS 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 0020000 CH02PROD 14333 08:01:23.54 00000281 IEA848I DUMP
SUPPRESSED - USER NOT AUTHORIZED BY SAF
N 0000000 CH02PROD 14333 08:01:23.54 00000281 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.
NC0000000 CH02PROD 14333 08:01:23.51 AWRK03P2 00000290 STOP OAM
NR4000000 CH02PROD 14333 08:01:23.51 S0166129 00000090 CBR1000I OAM STOP
command execution scheduled.
NC0000000 CH02PROD 14333 08:01:23.52 AWRK04P2 00000290 V
SMS,SMSVSAM,TERMINATESERVER
M 8000000 CH02PROD 14333 08:01:23.52 00000090 *IGW572I REQUEST TO
TERMINATE SMSVSAM 436
D 436 00000090 ADDRESS SPACE IS
ACCEPTED:
E 436 00000090 SMSVSAM SERVER
TERMINATION SCHEDULED.
M 4040000 CH02DSYS 14333 08:01:23.52 00000090 IGW467I DFSMS
SMF_TIME PARMLIB VALUE 825
D 825 00000090 CHANGED ON SYSTEM:
CH02DSYS
D 825 00000090 OLD VALUE: YES 5
E 825 00000090 NEW VALUE: YES 4
[snip 1]
M 4040000 CH04PROD 14333 08:01:23.53 00000090 IGW467I DFSMS
RlsAboveTheBarMaxPoolSize 414
D 414 00000090 PARMLIB VALUE
CHANGED ON SYSTEM: **ALL**
D 414 00000090 OLD VALUE: 4096 4
E 414 00000090 NEW VALUE: 4096 5
N 0020000 CH02PROD 14333 08:01:23.54 00000281 IEA848I DUMP
SUPPRESSED - USER NOT AUTHORIZED BY SAF
N 0000000 CH02PROD 14333 08:01:23.54 00000281 IEF196I IEA848I DUMP
SUPPRESSED - USER NOT AUTHORIZED BY SAF
N 8000000 CH02PROD 14333 08:01:23.58 00000090 *IGW408I SMSVSAM
SUCCESSFULLY TERMINATED AT END OF MEMORY
M 4040000 CH01NSYS 14333 08:01:23.52 00000090 IGW467I DFSMS
DEADLOCK_DETECTION PARMLIB VALUE 970
D 970 00000090 CHANGED ON SYSTEM:
CH01NSYS
D 970 00000090 THIS SYSTEM IS
OPERATING AS A LOCAL DEADLOCK PROCESSOR.
D 970 00000090 OLD VALUE: 15 4 4
E 970 00000090 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
