Disclaimer

The information contained in this document is distributed on as "as is" basis,

without any warranty either express or implied. The customer is responsible for
use of this information and/or implementation of any techniques mentioned. IBM
Optimizing RACF Performance has reviewed the information for accuracy, but there is no guarantee that a
customer using the information or techniques will obtain the same or similar
Session 28
results in its own operational environment.
Walt Farrell In this document, any references made to an IBM licensed program are not
intended to state or imply that only IBM's licensed program may be used.
RACF Design, IBM Functionally equivalent programs that do not infringe IBM's intellectual property
914-435-7750 rights may be used instead. Any performance data contained in this document
was determined in a controlled environment and therefore, the results which
wfarrell@us.ibm.com may be obtained in other operating environments may vary significantly. Users
of this document should verify the applicable data for their specific
environment.
It is possible that this material may contain references to, or information about,
IBM products (machines and programs), programming, or services that are not
announced in your country. Such references or information must not be
construed to mean that IBM intends to announce such IBM Products,
programming or services in your country.
Enterprise Security Expo 2000 IBM retains the title to the copyright in this paper and the right to make
derivative works and to republish and distribute this paper to whomever it
chooses.

Trademarks
Agenda
The following are trademarks or registered trademarks of
the International Business Machines Corporation:
CICS
RACF Process Overview
OS/390
RACF Tuning Options
S390 Tuning Recommendations
UNIX is a registered trademark in the United States and
other countries licensed exclusively through The Open
Group.

Enterprise Security Expo 2000

1-4
Process Overview-Logical Data Set Process Overview-Physical Data Set
ICB
Indexing ICB Templates Segment BAM Index L1
Table Block
L3
Index L1

L2
Index L2

L1 Index L1

Index L1 Index L2 Index L3

Data Records

Overview-Profile Access Overview-Index Blocks

Block Index Block index entries
4K Length

Index index entries

or :
Built as needed
res
Data qui
re
Resident Data Block Option
l ock Builds index and data blocks in storage
ab
16 data segmentsa dat ICB coordinates changes between CPUs
e ss to ICB
acc One index per level
ach Over time Indices and Data blocks get separated
E Data block

5-8
Overview-Index Separation Tuning Options-Influencing I/O
Before
L1 Index Profiles Profiles Profiles Profiles Profiles Profiles
A,D,..,Z A,Y,E,U H,J,S,L O,Q,E,T F,V,D,Z P,R,X,K1 K2,I,G,M Duplexing
Resident Data Blocks
Profiles
Add---- W,B MVS/RACF
After
L1 Index Profiles Profiles Profiles Profiles Profiles Profiles Audit Trail
A,...L A,Y,E,U H,J,S,L O,Q,E,T F,V,D,Z P,R,X,K1 K2,I,G,M

Profiles L1 Index L2 Index

W,B M,...Z L,...Z SMF
This is why you should run UT400

Tuning Options-Influencing I/O... Tuning Options-RACF Setup

MVS/RACF Resident Data Blocks

Global Access Table
Multiple data sets
Spread the I/O Generic Profiles
Shared Devices Shared General Resource Profiles
Cost=Reserve ACEE in VLF
or global ENQ
UID/GID in VLF (or UNIXMAP)
CacheDASD USP in VLF
MVS/RACF Coupling Facility in a SYSPLEX

9-12
Resident Data Blocks Option Global Access Table
Active blocks kept in storage Generic Naming Rules
Purge with LRU Algorithm &RACUID
&RACGPID
Recommend: Give maximum # No Logging
No Statistics
Resident Data Blocks ECSA on MVS If not granted in GAT
Service Machine on VM normal check made
MVS/RACF Access Approved CSA

Generic Profile Checking Generic Profiles Can Hurt Performance

ELSQA RACF will load -all- generic names

Prod.A* In-storage info for ALL for data set high level qualifier during
Prod.B*
generic profiles with same OPEN
Prod.C*
Prod.D* HLQ (on first reference/addr space)
and so on
At most 4 lists per address space
With a large number of generics
MVS/RACF the loading can require a lot of I/O
and CPU time
Possible "thrashing"

13-16
 Generic Profiles Can Hurt Performance... Generic Profiles Can Hurt Performance...
Avoid Problems:
//DD1 DD DSN=TOM.x
//DD2 DD DSN=MARY.x Don't create too many generics
//DD3 DD DSN=FRED.x Watch out for fully-qualified
//DD4 DD DSN=SUE.x generics
Each generic should ideally
//SYSPROC DD DSN=SYS1.CLIST protect many data sets
// DD DSN=ISP.CLIST Use GLOBAL DATASET for
// DD DSN=ICH.CLIST data sets everyone needs to
// DD DSN=MY.CLIST READ
// DD DSN=SYS1.CLST2

In-Storage Shared Profiles SETROPTS RACLIST Performance Enhancement

TSO1 TSO2 RACLIST GLOBAL=YES
Logon Logon CICS/ESA 4.1, CICS TS,
IMS/ESA V6
Benefits multiple regions
one CPU

RACLIST
ACCTNUM
Dataspace

17-20
RACLIST GLOBAL=YES RACGLIST
RACF

C Dataspace B-tree
B-tree
P B-tree

1 st Ref Pointers CICS CICS

U builds
CICS CICS
A X Y Z
RACROUTE REQ=LIST for TCICSTRN GLOBAL=YES
less virtual storage in CICS private
faster build for second+ region
Faster SETROPTS refresh
4.1 4.1
CICS X Z
Intent: Single image across systems and IPLs
Performance benefit for multiple regions
running on different CPUs using same
class
Setup: SETR CLASSACT(RACGLIST)
RDEFINE RACGLIST TCICSTRN

Group Tree in Storage...

Group Tree in Storage
Uses IRRGTS class in VLF (COFVLFxx)
Special
G1 Saves info about group relationships
Scope of group authority
U1 (superior group, owner) for use by users
G2
who have group-SPECIAL, group-
G3 OPERATIONS, or group-AUDITOR
G8 G4 Probably does NOT help most systems
U2
Can cause performance problems with
G5 G6 G7 split RACF data bases
G9 G10 FIN APAR OW37587, fixed after
OS/390 V2R9
Recommendation: Don't use it

21-24
 UNIX Performance Enhancements (VLF)
ACEE Data in Memory (VLF)
UNIX UNIX UNIX TSO
System System System
Services Services Services

CPU A
C prgm C prgm C prgm
1 2 3
You specify
IRRUMAP
CPU A CPU B IRRGMAP
VLF VLF
ACEE info ACEE info VLF IRRSMAP
about about
active users active users IRRUMAP in COVLFxx
UID userid
CPU A CPU B
IRRGMAP GID group
IRRACEE in VLF (COFVLFxx)
Admin changes affect VLF info IRRSMAP Saves USP info
MAXVIRT in VLF default is fine
Or consider UNIXMAP

UNIX Performance / Usability

Enhancements (UNIXMAP) Performance Enhancements 2.1 - Sysplex
Requirements
Added by APAR OW30858 for OS/390 R3, V2R4 RACF 2.1 Coupling
Profiles map UID or GID to user ID or group name MVS/ESA 5.1 Facilities
Same Sysplex
ADDUSER FRED OMVS(UID(12)) creates U12
profile in UNIXMAP class with FRED on access
list CPU A CPU B CPU C
ADDGROUP GRP2 OMVS(GID(20)) creates Cache Cache Cache
G20 profile in UNIXMAP class with GRP2 on Main Memory Main Memory Main Memory
access list
Avoids scanning RACF database if entry not found
in IRRUMAP or IRRGMAP (bad entry, or VLF Sysplex Communication
Bit in DSNT
purged by RACF administration) Propagate RVARY
Gives consistent "ls -l" output if IRRUMAP and Propagate SETR GLOBAL REFRESH
IRRGMAP not active
See SYS1.SAMPLIB(IRR30858) to "prime" class

25-28
Performance Enhancements 2.1-Sysplex... Storage Consumption MVS
CSA
Primary Backup
Global Access Table
RACF RACF CSA/ECSA
50 20% RACF Data Base Information
Min of
Primary
Profiles for Protected Programs
RDB
LSQA/ELSQA
CPU A CPU B CPU C
ACEEs
RACLISTed Profiles(IMS/CICS)
Data Sharing Mode Generic Profiles
Named Structures You
Data Space
Minimum=RDB for each primary & backup
Shared General Resource Profiles Control

Options Affecting End User Response Time Summary

Of the factors
that impact
RACF performance,
Erase on Scratch I am benefit is greatest
tired of
Long Group Trees waiting in reducing
Some admin functions I/O activity
V2.1 improved IRRUT200
Connections to many groups
Very large groups
Very large access lists

29-32
Tuning Recommendations
Skip Duplex profile statistics
Minimize level of SMF audit
Place RACF DS on fast device
Use Resident Data Blocks
Use Coupling Facility (data
sharing mode)
Use Global Access Table
Use generic profiles with care
Use SETR RACLIST
Control Admin functions
Keep ACEEs in VLF
Reorg your data set
Split database as last resort

33-36