Thank you for your response
So I believe I need to introduce RACF OPERCMDS even if it is maintained by
ISFPRMXX.
On Mon, 31 Aug, 2020, 9:11 am Brian Westerman, <
brian_wester...@syzygyinc.com> wrote:
> Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5
> because that's all
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5 because
that's all that will be supported) you will still have to update the RACF
OPERCMDS class (TSO RACF option 2 (general resource profiles)).
The profile name you need to update (for MVS batch and STC's) is MVS.MODIFY.**,
FWIW This VSAM index issue is most likely due to CI/CA splits. I would
suggest unloading/deleting/reloading the complete VSAM cluster (if
necessary ALTERing the original VSAM cluster to some temp other names
instead of deleting it, after the unload and as a fall-back) to fix
this. A
Just curious why you do not control SDSF through your SAF Product.
I removed all of my ISFPARMxx setup and allow our SAF to control who can do
what in SDSF. Now the security team is responsible.
Lizette
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter
Sent:
Hello
I am trying to issue a command using SDSF batch and I end up with
IEE345I Modify invalid authority failed by MVS
We have secured SDSF using ISFPRM
My ID and group are part of NTBL in ISFPRMxx and group name is assigned
under the GROUP which maps to my RACF Group (Default)
We are in zOS
Well a 1, 2, 4, 7, 8, 11, 13, or 14 track index has 1 track CAs, 3, 6,
9, or 12 for a 3 track CA, 5 or 10 for a 5 track CA, 15 tracks or more
for a 1 cylinder CA. Details then vary based on key size,
FREESPACE(ca ci) values, etc. Assuming reload after backup, delete,
define, restore. If you
[Default] On 30 Aug 2020 15:12:07 -0700, in bit.listserv.ibm-main
stars...@mindspring.com (Lizette Koehler) wrote:
>List -
>
>
>
>I have a VSAM Dataset that has grown over the years. When it was set up -
>the INDEX space was left to default
>
One other thing to check for in addition to the
Number of index levels is affected by data CA/CI sizes, index CA/CI
sizes and how well the key "compresses" between adjacent CIs. Until you
have a loaded file, you can't be positive about how many levels you
have. But, once you have it loaded, it's easier to make adjustments
prior to another
More efficient in terms of fewer index LEVELs as Tony Thigpen may have been
getting at? I thought the number of LEVELs was contingent on the the size of
the file and the number of CI and CA splits the index component had endured
and not the allocation of contiguous space for the index
CYL(4 1) should leave one cylinder empty. Cylinder CA will result is
a more efficient index.
On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler wrote:
>
> List -
>
>
>
> I have a VSAM Dataset that has grown over the years. When it was set up -
> the INDEX space was left to default
>
>
>
> I am
How many index levels do you have?
Tony Thigpen
Lizette Koehler wrote on 8/30/20 6:11 PM:
List -
I have a VSAM Dataset that has grown over the years. When it was set up -
the INDEX space was left to default
I am wondering if it makes sense to override the Track Allocation and put
Of course, buffering will probably do the most to improve VSAM REORG times.
For the sequential reads through the cluster that are typical of REORG
activity, add the ',AMP=('BUFNI=x,BUFND=yyy')' parameter to the DD card, where
'x' equals the number of index component LEVELS displayed in the
The index component alone is 2.4 MB? 2,400,000/56664 = 43 tracks? Sure,
Allocate the index component as 4 or even 5 cylinders primary and a single
cylinder secondary.
If the cluster has changed significantly over time, I might also run an IDCAMS
EXAMINE command:
EXAMINE NAME() INDEXTEST
List -
I have a VSAM Dataset that has grown over the years. When it was set up -
the INDEX space was left to default
I am wondering if it makes sense to override the Track Allocation and put it
in Cylinders.
We are noticing a little bit of an increase in run time during reorg. I was
My source is the IETF, and every issue is a semantic issue. I did searches for
bounce and DSN on a bunch of RFCs, and they all agreed. In particular, thr RFC
that you cited, 3464, lists DSN types that are not bounces.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
On 8/29/20 6:50 PM, Seymour J Metz wrote:
According to the IETF, every bounce is a DSN but not every DSN is a bounce.
Would you please cite your source?
I also wonder if we're having somewhat of a semantic issue. I'm
specifically referring to a bounce (which is a superset of the latter)
16 matches
Mail list logo
