Apuntes de RACF PDF

Apuntes de RACF
Juan Mautalen
2
PREFACIO
Este texto intenta ser una guía básica de RACF (Resource Access Control Facility), dirigida
principalmente a aquellas personas que quieran iniciarse como administradores del producto. De todos
modos, la información que contiene, aunque sea parcialmente, puede resultar de gran utilidad tanto para
los system programmers como para los system operators (o cualquier otro usuario con inquietudes en el
plano de la seguridad en plataforma mainframe).
Los requisitos previos para abordar su lectura son realmente mínimos. Una cierta familiaridad con el
entorno z/OS, sumada a un manejo básico de TSO, ISPF y JCL, son suficientes para comprender sin
problemas los temas expuestos.
La información que se brinda está basada en la versión de RACF provista por la versión 1.11 del z/OS.
Sin embargo, salvo contadas excepciones, también es válida para versiones anteriores de RACF, o
incluso posteriores.
Al tratarse de un manual introductorio, he omitido intencionalmente el tratamiento de varios temas que,
si bien importantes, considero que están mas allá del contenido que debe abarcar un texto básico (RRSF-
Racf Remote Sharing Facility- o Certificados Digitales, por ejemplo). Otros temas tampoco son
tratados, pero por considerar, en estos casos, que se trata de facilidades raramente utilizadas (security
labels, por ejemplo).
Con respecto a los comandos de RACF, solo he descripto los operandos de uso más frecuente. La
sintaxis completa puede consultarse en línea desde una sesión de TSO mediante el comando HELP, o
bien en el manual de IBM “RACF - Command Languaje Reference”.
En cualquier caso, toda información sobre RACF que el lector no encuentre en la presente guía, o que
pretenda ampliar, puede hallarla en la documentación oficial del producto.
En lo relativo al alcance, tampoco he incursionado en el análisis de la protección dada por RACF a
ciertos “productos de base”, como ser: DB2, CICS o IMS. Para ello, debe no solo debe recabarse
información en la bibliografía específica de RACF sino principalmente en la documentación propia de
cada producto. En la siguiente dirección web se pueden consultar y descargar gratuitamente todos los
manuales oficiales de IBM vinculados al entorno z/OS:
http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/#secserv
Lo ideal sería leer la presente guía junto a una terminal con acceso a TSO, disponiendo de un usuario
con atributo SPECIAL, para poder probar en la práctica los comandos y opciones que se van
describiendo. Naturalmente, las opciones críticas deben siempre experimentarse en un entorno no
productivo, a menos que se pretenda adquirir una rápida popularidad -y no de la mejor manera- dentro
de la organización. En ciertas ocasiones notarán que se hace referencia, en determinado capítulo, a
algún tema que recién se trata en detalle en uno posterior. Esto me resultó inevitable, más allá de mis
esfuerzos por organizar el material lo más posible.
A lo largo de esta guía he optado, en muchos casos, por dar recomendaciones respecto a la
configuración y políticas de seguridad que estimo más convenientes. Estas deben entenderse como mi
opinión personal, producto de mi propia experiencia. En ningún caso se trata de sugerencias de IBM,
salvo que ello se indique explícitamente. En cualquier caso, toda organización debe determinar sus
necesidades particulares de seguridad y decidir qué opciones le resultan las más apropiadas para
satisfacerlas.
Juan Guillermo Mautalen

Buenos Aires, julio 2011
Apuntes de RACF Juan Mautalen

3
TABLA DE CONTENIDOS
1 - INTRODUCCIÓN ..........................................................................................................................6
1.1 - Consideraciones generales .........................................................................................................6
1.2 - Identificación y autenticación de usuarios ..................................................................................6
1.3 - Control de acceso a recursos ......................................................................................................6
1.4 - Herramientas de auditoría ..........................................................................................................6
1.5 - Seguridad externa para aplicaciones ...........................................................................................7
2 - LA BASE DE RACF .......................................................................................................................8

2.1 - Consideraciones generales .........................................................................................................8
2.2 - Características............................................................................................................................8
2.3 - Estructura...................................................................................................................................9
2.4 - Actualización de la base .............................................................................................................9
3 - USUARIOS Y GRUPOS .............................................................................................................. 12

3.1 - Consideraciones generales ....................................................................................................... 12
3.2 - Administración de grupos de RACF ......................................................................................... 12
3.3 - Alta de un grupo ...................................................................................................................... 13
3.4 - Modificación de un grupo ........................................................................................................ 14
3.5 - Eliminación de un grupo .......................................................................................................... 15
3.6 - Listado de un grupo ................................................................................................................. 15
3.7 - Administración de usuarios de RACF ...................................................................................... 16
3.8 - Alta de un usuario .................................................................................................................... 18
3.9 - Modificación de un usuario ...................................................................................................... 19
3.10 - Eliminación de un usuario ...................................................................................................... 21
3.11 - Listado de un usuario ............................................................................................................. 22
3.12 - Comando PASSWORD.......................................................................................................... 26
3.13 - Atributos de usuario ............................................................................................................... 27
3.14 - Conexión de un usuario a un grupo ........................................................................................ 35
4 - PROTECCIÓN DE DATASETS ................................................................................................. 39

4.2 - Perfiles discretos ...................................................................................................................... 40
4.3 - Perfiles genéricos ..................................................................................................................... 40
4.4 - Cómo determina RACF el perfil protector de un dataset ........................................................... 41
4.5 - Niveles de autoridad para perfiles de dataset ............................................................................ 42
4.6 - Administración de perfiles de dataset ....................................................................................... 43
4.7 - Definición de un perfil de dataset ............................................................................................. 43
4.8 - Modificación de un perfil de dataset ......................................................................................... 47
4.9 - Eliminación de un perfil de dataset........................................................................................... 47
4.10 - Listado de un perfil de dataset ................................................................................................ 48
4.11 - Permisos sobre perfiles de dataset .......................................................................................... 52
4.12 - Perfiles de dataset: discretos versus genéricos ........................................................................ 54
4.13 - Creación de nuevos datasets ................................................................................................... 54
5 - OPCIONES GLOBALES DE RACF ........................................................................................... 56

5.2 - Posit Value de una clase ........................................................................................................... 56
5.3 - Listado de la SETROPTS ......................................................................................................... 56
5.4 - Estadísticas iniciales ................................................................................................................ 59

4
5.5 - Control de programas ............................................................................................................... 60

5.6 - Terminales no protegidas ......................................................................................................... 60
5.7 - Auditoría de usuarios con atributo SPECIAL ........................................................................... 60
5.8 - Auditoría de violación de comandos......................................................................................... 61
5.9 - Auditoría de usuarios con atributo OPERATIONS ................................................................... 61
5.10 - Clases con estadísticas ........................................................................................................... 62
5.11 - Clases auditadas ..................................................................................................................... 62
5.12 - Clases activas ......................................................................................................................... 63
5.13 - Clases con perfiles genéricos.................................................................................................. 64
5.14 - Clases con comandos genéricos.............................................................................................. 65
5.15 - Clases con perfiles genéricos compartidos en memoria (GENLISTeadas) .............................. 65
5.16 - Clases en la GLOBAL ........................................................................................................... 66
5.17 - Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadas- ............ 66
5.18 - Clases RACLISTeadas vía RACROUTE REQUEST=LIST, GLOBAL=YES ........................ 67
5.19 - Opciones de logging para clases ............................................................................................. 68
5.20 - Protección automática de datasets .......................................................................................... 69
5.21 - Uso del ** en perfiles genéricos de dataset ............................................................................. 69
5.22 - Nombres reales de dataset ...................................................................................................... 70
5.23 - Opciones relativas a JES ........................................................................................................ 70
5.24 - Protect-all .............................................................................................................................. 71
5.25 - Protección de archivos en cartucho......................................................................................... 72
5.26 - Período de retención para archivos en cartucho ...................................................................... 72
5.27 - Borrado físico de archivos ...................................................................................................... 73
5.28 - Archivos de un único calificador ............................................................................................ 74
5.29 - Lista de grupos ....................................................................................................................... 74
5.30 - Revocación automática por inactividad .................................................................................. 75
5.31 - Modelización de perfiles de dataset ........................................................................................ 75
5.32 - Opciones relativas a PASSWORD ......................................................................................... 76
5.33 - Passwords del RVARY .......................................................................................................... 81
5.34 - Opciones de auditoría relativas a security levels y security labels ........................................... 81
5.35 - Restricción para la creación de perfiles más específicos que perfiles existentes ...................... 81
5.36 - Otras opciones vinculadas a security levels y security labels .................................................. 82
5.37 - Acceso a datasets no catalogados ........................................................................................... 83
5.38 - Máximo global y default para la validez de la clave de una sesión .......................................... 84
5.39 - Auditoría de transacciones APPC ........................................................................................... 84
5.40 - Opción ADDCREATOR ........................................................................................................ 85
5.41 - Lenguaje ................................................................................................................................ 85
5.42 - Comandos de REFRESH ....................................................................................................... 85
6 - PROTECCIÓN DE RECURSOS GENERALES ........................................................................ 88

6.1 - Recursos generales y perfiles ................................................................................................... 88
6.2 - Clases de miembros y agrupadoras ........................................................................................... 88
6.3 - Perfiles genéricos ..................................................................................................................... 90
6.4 - Niveles de acceso ..................................................................................................................... 91
6.5 - Cómo determina RACF la protección de un recurso general ..................................................... 91
6.6 - Definición de un perfil de recursos generales ........................................................................... 92
6.7 - Modificación de un perfil de recursos generales ....................................................................... 94
6.8 - Eliminación de un perfil de recursos generales ......................................................................... 94
6.9 - Listado de un perfil de recursos generales ................................................................................ 95
6.10 - Permisos sobre perfiles de recursos generales ......................................................................... 96
6.11 - Comando SEARCH ............................................................................................................... 97

5
7 - CLASES PARTICULARES ....................................................................................................... 101

7.1 - Consideraciones generales ..................................................................................................... 101
7.2 - Clase GLOBAL ..................................................................................................................... 101
7.3 - Clase STARTED ................................................................................................................... 103
7.4 - Clase PROGRAM .................................................................................................................. 106
7.5 - Clase FACILITY ................................................................................................................... 109
8 – PROCESO DE CHEQUEO DE AUTORIDAD ........................................................................ 113

8.2 - Autoridad de un usuario sobre un recurso ............................................................................... 113
9 - PROGRAMAS UTILITARIOS ................................................................................................. 116

9.2 - IRRUT100 ............................................................................................................................. 116
9.3 - IRRUT200 ............................................................................................................................. 118
9.4 - IRRUT400 ............................................................................................................................. 121
9.5 - IRRDBU00 ............................................................................................................................ 124
9.6 - IRRRID00 ............................................................................................................................. 125
9.7 - IRRMIN00............................................................................................................................. 128
9.8 - Otros Utilitarios ..................................................................................................................... 130
10 - COMANDO RVARY................................................................................................................ 132

10.1 - Consideraciones generales ................................................................................................... 132
10.2 - Listado de la configuración de las bases ............................................................................... 133
10.3 - Switch de las bases ............................................................................................................... 133
10.4 - Activación/inactivación de las bases..................................................................................... 134
10.5 - Procedimientos de recuperación de bases de RACF.............................................................. 135

6
1 - INTRODUCCIÓN
1.1 - Consideraciones generales

RACF (Resource Access Control Facility) es el componente del sistema operativo z/OS, provisto por
IBM, para brindar seguridad en el entorno mainframe. Si bien el z/OS permite la utilización de otros
ESM (External Security Manager) en lugar de RACF, como TOP/SECRET o ACF2, ambos de la
empresa Computer Associates, vamos a asumir en todo la presente guía que el ESM utilizado es RACF.
Básicamente, RACF provee los siguientes servicios:
Identificación y autenticación de usuarios
Control de acceso a recursos
Herramientas de auditoría
Seguridad externa para aplicaciones
1.2 - Identificación y autenticación de usuarios

Todo usuario que requiera acceso al entorno del z/OS (subsistemas, aplicaciones, etc.) debe poseer un
identificador de usuario (userid) y una clave de acceso (normalmente una password, aunque existen
otros medios soportados). RACF se ocupa de identificar al usuario, comprobando que el userid exista en
su base. Asimismo, se encarga de autenticarlo, controlando que la password ingresada sea la que
corresponde.
Además, RACF controla en el momento del logon ciertos aspectos de seguridad adicionales. Por
ejemplo, verifica que el usuario no se encuentre revocado (esto es, que no tenga sus derechos de acceso
bloqueados), que esté habilitado a ingresar en ese día y horario o que se encuentre autorizado a ingresar
desde esa terminal.
1.3 - Control de acceso a recursos

Cuando un usuario intenta acceder a un recurso protegido por RACF, la aplicación dentro de la cual
surge el requerimiento se comunica con RACF enviándole, básicamente, la siguiente información:
o Identificador del usuario
o Nombre del recurso
o Clase a la que pertenece el recurso
o Nivel de autoridad requerido (por ejemplo, lectura o grabación, en el caso de un dataset)
En base a la información recibida, RACF consulta dentro de su base cómo se encuentra protegido el
recurso, y devuelve a la aplicación solicitante un código de retorno que indica si el acceso está
permitido (RC=00), denegado (RC=08), o si no posee la información necesaria para responder el
requerimiento (RC=04). Es la aplicación la que finalmente otorga o rechaza el acceso solicitado,
basándose naturalmente en la respuesta recibida de RACF.
1.4 - Herramientas de auditoría

RACF provee una flexible gama de opciones de auditoría, a través de las cuales se pueden detectar,
entre otros, los siguientes eventos:
o Día y hora en que un usuario ingresó por última vez al sistema
o Intentos fallidos de ingreso al sistema
o Intentos de acceso a recursos (fallidos y exitosos)
o Intentos fallidos de ejecución de comandos de RACF

7
o Ejecución exitosa de comandos de RACF

o Cantidad de veces en que determinado recurso ha sido accedido
La información relativa a accesos (exitosos o fallidos) se graba en registros tipo 80 del SMF (System
Management Facility). Otro tipo de información, de carácter estadístico, como ser la fecha y hora del
último ingreso exitoso de un determinado usuario, o la cantidad de veces que se logueó al sistema, se
graba directamente en la base de RACF.
1.5 - Seguridad externa para aplicaciones

RACF, conjuntamente con un componente básico del sistema operativo denominado SAF (System
Authorization Facility), brinda la posibilidad de desarrollar aplicaciones cuya seguridad esté controlada
externamente por RACF. En este sentido, es cada vez más frecuente que los proveedores independientes
de software que desarrollan productos para z/OS diseñen sus aplicaciones de modo que la seguridad sea
controlada externamente por RACF.
Contar con un producto como RACF que centralice la seguridad de todas las aplicaciones, no solo
facilita y simplifica enormemente las tareas administrativas, sino que robustece la seguridad global de la
plataforma.

8
2 - LA BASE DE RACF

Describiremos, de manera muy básica, la estructura de una base de RACF:
Toda LPAR (Logical Partition) con un sistema operativo z/OS instalado exige la existencia de una base
de RACF primaria y de una base de backup (opcional, aunque absolutamente recomendable), que deben
residir en disco. La base de backup, que por cuestiones obvias de seguridad conviene que resida en un
disco distinto al de la primaria, se actualizará automáticamente cada vez que se efectúen modificaciones
(siempre y cuando estén configurados los parámetros necesarios para que esto suceda). De este modo, si
la base primaria presenta algún error (situación realmente muy poco frecuente, pero posible), se puede
switchear fácilmente a la base de backup y seguir operando normalmente, como veremos en el capítulo
que trata el comando RVARY.
La base primaria de RACF puede consistir de un único dataset, o puede estar distribuida en más de uno.
El nombre de la base es de libre elección por parte de la organización, aunque naturalmente debe
adecuarse a las reglas que rigen la nomenclatura de cualquier dataset dentro del entorno z/OS. Idénticas
consideraciones se aplican a la base de backup (si la base primaria esta particionada en más de un
dataset, la base de backup debe estar particionada exactamente de la misma manera).
BASE PRIMARIA BASE BACKUP
Actualización automática
SYS1.RACF.PRIM1 SYS1.RACF.BACK1
SYS1.RACF.PRIM2 SYS1.RACF.BACK2
El diagrama muestra una configuración de una base de RACF particionada en 2 datasets
La alocación e inicialización de las bases de RACF se realiza a través del utilitario IRRMIN00, el cual
se describirá en detalle en el capítulo referido a programas utilitarios. Los datasets que constituyen las
bases de RACF deben ser definidos con características específicas, que mencionamos a continuación.
2.2 - Características
Organization PSU Archivo secuencial Unamovable (inamovible)

Record format F Registros de longitud fija
Record lenght 4096 Longitud de registro de 4K (4096 bytes)
Block size 4096 Bloqueo de 4K
Secondary cylinders 0 Debe ocupar un único extent
Es altamente recomendable que la organización sea PSU (Physical Secuencial Unamovable), de modo
que una eventual desfragmentación del disco dónde esté alocado no mueva el dataset de lugar. En
efecto, en el momento de IPL RACF toma registro de la ubicación absoluta, dentro de los discos, de los
datasets que conforman sus bases. Por lo tanto, cualquier movimiento posterior implicará que los
datasets ya no se encuentren dónde RACF tiene registrado, siendo las consecuencias impredecibles
(puede incluso que los problemas no se noten inmediatamente, sino que solo aparezcan cuando

9
efectivamente sea sobrescrito con nueva información el área de disco correspondiente a la ubicación
original). Debido a esta recomendación, es conveniente que los datasets que conforman las bases de
RACF (primaria y backup) residan en discos que no se encuentren bajo SMS (Storage Management
Subsystem), para que puedan alocarse como PSU. De no ser posible, deben alocarse como PS y tomarse
todas las precauciones necesarias para que los datasets no sean movidos (mientras se encuentren activos
en alguna LPAR).
Es obligatorio que tengan su espacio alocado en forma contigua, o sea que ocupen un único extent.
El tamaño de la base depende, naturalmente, del volumen de información que cada organización tenga
almacenada (lo cual no solo involucra la cantidad de usuarios definidos, sino muchos otros factores
adicionales). En cualquier caso, desde el punto de vista de storage, el espacio ocupado por las bases de
RACF es realmente pequeño. Es habitual y recomendable que la base de backup esté alocada con
idéntico tamaño que la primaria.
2.3 - Estructura
La base de RACF tiene una estructura propia bastante compleja. Sólo daremos una idea básica de cómo
está organizada, ya que una descripción detallada está más allá de los objetivos de este manual
introductorio.
La base de RACF está conformada, esencialmente, por entidades denominadas “perfiles” (profiles), que
pueden pensarse como registros que contienen distintos campos. Todo perfil pertenece a una “clase”
(class), que está identificada con un nombre de hasta 8 caracteres. Las clases, por lo tanto, agrupan
lógicamente a los perfiles. En el RACF que viene con el sistema operativo z/OS 1.11, IBM provee 230
clases predefinidas, cada una con un propósito específico, cuyos nombres son fijos e inalterables. Si
fuese necesario, existe la posibilidad de definir clases adicionales. Sin embargo, en la presente guía,
solo haremos referencia a las clases predefinidas por IBM, que suelen ser suficientes para satisfacer los
requerimientos de seguridad habituales de una organización.
Clase Descripción
USER Cada perfil en esta clase representa un usuario
GROUP Cada perfil en esta clase representa un grupo
DATASET Los perfiles en esta clase son reglas que protegen archivos
Clases de Recursos Generales (solo se enumeran muy pocas, a modo de ejemplo)

TERMINAL Protege el uso de terminales
APPL Protege el acceso a aplicaciones VTAM
TCICSTRN Protege la ejecución de transacciones CICS
PROGRAM Protege la invocación de programas
TSOPROC Protege el uso de procedimientos de logon a TSO
ACCTNUM Protege el uso de códigos de cuenta
OPERCMDS Protege los comandos de consola
CONSOLE Protege el uso de las consolas
SDSF Protege el uso del SDSF
STARTED Reglas que asignan usuarios a Started Task
2.4 - Actualización de la base

La base de RACF debe modificarse únicamente (salvo casos excepcionales) a través de la ejecución de
comandos de RACF.
Los comandos de RACF solo se pueden ejecutar desde una interfaz que los admita, siendo la más usual
el entorno TSO. Pueden ser ejecutados en foreground (opción preferible, si se trata de pocos
comandos), o batchground (mejor opción si se tiene que ejecutar una gran cantidad).

10
Existe también la posibilidad de ejecutar comandos de RACF utilizando una serie de paneles accesibles
desde una sesión de TSO. Estos proporcionan una interfaz amigable para el usuario, evitándole tener
que recordar los comandos de RACF y su sintaxis. Sin embargo, el administrador de RACF memorizará
rápidamente la sintaxis de los comandos básicos, en cuyo caso la utilización de los paneles resulta lenta
y tediosa, siendo mucho más práctico y veloz ejecutar los comandos tipeándolos directamente. Por lo
tanto, no haremos referencia en el futuro a la utilización de los paneles, ya que no suelen ser muy
utilizados.
Aunque no suele resultar necesario en la operatoria habitual, también se pueden ejecutar comandos de
RACF desde una consola del sistema. Esta facilidad cobra especial importancia cuando, por algún
motivo, no se disponga de sesiones de TSO.
Es de destacar que un usuario final, que solo tenga acceso a regiones CICS, no tendrá la posibilidad de
ejecutar ningún comando de RACF.
Los comandos actúan siempre sobre la base primaria, y son replicados inmediatamente en la base de
backup (asumiendo que RACF esté configurado para mantener sincronizadas ambas bases).
Se listan a continuación los comandos de RACF que consideramos más relevantes:
Comando Abreviación Descripción

ADDUSER AU Define un usuario nuevo
ALTUSER ALU Modifica características de un usuario existente
DELUSER DU Borra un usuario
LISTUSER LU Lista las características de un usuario
ADDGROUP AG Define un nuevo grupo de usuarios

ALTGROUP ALG Modifica características de un grupo existente
DELGROUP DG Borra un grupo
LISTGRP LG Lista las características de un grupo
ADDSD AD Define un nuevo “perfil de dataset”

ALTDSD ALD Modifica características de un “perfil de dataset” existente
DELDSD DD Borra un “perfil de dataset”
LISTDSD LD Lista las características de un “perfil de dataset”
RDEFINE RDEF Define un nuevo perfil de recursos generales

RALTER RALT Modifica características de un perfil de recursos generales existente
RDELETE RDEL Borra un perfil de recursos generales
RLIST RL Lista las características de un perfil de recursos generales
PERMIT PE Modifica las listas de acceso de un perfil

PASSWORD PW Cambia la password de un usuario
CONNECT CO Conecta un usuario a un grupo
REMOVE RE Desconecta un usuario de un grupo
SEARCH SR Permite realizar búsquedas en la base de RACF
RACDCERT RACDCERT Permite la administración de certificados digitales
SETROPTS SETR Lista o modifica opciones de la SETROPTS
RVARY RVARY Lista, intercambia y activa/inactiva bases de RACF
Los comandos requieren operandos, algunos posicionales y otros no. A lo largo de la presente guía
analizaremos la mayoría de los comandos y describiremos sus operandos más relevantes. A modo de
ejemplo, mostramos a continuación un comando que da de alta un usuario en la base de RACF:

11
AU rh3472 NAME(‘juan’) DFLTGRP(rrhh) PASSWORD(abc123)
AU Comando básico, abreviación de ADDUSER.

rh3472 Identificador del usuario. Variable posicional que debe seguir al comando AU.
NAME Operando no posicional que define el nombre.
juan Valor del nombre.
DFLTGRP Operando no posicional que define el grupo default.
rrhh Valor del grupo default.
PASSWORD Operando no posicional que define la password inicial.
abc123 Valor de la password inicial –expirada-.
Ciertos operandos, si se omiten, toman un valor por defecto. En el caso anterior, por ejemplo, al no
haberse codificado explícitamente OWNER, quedará por defecto como OWNER del nuevo usuario
aquel que ejecute el comando ADDUSER.

12
3 - USUARIOS Y GRUPOS

Toda persona que deba ingresar a alguna aplicación dentro del entorno z/OS necesita tener un
identificador de usuario (userid). El mismo consiste en una cadena de caracteres alfanuméricos
(incluyendo los caracteres #, $ y @, conocidos como nacionales), con una longitud mínima de 1,
máxima de 8 y con la restricción de que el primer carácter no sea numérico. En el caso de usuarios de
TSO, la máxima longitud admisible es de 7 caracteres, debido a una restricción propia del TSO.
RACF solo permite el uso de mayúsculas para identificadores de usuarios y grupos (y, en general, para
casi todos los demás perfiles). De todos modos, si se ingresa información en minúsculas, la misma es
usualmente transformada automáticamente a mayúsculas, de modo que para el administrador resulta
como si RACF no distinguiera entre ambas.
Cada organización debe elegir una convención para los identificadores de sus usuarios, de acuerdo a sus
necesidades y preferencias. Conviene recalcar la importancia de la adopción de una buena
nomenclatura, ya que eso facilita en gran medida la administración posterior (y resulta particularmente
trabajoso renombrar gran cantidad de usuarios, si se descubre que la convención elegida inicialmente no
es adecuada).
Todo usuario debe ser definido en la base como miembro de un grupo de RACF, que pasa a constituir
su "grupo default" (default group). Adicionalmente, el usuario puede estar conectado a otros grupos.
Dicho de otro modo, si bien un usuario está eventualmente conectado a varios grupos, uno y solo uno de
ellos es su grupo default.
Los grupos son pues conjuntos de usuarios. Todo grupo de RACF tiene un identificador único (grupid),
que al igual que en el caso de usuarios, consiste en una cadena de caracteres alfanuméricos (incluyendo
#, $ y @); de longitud mínima 1 y máxima 8 y que no debe empezar con un número). El identificador
de un grupo de usuarios lo llamaremos simplemente “nombre del grupo”.
El nombre de un grupo no puede coincidir con el identificador de ningún usuario.
Los grupos de RACF se distribuyen de acuerdo a una estructura de árbol, que surge del hecho de que
todo grupo nuevo debe ser definido como subgrupo de otro existente. En lo más alto del árbol se
encuentra el grupo SYS1, que viene predefinido por IBM (no es posible cambiar su nombre). SYS1
resulta ser pues el único grupo que no tiene grupo superior (o sea, no es subgrupo de ningún otro).
3.2 - Administración de grupos de RACF

Todas las características de un grupo de RACF se encuentran almacenadas en un “perfil de grupo”. Este
perfil tiene distintos campos, de los cuáles solo describiremos los más relevantes.
NOMBRE Nombre del grupo.
DATA Información sobre el grupo, con una longitud máxima de 255 caracteres.
SUPGROUP Nombre del grupo superior.
OWNER Owner del grupo.
Con respecto al nombre, ya señalamos las condiciones que debe cumplir.

La Installation Data, como su nombre completo lo indica, es un campo dónde la organización almacena
información administrativa sobre el grupo que considere relevante. Normalmente, este campo contiene
una breve descripción del grupo.
El grupo superior es imprescindible, ya que todo grupo (excepto SYS1) debe ser subgrupo de algún otro
(“B tiene como grupo superior a A” o “B es un subgrupo de A” son 2 formas distintas de expresar lo
mismo).

13
El concepto de owner es particularmente importante, y se aplica a cualquier tipo de perfil en la base de

RACF. Todo perfil debe tener un owner, que puede ser un usuario o un grupo. En este caso particular,
esto es el owner de un grupo, el valor que puede tomar debe ser un usuario o bien el grupo superior.
Dicho de otro modo, no puede establecerse como owner de un grupo a otro que no sea su grupo
superior.
3.3 - Alta de un grupo

Sintaxis:
ADDGROUP|AG nombre [DATA(‘installation-data’)] [SUPGROUP(grupo)]
[OWNER(usuario/grupo)] [OMVS([GID(valor)])]
El nombre del grupo es requerido y debe estar a continuación del comando ADDGROUP.
Si no se especifica SUPGROUP, el valor que asume por defecto es el “actual grupo de conexión” del
usuario que ejecuta el comando.
Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando.
El operando OMVS solo debe codificarse si se quiere proveer al grupo de un segmento de OMVS. El
GID (Group IDentifier) debe ser un número comprendido entre 0 y 2147483647. Si se especifica
OMVS y se omite GID, el valor por defecto es 0000000000. Si se omite el operando OMVS, el grupo
simplemente queda definido sin este segmento.
Es frecuente, dada la cantidad de operandos que es necesario codificar en algunos casos, que los
comandos no entren en una única línea. Si se ejecutan desde un dataset o embebidos en un job, un guión
(-) al final de la línea indica que el comando continúa en la siguiente. También existe una opción dentro
del menú del ISPF que permite ingresar comandos en foreground que ocupen más de un renglón.
Ejemplo:
AG conta DATA(‘Subgerencia de Contabilidad’) SUPGROUP(finanzas) OWNER(finanzas)
Este comando define un nuevo grupo de nombre CONTA. El mismo se define como subgrupo del grupo
FINANZAS, que debe existir previamente (sino el comando falla). En este caso, se eligió definir como
owner a un grupo, que por lo tanto debe ser el grupo FINANZAS.
Autoridad requerida
Para definir un nuevo grupo, quien ejecuta el comando debe satisfacer alguna de las siguientes
condiciones:
Tener el atributo SPECIAL a nivel de sistema.
Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al grupo
superior del que se intenta definir.
Ser el owner del grupo superior.
Estar conectado al grupo superior con nivel de autoridad JOIN.
Para poder definir al grupo con algún “segmento no base” (por ejemplo, el segmento OMVS), el usuario
tiene que cumplir alguna de las siguientes condiciones:
Tener autoridad a través de perfiles apropiados en la clase FIELDS.

14
3.4 - Modificación de un grupo

Sintaxis:
ALTGROUP|ALG nombre [DATA(‘installation-data’)|NODATA] [SUPGROUP(grupo)]
[OWNER(usuario/grupo)] [OMVS([GID(valor)|NOGID])|NOOMVS]
Naturalmente, solo es necesario incluir aquellos operandos que correspondan a los campos que se desee
modificar. No se aplica, en este caso, ningún valor por defecto.
Ejemplo:
ALG conta DATA(‘Sector de Contabilidad - Jefatura’)
Este comando modifica la Installation Data del grupo CONTA.
Consideraciones:
Hacemos notar que el nuevo valor especificado en DATA reemplaza íntegramente al valor
anterior. No se puede modificar parcialmente este campo. Si se pretende agregar algo a
continuación de la DATA existente, debe ejecutarse el comando retipeando toda la DATA. Esto
no solo es válido para grupos, sino para la Installation Data de cualquier perfil en la base de
RACF.
No existe la opción de modificar el nombre de un grupo. La única forma que prevé RACF para
renombrar un grupo consiste en darlo de baja para luego redefinirlo con el nuevo nombre. Esto es
trabajoso, ya que antes de borrar el grupo viejo, debe tomarse debida nota de los usuarios que
tiene conectados, así como también de todas sus autorizaciones, de modo que el nuevo grupo
resulte un clon del anterior. Al no ser una tarea sencilla, conviene establecer desde el comienzo
una buena nomenclatura, de modo a evitar, dentro de lo posible, tener que rebautizar grupos en el
futuro.
Autoridad requerida
Para poder modificar el grupo superior, quien ejecuta el comando debe cumplir con alguna de las
condiciones siguientes:
Tanto para el actual grupo superior como para el futuro, satisfacer alguna de las opciones que se
enumeran:
- Ser el owner.
- Estar conectado con nivel de autoridad JOIN.
- Tener el atributo SPECIAL a nivel de un grupo que lo tenga dentro de su campo de acción.
Observemos que si el owner del grupo era su grupo superior, no podrá cambiarse el grupo superior sin
modificar asimismo el owner (ya que el único grupo que se admite como owner es el grupo superior)
Para poder especificar cualquier otro operando del comando ALTGROUP (con excepción del manejo
de segmentos no base), quien ejecuta el comando debe satisfacer alguna de las siguientes condiciones:
que se modifica.
Ser el owner del grupo.
Para poder agregar, modificar o deletear “segmentos no base” del grupo, quien ejecuta el comando debe
satisfacer alguna de las siguientes condiciones:

15
3.5 - Eliminación de un grupo

Sintaxis:
DELGROUP|DG nombre
Consideraciones:
RACF no permite borrar un grupo que tenga usuarios conectados. En consecuencia, como paso
previo al comando DELGROUP, deben ser removidos todos sus usuarios.
RACF no permite borrar un grupo que tenga subgrupos. Por lo tanto, debe modificarse el grupo
superior de todos aquellos grupos que sean subgrupos del que se quiere borrar.
RACF no permite borrar un grupo si existen en la base perfiles de dataset cuyo primer calificador
(High level Qualifier, o HLQ) coincida con el nombre del grupo. Los mismos deben deletearse
previamente a la ejecución de comando DELGROUP, ya que en caso contrario el comando falla.
La ejecución exitosa del comando DELGROUP no elimina las referencias al grupo que puedan
existir en otros perfiles de la base (por ejemplo, el grupo puede figurar en la lista de acceso de
perfiles de dataset o de recursos generales). Por esta razón, con el objeto de mantener la base
prolija (sin referencias a grupos inexistentes), el borrado del grupo debe ser acompañado de la
eliminación de todas las referencias al mismo que existan en la base. Mas adelante veremos que
IBM provee, a tal efecto, el utilitario IRRRID00.
Autoridad requerida
Para poder borrar un grupo, quien ejecuta el comando debe cumplir con alguna de las condiciones
siguientes:
que se pretende borrar.
Ser el owner del grupo superior.
Estar conectado al grupo superior con nivel de autoridad JOIN.
Ser el owner del grupo que se pretende deletear.
3.6 - Listado de un grupo

Sintaxis:
LISTGRP|LG nombre [OMVS]
Este comando, a diferencia de los anteriores, no efectúa ninguna modificación sobre la base de RACF.
Unicamente lista (en la pantalla de la terminal, si se ejecuta en foreground, o con salida a un dataset o al
spool, si se ejecuta en batchground) información relativa al grupo.
Ejemplo:
LG conta OMVS
La salida tendría el siguiente aspecto:
INFORMATION FOR GROUP CONTA
SUPERIOR GROUP=FINANZAS OWNER=FINANZAS CREATED=10.245
INSTALLATION DATA=SECTOR DE CONTABILIDAD - JEFATURA
NO MODEL DATA SET
TERMUACC

16
SUBGROUP(S)= PAGOS SUELDOS

USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS=
CONJF01 USE 001475 NONE
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
CONFJ02 USE 002487 NONE
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
OMVS INFORMATION
GID= 0000000015
Del listado precedente, se desprende claramente la siguiente información sobre el grupo CONTA:
El grupo superior es el grupo FINANZAS.
El owner del grupo CONTA es el grupo FINANZAS.
El grupo fue creado el día 245 del año 2010.
El grupo CONTA tiene 2 subgrupos, cuyos nombres son PAGOS y SUELDOS.
El grupo CONTA tiene 2 usuarios conectados, de identificadores CONFJ01 y CONFJ02.
El grupo CONTA tiene segmento de OMVS con un GID igual 15.
No describiremos, en este punto, el resto de la información listada, ya que para comprender ciertos
campos específicos se requieren nociones que se verán más adelante (MODEL y TERMUACC, por
ejemplo).
Autoridad requerida
Para listar el segmento base de un perfil de grupo, quien ejecuta el comando debe cumplir con alguna de
las condiciones siguientes:
que se pretende listar.
Tener el atributo AUDITOR a nivel de sistema.
Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al
grupo que se pretende listar.
Estar conectado al grupo con nivel de autoridad CONNECT o JOIN.
Para poder listar “segmentos no base” del grupo, quien ejecuta el comando debe satisfacer alguna de las
siguientes condiciones:
3.7 - Administración de usuarios de RACF

Todas las características de un usuario de RACF se encuentran almacenadas en un perfil de usuario, que
consta de un segmento base (obligatorio), más, opcionalmente, algunos segmentos no base (por
ejemplo, segmentos de TSO, OMVS, etc.). Todos los segmentos se componen de campos, de los cuales
nos ocuparemos en este punto únicamente de los más relevantes.

17
Segmento Base
USERID Identificador del usuario.
NAME Nombre asociado con el usuario, de longitud máxima 20.
DATA Información sobre el usuario, con una longitud máxima de 255 caracteres.
DFLTGRP Nombre del grupo default del usuario.
PASSWORD Password que se otorga usuario.
OWNER Owner del usuario.
Segmento de TSO
PROC Nombre del procedimiento de logon a TSO (default) para el usuario
ACCTNUM Código de cuenta (default) para el usuario
COMMAND Comando a ejecutarse durante el logon a TSO
SIZE Tamaño mínimo de la región, expresado en Kbytes, default para el usuario
MAXSIZE Tamaño máximo que el usuario puede requerir en el momento de logon
Segmento de OMVS
UID UID del usuario. Número entre 0 y 2147483647. 0 indica superusuario.
HOME Home directory del usuario.
PROGRAM Shell asignado.
Con respecto al identificador del usuario, ya señalamos anteriormente las condiciones que debe cumplir.
En el campo NAME, si se trata de una persona física, se pone usualmente su nombre y apellido. En el
caso de usuarios asociados a procesos, se puede colocar un nombre que identifique la tarea para la que
es utilizado.
En la DATA, la organización guarda información administrativa que considere importante sobre el
usuario. Por ejemplo, se puede incluir su número de documento y el sector de la empresa dónde
desempeña sus tareas.
El grupo default debe ser un grupo que exista previamente en la base de RACF.
La password inicial es una clave expirada, lo cual significa que el usuario es forzado a cambiarla en el
momento del logon inicial. Por esta razón, no es necesario que cumpla con las reglas para passwords
fijadas por la organización en la SETROPTS (esto se verá en detalle en el capítulo correspondiente).
Debe tener una longitud máxima de 8 caracteres.
Es de destacar que RACF permite también la autenticación a través de Password Phrases, que son
cadenas de caracteres alfanuméricos y especiales (incluyendo blancos), de longitud mínima 9 y máxima
100. Presentan una posibilidad más robusta que las passwords tradicionales, dada su mayor longitud.
Sin embargo, por el momento son de utilidad limitada ya que existen aplicaciones que no las soportan,
algunas de uso muy difundido. CICS, por ejemplo, acaba de anunciar el soporte de Password Phrases
para su versión 4.2, que recién estará disponible a mediados del 2011. También debemos señalar que,
aún cuando el usuario tenga asignada una Password Phrase, debe también obligatoriamente contar con
una password tradicional (que podría ser desconocida por el usuario, para que se vea obligado a
autenticarse usando su Password Phrase). Por lo tanto, si bien creemos importante mencionar su
existencia y entendemos que en el futuro van seguramente a desempeñar un rol relevante, no haremos
más referencias a ellas en el presente manual.
El OWNER del usuario puede ser cualquier otro grupo o usuario existente en la base de RACF.
El segmento de TSO solo debe definirse para usuarios que tengan que usar esta facilidad. La mayoría de
los parámetros especificados se convierten en los valores default para el usuario, quien puede
cambiarlos, de ser necesario, en la pantalla de logon a TSO.

18
El segmento de OMVS solo debe definirse para usuarios que lo necesiten. Existe incluso, a partir del
z/OS 1.11, la posibilidad de configurar RACF de forma que este segmento se le agregue
automáticamente a los usuarios la primera vez que invoquen algún servicio Unix que lo requiera.
3.8 - Alta de un usuario

Sintaxis:
ADDUSER|AU userid [NAME(‘nombre’)] [DFLTGRP(grupo)] [DATA(‘installation-data’)]
[PASSWORD(clave-inicial)|NOPASSWORD] [OWNER(usuario/grupo)]
[AUTHORITY(nivel)] [UACC(nivel)]
[SPECIAL|NOSPECIAL] [OPERATIONS|NOOPERATIONS] [AUDITOR|NOAUDITOR]
[RESTRICTED|NORESTRICTED] [GRPACC|NOGRPACC] [ADSP|NOADSP]
[CLAUTH(clase)|NOCLAUTH] [WHEN(DAYS(días) TIME(hora-inicio:hora-fin))]
[TSO(PROC(nombre-del-procedimiento-de-TSO) ACCTNUM(código-de-cuenta))]
[OMVS(UID(valor) PROGRAM(nombre-del-programa) HOME(directorio-inicial))]
El userid es requerido y debe estar inmediatamente a continuación del comando ADDUSER.
Si no se codifica NAME, este campo aparece como UNKNOWN cuando se lista el usuario a través del
comando LISTUSER.
Si no se especifica DFLTGRP, el valor que asume por defecto es el “actual grupo de conexión” del
usuario que ejecuta el comando.
Si no se especifica DATA, este campo queda vacío y al listar el usuario se muestra la leyenda “NO-
INSTALLATION_DATA”.
Si no se codifica PASSWORD, asume por defecto como password inicial el grupo especificado en el
operando DFLTGRP. Esto no es para nada recomendable desde el punto de vista de la seguridad, ya que
los nombres de los grupos suelen ser públicos. Por lo tanto, es aconsejable siempre especificar una
password, de modo a evitar que asuma el valor por defecto.
Si se especifica NOPASSWORD, y el usuario tiene también NOOIDCARD (que es el defecto), el
usuario adquiere el atributo PROTECTED, del cual hablaremos en más adelante.
Los atributos SPECIAL, OPERATIONS, AUDITOR, RESTRICTED, GRPACC, ADSP y CLAUTH no
se otorgan, salvo que se los codifique explícitamente.
Si se omite OWNER, el valor por defecto es el usuario que ejecuta el comando.
AUTHORITY indica el nivel de autoridad que tendrá el usuario como miembro de su grupo default. El
valor por defecto es USE. Más adelante se verán en detalle los posibles valores y su significado.
UACC indica el acceso universal del usuario para su grupo default. El valor por defecto es NONE. Mas
adelante, al analizar un ejemplo del comando LISTUSER, se verán en detalle los posibles valores y su
significado.
El parámetro WHEN especifica los días de la semana y las horas del día en los cuales el usuario está
autorizado a ingresar al sistema. Este chequeo se realiza únicamente en el momento en que RACF
procesa el pedido de logon. Por lo tanto, si el usuario ingresó en un día y horario válidos, pero su sesión
se extendió más allá de los límites permitidos, no será forzado a salir del sistema (naturalmente, en tal
caso, si cierra la sesión, ya no podrá reingresar). Estas restricciones no se aplican para la ejecución de
trabajos batch (o sea, un job del usuario puede iniciarse y ejecutarse fuera de los días y horarios
permitidos). Si no se especifica el operando WHEN, el valor por defecto es ANYDAY/ANYTIME, lo
cual autoriza al usuario a ingresar en cualquier día y horario. Por ejemplo, podría establecerse que el
usuario solo esté habilitado para ingresar al sistema lunes, miércoles y viernes de 8 a 19:30 horas. En tal
caso, debería codificarse el operando WHEN del siguiente modo:
WHEN(DAYS(monday wednesday friday) TIME(0800:1930))

19
Para los operandos TSO y OMVS, solo se indicaron los suboperandos más frecuentes, existiendo varios
otros. Si no se especifica TSO u OMVS, el usuario simplemente queda definido sin tal segmento.
Autoridad requerida
Para definir un nuevo usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones
siguientes:
Tener CLAUTH en la clase USER y verificar además alguno de los siguientes requisitos:
- Ser el owner del grupo default especificado en el comando ADDUSER.
- Estar conectado con nivel de autoridad JOIN al grupo default especificado en el comando
ADDUSER.
- Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al
grupo default especificado en el comando ADDUSER.
Para poder definir al usuario con algún segmento no base (por ejemplo, segmentos de TSO u OMVS),
quien ejecuta el comando tiene que cumplir alguna de las siguientes condiciones:
3.9 - Modificación de un usuario

Sintaxis:
ALTUSER|ALU userid
[NAME(‘nombre’)] [DFLTGRP(grupo)] [DATA(‘installation-data’)|NODATA]
[PASSWORD(clave-inicial)|NOPASSWORD] [EXPIRED|NOEXPIRED]
[OWNER(usuario/grupo)] [UAUDIT|NOUAUDIT]
[GROUP(nombre)] [AUTHORITY(nivel)] [UACC(nivel)]
[SPECIAL|NOSPECIAL] [OPERATIONS|NOOPERATIONS] [AUDITOR|NOAUDITOR]
[RESTRICTED|NORESTRICTED] [GRPACC|NOGRPACC] [ADSP|NOADSP]
[RESUME(mm/dd/aa) |NORESUME] [REVOKE(mm/dd/aa) |NOREVOKE]
[WHEN(DAYS(días) TIME(hora-inicio:hora-fin))]
[TSO(PROC(nombre-del-proc)|NOPROC ACCTNUM(código)|NOACCTNUM))|NOTSO]
[OMVS([UID(valor)|NOUID] [PROGRAM(nombre-del-programa)|NOPROGRAM]
[HOME(directorio-inicial)|NOHOME])|NOOMVS]
Naturalmente, solo es necesario incluir los operandos que corresponden a los campos que se quiere
modificar .No se aplica ningún valor por defecto en este caso.
DFLTGRP indica el nombre del nuevo grupo default del usuario, al cual debe encontrarse conectado
previamente. Observemos que el usuario continúa conectado a su antiguo grupo default.
EXPIRED|NOEXPIRED solo surte efecto si ha sido codificado el operando PASSWORD.
El valor por defecto es EXPIRED, el cual indica que el usuario está obligado a cambiar su password por
una nueva en el momento de su próximo logon. Por ello, en este caso, no es necesario que la password
otorgada cumpla con las reglas fijadas por la organización, que se encuentran especificadas en la
SETROPTS. Debe, de todos modos, tener una longitud máxima de 8 caracteres.
NOEXPIRED indica que el usuario no estará forzado a cambiar su password en el momento de su
próximo logon (aunque naturalmente puede hacerlo, si así lo desea y la aplicación lo permite). De todos
modos, ello no significa que su password nunca venza. El usuario, a menos que se le haya dado
NOINTERVAL a través del comando PASSWORD, se encuentra sujeto a la política usual de cambio
periódico de password establecida por la organización. Toda password dada con NOEXPIRED debe
adecuarse a las reglas fijadas en la SETROPTS.

20
GROUP indica el nombre de un grupo al cual el usuario se encuentra previamente conectado y sobre el
cual actuarán los nuevos valores especificados en los operandos AUTHORITY y UACC. Si se omite
GROUP, pero se codifica AUTHORITY o UACC, los mismos actúan sobre del grupo default del
usuario (aún en el caso en que se haya especificado DFLTGRP para cambiar el grupo default del
usuario, actúan sobre viejo).
REVOKE(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario no podrá acceder al
sistema. Si la fecha ingresada no es posterior a la fecha actual, RACF informa que la fecha no es válida,
y envía al usuario que ejecuta el comando un mensaje para que especifique una fecha futura (esto
último, suponiendo que el comando se ejecuta en foreground. Si la ejecución es en batch, simplemente
se ignora el operando, por fecha inválida). Mientras el usuario tenga una fecha de revocación futura, se
considera que tiene un REVOKE pendiente. Si se codifica REVOKE sin especificar fecha, el REVOKE
toma efecto la próxima vez que el usuario ingrese al sistema. En este caso, el usuario adquiere el
atributo REVOKED (más adelante veremos en detalle todos los atributos de usuario).
NOREVOKE tiene como efecto quitar la fecha de revocación futura, si el usuario la tuviera.
RESUME(mm/dd/aa) especifica una fecha futura a partir de la cual el usuario podrá acceder al sistema
nuevamente. Usualmente, se utiliza este operando para anular el efecto del REVOKE. En el caso en que
el usuario no tenga un REVOKE pendiente, o no tenga el atributo REVOKED, el RESUME(mm/dd/aa)
es ignorado. Mientras el usuario tenga una fecha de resume futura, se considera que tiene un RESUME
pendiente. Si se codifica RESUME sin especificar fecha, el RESUME toma efecto inmediatamente (o
sea, habilita al usuario a ingresar al sistema de inmediato) y le saca el atributo REVOKED, si lo tuviera.
NORESUME tiene como efecto quitar la fecha de resume futura, si el usuario la tuviera.
Si se especifican ambos operandos REVOKE(mm/dd/aa) y RESUME(mm/dd/aa), las fechas no deben
entrar en conflicto (básicamente, la fecha especificada en RESUME debe ser posterior a la fecha del
REVOKE). Por ejemplo, el siguiente comando inhabilita al usuario fin7632 a usar el sistema desde el
1/1/2010 hasta el 31/1/2010.
ALU fin7632 REVOKE(1/1/10) RESUME(31/1/10)
Con respecto al formato de la fecha, el mismo debe ser mes/día/año. Los ceros a la izquierda, para mes
y día, pueden ser omitidos (1/1/03 equivale a 01/01/03). El año debe ser siempre de 2 dígitos, y se
extiende a 4 de acuerdo al siguiente criterio:
aa se traduce en 20aa si aa es menor a 71
aa se traduce en 19aa si aa es mayor o igual a 71
Consideraciones:
Sólo puede cambiarse el grupo default de un usuario por otro grupo al cual se encuentre
previamente conectado. Si el grupo especificado en DFLTGRP no es un grupo al cual esté
conectado, el grupo default no es alterado. Esto no evita que el resto del comando se procese. Es
posible y frecuente que un comando de RACF solo resulte exitoso parcialmente.
No existe la opción de modificar el identificador de un usuario. La única forma prevista por
RACF para renombrar un usuario consiste en deletearlo y darlo de alta nuevamente con el nuevo
identificador. Esto es trabajoso, ya que antes de borrar el usuario viejo, debe tomarse debida nota
de los grupos a los que se encuentra conectado, así como también de todas las autorizaciones que
tiene, de modo que el nuevo usuario resulte un clon del anterior. Al no ser una tarea sencilla,
conviene establecer desde el comienzo una buena nomenclatura de usuarios, de modo a evitar,
dentro de lo posible, tener que rebautizar en el futuro.
Autoridad requerida
El nivel de autoridad requerido depende del campo del perfil de usuario que se pretenda modificar.
Mencionamos a continuación algunos casos, que consideramos los más relevantes. La lista no pretende
de ningún modo ser exhaustiva.

21
El atributo SPECIAL a nivel de sistema permite especificar cualquier operando, con excepción de
UAUDIT/NOUAUDIT.
Si el owner del usuario está dentro del campo de acción de un grupo en el cual el usuario tiene el
atributo SPECIAL, entonces puede especificar cualquier operando, con excepción de SPECIAL,
AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT.
Si es el owner del usuario, entonces básicamente puede especificar cualquier operando, con
excepción de SPECIAL, AUDITOR, OPERATIONS y UAUDIT/NOUAUDIT. Para otorgar
CLAUTH sobre una clase debe además tener él mismo CLAUTH sobre ella.
Todo usuario puede cambiar su NAME y DFLTGRP. Naturalmente, si decide cambiar su grupo
default, debe encontrarse previamente conectado al nuevo grupo que especifique.
Para poder otorgar los atributos SPECIAL, AUDITOR y OPERATIONS a nivel de sistema se
requiere el atributo SPECIAL a nivel de sistema.
Para especificar UAUDIT/NOUAUDIT, es necesario tener el atributo AUDITOR a nivel de
sistema, o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción.
Para agregar, modificar o deletear información de “segmentos no base” del usuario, se requiere el
atributo SPECIAL a nivel de sistema o bien tener suficiente autoridad en perfiles apropiados de la
clase FIELDS.
Si tiene autorización sobre el recurso IRR.PASSWORD.RESET de la clase FACILITY puede
otorgar una nueva password para cualquier usuario (ver 7.5).
3.10 - Eliminación de un usuario

Sintaxis:
DELUSER|DU userid
Este comando borra de la base de RACF el perfil del usuario, así como también elimina las conexiones
que el usuario pueda tener a distintos grupos. Por lo tanto, no solo deletea el perfil del usuario, sino que
también modifica los perfiles de los grupos a los cuales se encuentra conectado. Es habitual, como se ve
en este ejemplo, que un comando de RACF impacte sobre más de un perfil de la base.
Sin embargo, el comando DELUSER no elimina al usuario de otros perfiles de la base dónde pueda
figurar. Por ejemplo, el usuario puede estar en listas de acceso, o puede ser owner de algún otro perfil
de la base. Si bien la existencia de tales referencias no impide la ejecución exitosa del comando
DELUSER, no es una buena práctica dejar en la base referencias a usuarios inexistentes. Por lo tanto,
del mismo modo que en el caso de la eliminación de grupos, es apropiado identificarlas y borrarlas.
Consideraciones:
No es posible borrar un usuario si existen en la base perfiles de dataset cuyo HLQ sea igual al
identificador del usuario. Los mismos deben borrarse previamente, ya que en caso contrario el
comando DELUSER falla.
En concordancia con lo anterior, también deben renombrarse (o deletearse, si no fuese necesario
conservarlos) los datasets cuyo HLQ coincida con el identificador del usuario. Esto hay que
hacerlo antes de borrar los perfiles de dataset, para evitar, por un lado, tener que manipular
archivos “no protegidos”, así como también para preservar su nivel de protección, si alguno de
ellos tuviera un perfil discreto. Esto quedará claro en el capítulo siguiente, cuando tratemos
específicamente la protección de datasets.
Si el usuario a eliminar se encuentra trabajando dentro del sistema en el momento en que se
ejecuta el comando de baja, es muy posible que pueda seguir haciéndolo normalmente hasta que
cierre su sesión. Obviamente, una vez que salga del sistema, ya no podrá ingresar nuevamente.
Si resultara imprescindible que cese de inmediato toda actividad, se puede solicitar a los
operadores del equipo que cancelen todas las sesiones que pueda tener activas.

22
Como dar de baja a un usuario de manera adecuada puede llevar algo de tiempo, resulta útil,
como medida inicial, revocarle su acceso al sistema ejecutando el comando:
ALTUSER userid REVOKE
De este modo, el usuario queda imposibilitado de ingresar al sistema (si ya está adentro,
corresponden las mismas consideraciones que en el punto anterior) durante el tiempo que
insuman los pasos previos a la baja. Incluso, en algunas organizaciones, se va revocando
diariamente a los usuarios a ser dados de baja, hasta que al cabo de una semana, por ejemplo, se
ejecuta un proceso que los borra efectivamente.
Autoridad requerida
Para poder deletear un usuario, quien ejecuta el comando debe cumplir con alguna de las condiciones
siguientes:
Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al
usuario que se pretende eliminar.
Ser el owner del usuario.
Estar conectado a su grupo default con nivel de autoridad JOIN no es suficiente para poder deletear el
usuario.
3.11 - Listado de un usuario

Sintaxis:
LISTUSER|LU userid [TSO] [OMVS]
Este comando no efectúa ninguna modificación sobre la base de RACF. Únicamente lista información
relativa al usuario. Si se especifica el operando TSO u OMVS, se lista también tal segmento. Si no se
especifican especialmente, los segmentos no base no son listados (existen varios más que los dos
mencionados, pero no nos ocuparemos de ellos en esta guía).
Ejemplo:
LU fin7632 TSO OMVS
USER= FIN7632 NAME= PEREZ ALEJANDRA OWNER= FINADM CREATED= 10.158

DEFAULT-GROUP= FINANZAS PASSDATE= 10.308 PASS-INTERVAL= 30 PHRASEDATE=N/A
ATTRIBUTES= NONE
REVOKE DATE= NONE RESUME DATE= NONE
LAST-ACCESS= 10.309/09:48:25
CLASS AUTHORIZATIONS= NONE
INSTALLATION-DATA= DNI:24857632
NO-MODEL-NAME
LOGON ALLOWED (DAYS) (TIME)
---------------------------------------------------------------
ANYDAY ANYTIME
GROUP= FINANZAS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.158
CONNECTS= 857 UACC= NONE LAST-CONNECT= 10.309/09:48:25
CONNECT ATTRIBUTES= NONE
GROUP= COBROS AUTH= USE CONNECT-OWNER= FINADM CONNECT-DATE= 10.184
CONNECTS= 00 UACC= NONE LAST-CONNECT= UNKNOWN
CONNECT ATTRIBUTES= NONE
SECURITY-LEVEL= NONE SPECIFIED

23
CATEGORY-AUTHORIZATION
NONE SPECIFIED
SECURITY-LABEL= NONE SPECIFIED
TSO INFORMATION
-----------------------------
ACCTNUM= FINA01
PROC= IKJFIN
SIZE= 00008192
MAXSIZE= 00000000
USERDATA= 0000
COMMAND=
NO OMVS INFORMATION
Del listado precedente, se obtiene gran cantidad de información sobre el usuario FIN7632, entre la que
destacamos la siguiente:
El grupo default es el grupo FINANZAS.
El campo CREATED indica la fecha de creación del usuario, en formato juliano. En el ejemplo
expuesto, el usuario fue dado de alta el 7 de junio del año 2010 (día 158 del año 10).
El OWNER es FINADM, que en principio podría ser un grupo o un usuario. En caso de ser un
usuario, esto no significa que sea FINADM quién ejecutó el comando de alta. En ningún lugar
de la base de RACF está guardada la información sobre quién dio el alta (este dato debería
rastrearse en los registros tipo 80 del SMF, dónde se loguea información sobre los comandos de
RACF ejecutados).
PASSDATE indica la fecha en la que el usuario cambió su password por última vez. Todo
usuario puede cambiar su password en cualquier momento, si así lo desea, ya sea a través del
comando PASSWORD, o bien mediante los paneles de logon de ciertas aplicaciones (TSO o
CICS, por ejemplo). El valor 00.000 significa que el usuario tiene una password expirada. Esto
indica que aún no ha ingresado desde que el administrador se la otorgó.
PASS-INTERVAL establece la cantidad de días que la password de este usuario permanecerá
válida, contados a partir del día en que se cambió por última vez. El valor debe estar
comprendido entre 1 y 254. De todos modos, la cantidad de días pasados los cuáles el usuario es
forzado a cambiar su password surge del mínimo entre el valor del PASS-INTERVAL del
usuario y el valor global seteado en la SETROPTS. Por ejemplo, si el usuario tiene
PASS-INTERVAL=45 en su perfil, pero el valor de la SETROPTS es 30, tendrá que cambiar su
password obligatoriamente cada 30 días.
PASS-INTERVAL=N/A indica que el usuario tiene una password que nunca vence. Desde el
punto de vista de seguridad, esta es una opción poco recomendable. Es útil, sin embargo, para
usuarios que no corresponden a personas físicas (siempre y cuando se pueda tener certeza de que
nadie conoce su password). Si ambos campos PASSDATE y PASS-INTERVAL tienen el valor
N/A, entonces el usuario tiene el atributo PROTECTED, al cual nos referiremos más adelante.
ATTRIBUTES= NONE muestra que el usuario no posee ningún atributo particular a nivel de
sistema. Examinaremos posteriormente en detalle los posibles atributos que se le pueden otorgar
a un usuario.
El campo LAST-ACCESS indica fecha y hora en que el usuario ingresó al sistema por última
vez, con ciertas salvedades:
- Si al usuario se le da un RESUME, los valores del campo LAST-ACCESS son actualizados
con la fecha y hora en que se ejecutó el comando.

24
- Si se cambia la password del usuario, ya sea con el comando ALTUSER o PASSWORD, los
valores del campo LAST-ACCESS son actualizados con la fecha y hora en que se ejecutó el
comando.
- Si un job se ejecuta bajo la identidad del usuario, los valores del campo LAST-ACCESS son
igualmente actualizados con la fecha y hora de iniciación del job.
- Si el usuario nunca ingresó, el campo LAST-ACCESS muestra el valor UNKNOWN.
Es importante tener en cuenta estos detalles, para no interpretar erróneamente la información
brindada por el campo LAST-ACCESS.
LOGON ALLOWED (anyday anytime) significa que el usuario no tiene ninguna restricción de
día y horario para ingresar al sistema.
A continuación, en la salida del comando LU, figuran todos los grupos a los cuales el usuario está
conectado, mostrando varios parámetros que caracterizan cada conexión. El primer grupo listado es
siempre el grupo default del usuario (recordemos que todo usuario está conectado, como mínimo, a
su grupo default). Para cada uno de los grupos, la información mostrada tiene idénticos campos, que
describimos a continuación:
Un usuario es conectado a un grupo con un determinado nivel de autoridad. Este se muestra en el
campo AUTH, y sus posibles valores son: USE, CREATE, CONNECT y JOIN (enumerados en
orden jerárquico, o sea que cada uno incluye los privilegios del anterior). El valor por defecto es
USE, suficiente para la casi totalidad de los casos. Más adelante discutiremos en detalle los
alcances de cada uno de estos niveles.
CONNECT-OWNER es un campo que se mantiene por razones de compatibilidad con versiones
anteriores de RACF, pero que actualmente es totalmente irrelevante desde el punto de vista de
seguridad. El valor que asume por defecto es el usuario que conectó el usuario al grupo.
CONNECT-DATE muestra la fecha en que el usuario fue conectado al grupo.
El campo CONNECTS indica la cantidad de veces que el usuario ingresó al sistema
especificando este grupo en el momento de logon (tanto CICS como TSO permiten, por
ejemplo, especificar un grupo en la pantalla de logon). Como actualmente es muy habitual que la
opción GRPLIST esté activa en la SETROPTS (esto se analizará en detalle más adelante, en el
capítulo dedicado a la SETROPTS), no suele especificarse un grupo distinto del default en la
pantalla de logon. En virtud de ello, es frecuente que solo se incremente la cuenta del campo
CONNECTS para el grupo default del usuario, quedando el mismo en 00 para los otros grupos.
Así, en el ejemplo mostrado, el usuario FIN7632 se conectó 857 veces usando su grupo default,
de nombre FINANZAS, mientras que la cuenta para el otro grupo al que está conectado, llamado
COBROS, permanece en 00. Esto no significa, de ninguna manera, que el usuario no esté
haciendo uso de su conexión al grupo COBROS. Obtener acceso a un recurso protegido gracias
d pertenecer a un cierto grupo no incrementa el valor del campo CONNECTS para ese grupo.
Solo se incrementa el contador cuando el usuario se loguea a una aplicación especificando al
grupo como “grupo de conexión”.
El campo UACC en la conexión de un usuario a un grupo puede tomar los valores NONE,
READ, UPDATE, CONTROL o ALTER, siendo NONE el valor por defecto. Este parámetro,
que se especifica a nivel de grupo, determina el UACC de los perfiles de dataset o de recursos
generales que el usuario eventualmente defina en la base de RACF, siempre y cuando haya
iniciado la sesión especificando este grupo como “grupo de conexión”, y se cumpla que:
- El usuario no codifica explícitamente el operando UACC en la definición del perfil. En caso
contrario, este valor prevalece.
- Para perfiles de recursos generales, la clase de RACF correspondiente no debe tener
DFTUACC especificado en la CDT (Class Descriptor Table), pues de otro modo el perfil
toma por defecto ese valor.

25
Por ejemplo, si un usuario tiene UACC(READ) especificado en su conexión a su grupo default,

(y se loguea a TSO sin cambiar el grupo en el panel de logon, de modo que su grupo de
conexión sea efectivamente su grupo default), entonces si define un perfil de dataset y no
especifica UACC, el perfil quedará definido con UACC(READ).
La enorme mayoría de los usuarios no define perfiles en la base de RACF, por lo cual el UACC
de la conexión no tiene mayor relevancia. Para los usuarios administradores, que deben definir
nuevos perfiles en la base de RACF, conviene de todos modos conservar el valor default
UACC=NONE en la conexión a cada uno de sus grupos. De este modo, los perfiles de RACF
que definan tendrán por defecto UACC(NONE), lo cual es conveniente desde el punto de vista
de seguridad. Si necesitaran crear un perfil con un UACC distinto de NONE, no tienen más que
codificar dicho operando con el valor deseado en el comando de definición del perfil.
El campo LAST-CONNECT muestra fecha y hora en la que el usuario ingresó por última vez al
sistema con este grupo como "grupo de conexión". Recordemos que si el usuario no especifica
grupo en la pantalla de logon (TSO, CICS, etc.), el grupo de conexión resulta ser su grupo
default. Por lo tanto, es muy frecuente que el campo LAST-CONNECT solo esté actualizado
para el grupo default del usuario (tal como sucede con el campo CONNECTS). Si el usuario
nunca inició una sesión con determinado grupo, el LAST-CONNECT para este grupo muestra el
valor UNKNOWN.
El campo LAST-CONNECT suele ser un indicador más fiable respecto del día y hora del último
ingreso del usuario al sistema ya que, a diferencia del campo LAST-ACCESS, no se actualiza si
se le da al usuario un RESUME o una nueva password (pero si es actualizado cuando se inicia
un job bajo su identidad). De todos modos, es frecuente que los valores de los campos LAST-
ACCESS y LAST-CONNECT para el grupo default coincidan.
CONNECT-ATTRIBUTES muestra los atributos del usuario relativos a su conexión al grupo.
Los usuarios se dividen en atributos a nivel de sistema, que figuran en el campo ATTRIBUTES,
y atributos a nivel de grupo. Más adelante los analizaremos en detalle.
REVOKE DATE y RESUME DATE funcionan, a nivel de grupo, de modo similar a como lo
hacen a nivel global. Sin embargo, a nivel grupal, se establecen a través del comando
CONNECT, que veremos cuándo analicemos las conexiones de usuarios a grupos.
SECURITY-LEVEL, CATEGORY-AUTHORIZATION y SECURITY-LABEL son campos
relacionados con un nivel extra de seguridad que provee RACF, realmente poco utilizado.
Básicamente, fue implementado por IBM para que RACF cumpla con los requisitos que
establece el gobierno de los EEUU para obtener la calificación B1 en materia de seguridad. Si la
organización no usa esta seguridad adicional, los 3 campos deben mostrar NONE SPECIFIED
para todos los usuarios de la base de RACF.
Autoridad requerida
Todo usuario puede listar el segmento base de su propio perfil. Para listar el segmento base del perfil de
otro, debe cumplir con alguna de las condiciones siguientes:
Tener el atributo SPECIAL a nivel de un grupo que tenga dentro de su campo de acción al
usuario a listar.
Tener el atributo AUDITOR a nivel de sistema.
Tener el atributo AUDITOR a nivel de un grupo que tenga dentro de su campo de acción al
usuario a listar.
Tener acceso READ sobre el recurso IRR.LISTUSER de la clase FACILITY (ver 7.5).

26
Para poder listar “segmentos no base”, debe satisfacer alguna de las siguientes condiciones:
3.12 - Comando PASSWORD

Sintaxis:
PASSWORD|PW
[USER(userid)] [PASSWORD(clave-actual clave-nueva)] [INTERVAL(valor)|NOINTERVAL]
El comando PASSWORD permite a un usuario cambiar su clave, así como también su INTERVAL.
USER indica el usuario cuya password se va a modificar.
Si se codifica USER y no se establece la opción INTERVAL|NOINTERVAL, la password del usuario
es reseteada al valor de su grupo default y queda expirada (el usuario deberá forzosamente cambiarla en
el momento de logon). Si, por el contrario, se codifica USER junto con alguna de las opciones
INTERVAL|NOINTERVAL, la password del usuario no se altera, siendo modificado únicamente su
intervalo de validez. El operando PASSWORD es ignorado si se ha especificado USER.
El operando PASSWORD permite cambiar la clave propia en cualquier momento. Para ello, no debe
especificarse el operando USER. Resulta conveniente ingresar PASSWORD sin especificar los valores
de las passwords, ya que en tal caso RACF promptea al usuario para que los introduzca por pantalla y
no resultan visibles mientras se los tipea.
INTERVAL establece el valor del campo PASS-INTERVAL del usuario especificado en el operando
USER (si éste se omitiera, el cambio afecta al usuario que ejecuta el comando). El valor debe estar
comprendido entre 1 y 254, no pudiendo exceder el máximo global fijado en la SETROPTS. Si se
codifica INTERVAL sin especificar valor, se toma por defecto el máximo global de la SETROPTS.
NOINTERVAL establece que la clave del usuario nunca vence, en cuyo caso el campo PASS-
INTERVAL muestra el valor N/A. Tal cual indicáramos anteriormente, debe usarse esta opción solo en
contados casos que lo justifiquen.
El comando PASSWORD es realmente poco usado, ya que lo habitual es que los usuarios cambien su
password a través de la pantalla de logon de las aplicaciones (TSO, CICS, etc.), y no se preocupen en
modificar su INTERVAL. Es imprescindible, sin embargo, para otorgar a un usuario una password que
nunca venza.
Autoridad requerida
Todo usuario está autorizado a modificar su propia password y el intervalo de validez de la misma (no
puede, sin embargo, usar la opción NOINTERVAL, salvo que tenga la autoridad suficiente).
Para resetear la password de otro usuario al valor de su grupo default, quien ejecuta el comando debe
cumplir con alguna de las siguientes condiciones:
Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dentro de su campo de
acción.
Para cambiar el intervalo de validez de la password de otro usuario, o especificar NOINTERVAL, quien
ejecuta el comando debe cumplir con alguna de las siguientes condiciones:
acción.

27
3.13 - Atributos de usuario

Los atributos son facultades extraordinarias, o restricciones, que se le pueden otorgan a un usuario.
Como ya mencionáramos anteriormente, se pueden dar tanto a nivel de sistema (system level attributes),
en cuyo caso de denominan simplemente atributos del usuario, como a nivel de la conexión del usuario
con un grupo, en cuyo caso se llaman atributos relativos a grupos. Cuando son especificados a nivel de
sistema, actúan en todo momento. En cambio, cuando se otorgan a nivel de grupo, dependiendo del
atributo, o actúan de manera más acotada, o bien solo lo hacen cuando el usuario ingresó especificando
ese grupo en la pantalla de logon. En un principio, analizaremos los “atributos a nivel de sistema”.
Luego indicaremos de que manera actúan cuando se los especifica a nivel de grupo.
Atributos a nivel de sistema

Los atributos que se pueden otorgar a nivel de sistema son los siguientes:
o SPECIAL
o AUDITOR
o OPERATIONS
o CLAUTH
o REVOKE
o GRPACC
o ADSP
o RESTRICTED
o PROTECTED
o UAUDIT
En general, se otorgan, ya sea en el momento de la creación del usuario (comando ADDUSER), o bien
con posterioridad (comando ALTUSER), especificando como parámetro no posicional el nombre del
atributo (con excepción de CLAUTH, que debe ir acompañado del nombre de una clase, y de
PROTECTED). Los atributos REVOKE y UAUDIT solo pueden otorgarse con el comando ALTUSER,
es decir con posterioridad a la creación del usuario.
Para quitarlos, debe ejecutarse el comando ALU, poniendo como parámetro el nombre del atributo
antecedido por el prefijo NO, con las siguientes excepciones:
- El atributo REVOKE se quita especificando el operando RESUME.
- El atributo PROTECTED se quita otorgando una password al usuario.
Ejemplos:
1) ALTUSER jefa524 AUDITOR
Este comando le da al usuario JEFA524 el atributo AUDITOR a nivel de sistema.
2) ALTUSER jefa524 SPECIAL NOOPERATIONS
Este comando le otorga al usuario JEFA524 el atributo SPECIAL a nivel de sistema, y le saca el
atributo OPERATIONS a nivel de sistema, si lo tuviera.
3) ALTUSER jefa524 CLAUTH(tsoproc) RESUME
Este comando le otorga al usuario JEFA524 el atributo CLAUTH en la clase TSOPROC a nivel de
sistema, y le saca el atributo REVOKE (si lo tuviera a nivel de sistema).
Atributo SPECIAL
El atributo SPECIAL a nivel de sistema confiere al usuario la autoridad para ejecutar cualquier
comando de RACF. Por lo tanto, el atributo SPECIAL otorga un absoluto control sobre la base de

28
RACF, pudiendo los usuarios que lo tienen, definir, modificar y deletear cualquier perfil, así como
también modificar las opciones de configuración de RACF establecidas en la SETROPTS, con la
siguiente importante excepción:
El atributo SPECIAL no permite listar ni modificar opciones relativas a auditoría (que quedan, por lo
tanto, reservadas a los usuarios con atributo AUDITOR). Más específicamente, un usuario con atributo
SPECIAL (y sin atributo AUDITOR) no podrá listar ni modificar:
o Parámetros SAUDIT, CMDVIOL, OPERAUDIT, AUDIT CLASSES, LOGOPTIONS,
SECLABELAUDIT, SECLEVELAUDIT, APPLAUDIT de la SETROPTS.
o Atributo UAUDIT en perfiles de usuario.
o Campo GLOBALAUDIT en perfiles de dataset o de recursos generales.
Solo un usuario con atributo SPECIAL a nivel de sistema puede dar o quitar este atributo a otro usuario.
En una base de RACF recién inicializada, el usuario IBMUSER, provisto por IBM, tiene el atributo
SPECIAL. Ingresando con este usuario, debe otorgarse el atributo SPECIAL a los administradores de
RACF de la organización. A continuación, luego de verificar que los nuevos administradores pueden
trabajar normalmente, resulta muy recomendable, desde el punto de vista de seguridad, quitarle al
usuario IBMUSER el atributo SPECIAL y darle los atributos REVOKE, RESTRICTED y
PROTECTED (no es posible eliminarlo). En efecto, como el usuario IBMUSER existe en toda base de
RACF, es un blanco ideal de hackeo, razón por la cual mantenerlo inutilizable es lo más aconsejable.
El atributo SPECIAL no brinda acceso alguno a los recursos del sistema protegidos por RACF (con 2
excepciones particulares, que son el acceso a “datasets no catalogados” y “datasets no protegidos”). Sin
embargo, el usuario con atributo SPECIAL tiene la posibilidad de otorgarse a sí mismo el acceso a
cualquier perfil de la base con el máximo nivel de autoridad. Por lo tanto, indirectamente, tiene acceso
irrestricto a los recursos protegidos del sistema.
Debido al enorme poder que confiere el atributo SPECIAL a nivel de sistema, solo un muy reducido
conjunto de usuarios -encargados de la administración centralizada de RACF- deben tenerlo. No es
sencillo recomendar una cantidad óptima, ya que ello depende de la complejidad de la base (la cantidad
total de usuarios es solo uno de los aspectos a considerar) y de la organización. Sin embargo, podemos
señalar que, siempre que ello no comprometa la eficiencia de la administración, cuantos menos usuarios
con atributo SPECIAL existan, mejor. Normalmente, deberían sobrar los dedos de las manos para
contar la cantidad de usuarios con atributo SPECIAL a nivel de sistema. Es por cierto recomendable,
para su uso en una situación de emergencia, conservar bajo sobre y en lugar seguro un usuario con este
atributo.
Atributo AUDITOR
Los usuarios con atributo AUDITOR pueden listar la información completa de cualquier perfil de la
base de RACF y de la SETROPTS (incluidas aquellas opciones que no se le muestran a un usuario con
atributo SPECIAL), así como también utilizar el comando SEARCH de búsqueda y el utilitario
IRRUT100 (permite buscar y listar las ocurrencias de un usuario o grupo en la base de RACF). Pueden,
asimismo, modificar las opciones de logging para usuarios, perfiles de dataset, perfiles de recursos
generales y las opciones de auditoría globales establecidas en la SETROPTS. Fuera de las opciones
relativas a auditoría, el atributo AUDITOR no confiere autoridad para modificar ningún dato en la base
de RACF. Tampoco otorga acceso a ningún recurso protegido.
El utilitario DSMON brinda importante información para auditar el sistema. Sólo los usuarios con
atributo AUDITOR pueden utilizarlo (salvo que el programa ICHDSM00, invocado por la herramienta,
se encuentre protegido en la clase PROGRAM, en cuyo caso es necesario tener acceso al mismo).
El atributo AUDITOR debe ser otorgado criteriosamente, y únicamente a los usuarios que desempeñen
tareas globales de auditoría. Resulta aconsejable que los usuarios con atributo SPECIAL no tengan el
atributo AUDITOR, de modo de no concentrar excesivo poder en una única persona.

29
El atributo AUDITOR a nivel de sistema solo puede ser otorgado o quitado por un usuario con atributo
SPECIAL a nivel de sistema. Por lo tanto, con respecto a la observación anterior, si se pretende una
buena separación de funciones en la organización, debe controlarse que los usuarios administradores de
RACF que tienen el atributo SPECIAL no se otorguen a sí mismos el atributo AUDITOR. Para ello,
basta con analizar el logging de los comandos de RACF ejecutados, que se obtiene de los registros tipo
80 del SMF.
Atributo OPERATIONS
Este atributo, a diferencia de los anteriores, otorga al usuario acceso a gran cantidad de recursos
protegidos por RACF. En efecto, un usuario con atributo OPERATIONS a nivel de sistema tiene acceso
ALTER -el máximo posible- a todos los perfiles en las clases DATASET, DASDVOL, GDASDVOL,
TAPEVOL, PSFMPL, VMBATCH, VMCMD, VMMDISK, VMNODE, VMRDR (las últimas cinco
totalmente irrelevantes para z/OS, ya que se relacionan con VM), con las siguientes importantes
salvedades:
1) Si el usuario figura explícitamente en la lista de acceso del perfil con un nivel de autoridad
menor, entonces ése será su nivel de acceso. En efecto, a la hora de determinar el nivel de acceso
de un usuario sobre un perfil, la presencia del identificador del usuario en la lista de acceso es
mandatoria y toma preeminencia por sobre los eventuales grupos a los que está conectado o el
nivel de autoridad implícito dado por el atributo OPERATIONS. En un capítulo posterior
analizaremos en detalle el proceso de chequeo de autoridad de un usuario sobre un recurso que
lleva a cabo RACF.
2) Si el usuario no está en la lista de acceso del perfil, pero figuran en la misma uno o más grupos a
los cuales se encuentra conectado (asumimos que la instalación tiene la opción List of Groups
Checking Active en la SETROPTS, lo cual es la configuración habitual hoy en día), entonces su
nivel de autoridad será el más permisivo dado por sus grupos.
Ejemplo:
Supongamos que el usuario FIN5214 tiene el atributo OPERATIONS a nivel de sistema, que
está conectado únicamente a los grupos FINANZAS y CONTA, y que existe en la base un perfil
de dataset CUIL.** con la siguiente lista de acceso
FINANZAS UPDATE
CONTA READ
COBROS ALTER
En este caso, el nivel de autoridad del usuario FIN5214 sobre el perfil CUIL.** será UPDATE,
es decir el más permisivo dado por sus grupos (ya que no figura explícitamente FIN5214 en la
lista de acceso). El atributo OPERATIONS no entra en juego ya que existen en la lista de acceso
del perfil grupos a los cuales el usuario está conectado.
3) Security levels, categories y security labels también pueden limitar el acceso implícito a un
perfil dado por el atributo OPERATIONS. Sin embargo, ya mencionamos que son opciones
poco utilizadas que no analizaremos.
En virtud de las salvedades expuestas concluimos que, para un usuario con el atributo OPERATIONS,
la presencia de su identificador de usuario o de alguno de sus grupos en la lista de acceso de un perfil
(de una clase dónde actúe el atributo OPERATIONS) solo sirve para eventualmente reducir su nivel de
autoridad.
El atributo OPERATIONS a nivel de sistema solo puede ser otorgado o quitado por un usuario con
atributo SPECIAL a nivel de sistema. Se trata de un atributo que brinda gran poder de acceso, razón por
la cual debe ser otorgado con suma cautela, y en contadísimos casos. Más aún, es perfectamente posible
(e incluso recomendable) no tener usuarios con atributo OPERATIONS a nivel de sistema. Por ejemplo,
para los usuarios de administración de storage, existen mecanismos alternativos al atributo
OPERATIONS para brindarles acceso a los recursos que requieren sus funciones. En cualquier caso,

30
otorgar el atributo OPERATIONS no suele ser más que una solución fácil (que se paga a expensas de la
seguridad) para evitar identificar exactamente los recursos a los que precisa acceder el usuario.
Atributo CLAUTH
Este atributo, que significa Class Authority, se otorga para una (o varias) clases de RACF, y solo es
aplicable a nivel de sistema. Las clases para las cuáles es válido son la clase USER o cualquier otra
clase definida en la CDT (GROUP y DATASET quedan pues excluidas).
Básicamente, poseer el atributo CLAUTH para una determinada clase autoriza al usuario a definir
nuevos perfiles en ella (y el cualquier otra con idéntico POSIT number), teniendo en cuenta las
siguientes salvedades:
1) La opción GENERICOWNER de la SETROPTS, que veremos en el capítulo correspondiente,
puede limitar la posibilidad de crear perfiles en una clase dada por el atributo CLAUTH.
2) Tener únicamente CLAUTH en la clase USER no autoriza a dar de alta un nuevo usuario en la
base de RACF. Adicionalmente, se debe ser el owner del grupo default del usuario a definir, o
bien estar conectado al mismo con nivel de autoridad JOIN.
El atributo CLAUTH sobre una clase brinda una bastante limitada capacidad de administración sobre
sus perfiles. En efecto, si bien permite definir nuevos perfiles, no permite modificar, borrar, o listar
perfiles ya existentes (siempre y cuando estas acciones no estén posibilitadas por algún otro tipo de
autoridad). Si el usuario con el atributo CLAUTH define un nuevo perfil sin especificar owner, queda
por defecto como dueño del perfil y por lo tanto con poder de administración casi total sobre el mismo.
En cambio, si especifica un owner distinto de su usuario, ya no podrá actuar sobre él una vez creado.
CLAUTH resulta, de todos modos, útil como herramienta de descentralización de ciertas tareas de
administración de RACF, y es bastante utilizado en muchas organizaciones. Para estar autorizado a
otorgarlo sobre una determinada clase, debe cumplirse alguna de las siguientes condiciones:
Tener CLAUTH sobre esa clase, y además estar autorizado a modificar el perfil del usuario (por
ejemplo, siendo su owner).
Atributo REVOKE
El atributo REVOKE a nivel de sistema impide al usuario el logon a cualquier aplicación (TSO, CICS,
IMS, etc.), así como también la ejecución de trabajos batch. Únicamente las Started Task pueden
arrancar con un usuario revocado, aunque es posible que experimenten inconvenientes posteriores,
dependiendo de lo que hagan.
El atributo REVOKE, a diferencia de los anteriores, no solo puede ser otorgado por un usuario con la
suficiente autoridad (atributo SPECIAL u owner del usuario), sino que también puede ser dado
automáticamente por RACF en alguna de las siguientes situaciones:
1) Si en la SETROPTS está especificado que “el usuario será revocado después de N intentos
consecutivos y fallidos de password”, entonces al (N+1) intento consecutivo de password
inválida el usuario es revocado. Naturalmente, un ingreso válido vuelve la cuenta a 0.
2) Si en la SETROPTS está especificado que “el usuario será automáticamente revocado después
de N días de inactividad”, y transcurrieron al menos (N+1) días desde su último ingreso al
sistema, el usuario será revocado por RACF en el momento del intento de logon. Cabe aclarar
que, aunque se haya excedido el tiempo de inactividad estipulado, hasta tanto el usuario no
intente loguearse al sistema no adquirirá el atributo REVOKE, ya que RACF lo otorga al
procesar la solicitud de logon.
Con respecto a las situaciones recién descriptas, merecen una consideración particular los usuarios con
atributo SPECIAL a nivel de sistema. En efecto, RACF no los revoca automáticamente, sino que emite
un mensaje por consola solicitando al operador, o bien que confirme la revocación, o bien que otorgue

31
un intento adicional de ingreso de password u omita la inactividad, según sea el caso. Sin este
tratamiento diferenciado, sería perfectamente posible que una persona revocara intencionalmente
(mediante ingresos consecutivos de passwords incorrectas) a todos los usuarios con atributo SPECIAL
de la organización, generando una situación delicada de la cual no es sencillo recuperarse.
Atributo GRPACC
El atributo GRPACC (Group Access) a nivel de sistema funciona del siguiente modo:
Si un usuario con GRPACC se encuentra conectado a un grupo A y define un perfil de dataset cuyo
HLQ es A (suponiendo que tenga autoridad suficiente para hacerlo), automáticamente se agregará en la
lista de acceso al grupo A con autoridad UPDATE. Se trata de un atributo poco utilizado, y para
otorgarlo o quitarlo es necesario tener el atributo SPECIAL, o bien ser el owner del perfil del usuario.
Atributo ADSP
ADSP significa Automatic Data Set Protection. Si un usuario tiene este atributo a nivel de sistema, cada
vez que cree un dataset permanente en disco (o en cartucho, si la clase TAPEVOL está activa y la
opción TAPEDSN está especificada en la SETROPTS), RACF automáticamente le definirá un perfil
discreto de dataset.
Siendo la tendencia actual la de utilizar solo perfiles de dataset genéricos, pues son más sencillos de
administrar y presentan varias ventajas sobre los discretos, el atributo ADSP ha caído francamente en
desuso. Existe la opción NOADSP a nivel de la SETROPTS que inhibe el eventual atributo ADSP que
puedan tener los usuarios.
Para otorgar o quitar el atributo ADSP es necesario, o bien tener el atributo SPECIAL, o bien ser el
owner del perfil del usuario. Para setear ADSP|NOADSP a nivel de la SETROPTS es necesario tener el
atributo SPECIAL a nivel de sistema.
Atributo RESTRICTED
Este atributo es solo aplicable a nivel de sistema. Se trata de un atributo de carácter limitativo, que
restringe casi completamente los recursos a los cuáles puede acceder el usuario. En efecto, un usuario
con el atributo RESTRICTED no puede obtener acceso a un recurso protegido por RACF ni por una
regla en la clase GLOBAL, ni por el UACC del perfil protector, ni por la presencia de “*” en las listas
de acceso. Dicho de otro modo, un usuario con atributo RESTRICTED solo puede acceder a aquellos
recursos para los cuales se encuentre explícitamente autorizado, ya sea porque su identificador de
usuario, o alguno de los grupos a los que está conectado, figura en las listas de acceso del perfil con el
nivel de autoridad requerido.
El atributo RESTRICTED es útil en situaciones dónde se requiere tener un absoluto control de los
recursos a los que debe acceder el usuario. Antes de otorgarlo, es vital realizar un detallado
relevamiento de todos los recursos a los que necesita acceder y con qué nivel de autoridad, de modo de
no provocar una interrupción en las tareas operativas.
Para otorgar o quitar el atributo RESTRICTED a un usuario, es necesario, o bien tener el atributo
SPECIAL, o bien ser el owner de su perfil.
Atributo PROTECTED
Un usuario con atributo PROTECTED (protegido) no puede loguearse a ninguna aplicación del sistema
que requiera el uso de una password. Por ejemplo, no puede iniciar sesiones de TSO, CICS, NETVIEW,
etc. Si alguien intenta loguearse con un usuario que tenga el atributo PROTECTED, RACF
directamente rechaza el pedido de logon sin considerarlo ni siquiera un intento fallido por password
inválida. Se trata de usuarios sin password que resultan inmunes a la revocación automática por
ingresos consecutivos de passwords erróneas. Sin embargo, sí están sujetos a la eventual revocación
automática por inactividad.

32
Básicamente, se trata de un atributo muy útil para aquellos usuarios asociados con started tasks que no
necesiten loguearse a ninguna aplicación. Para estos usuarios, el atributo PROTECTED asegura no solo
que no se puedan utilizar para ingresar a ninguna aplicación, sino que también elimina la posibilidad de
que se los revoque (voluntaria o involuntariamente) por ingresos consecutivos de passwords inválidas.
Los usuarios de las regiones CICS, por ejemplo, son excelentes candidatos para este atributo.
Se otorga a un usuario el atributo PROTECTED, ya sea en el momento de su creación (comando
ADDUSER) o con posterioridad (comando ALTUSER), especificando el operando NOPASSWORD.
Ejemplo: ALTUSER userid NOPASSWORD
Cuando un usuario tiene este atributo, los campos PASSDATE y PASS-INTERVAL de la salida del
comando LISTUSER muestran el valor N/A.
Para quitar el atributo PROTECTED, basta con darle al usuario una password, ejecutando el comando:
ALTUSER userid PASSWORD(password)
Para otorgar el atributo PROTECTED, se debe cumplir alguna de las siguientes condiciones:
acción.
Atributo UAUDIT
El atributo UAUDIT (User Audit) indica que RACF grabe registros tipo 80 del SMF toda vez que el
usuario efectúe alguna de las siguientes acciones:
Ejecute un comando de RACF (con excepción de los comandos LISTUSER, LISTGROUP,
LISTDSD, RLIST y SEARCH, que nunca se registran dada su baja criticidad).
Intente acceder a un recurso protegido, resulte el acceso fallido o exitoso (independientemente
de la configuración de auditoría que tenga el perfil protector del recurso), excepto en el caso en
que el acceso haya sido autorizado por una regla en la clase GLOBAL.
Defina algún nuevo recurso cuya creación esté controlada por RACF (la alocación de un nuevo
dataset, por ejemplo).
Para poder otorgar o quitar el atributo UAUDIT, se debe tener el atributo AUDITOR a nivel de sistema,
o bien a nivel de un grupo que tenga al usuario dentro de su campo de acción. El atributo SPECIAL,
incluso a nivel de sistema, no permite listar -y mucho menos dar o quitar- este atributo.
No se debe abusar del atributo UAUDIT ya que puede provocar un aumento muy considerable de la
cantidad de registros SMF grabados por RACF, con los consiguientes problemas de tipo operativo que
ello acarrea. Es conveniente otorgarlo solo cuando se requiera un monitoreo estricto de la actividad de
un determinado usuario, y por un período limitado de tiempo.
Atributos a nivel de grupo

Los atributos que se pueden otorgar a nivel de grupo son los siguientes:
o SPECIAL
o AUDITOR
o OPERATIONS
o REVOKE
o GRPACC
o ADSP

33
Se otorgan a través de comando CONNECT, que se verá en detalle más adelante.

Ejemplos:
1) CO fina857 GROUP(finanzas) AUDITOR
Este comando conecta al usuario FINA857 al grupo FINANZAS con atributo AUDITOR a nivel de
grupo. Si el usuario FINA857 ya se encontrara conectado al grupo FINANZAS, solo modifica la
conexión agregando el atributo AUDITOR.
2) CO fina857 GROUP(finanzas) SPECIAL RESUME
La presencia del parámetro RESUME hace presuponer que el usuario FINA857 ya se encuentra
conectado al grupo FINANZAS (si no fuese el caso, sería irrelevante). En tal caso, el comando modifica
la conexión, eliminando el atributo REVOKE a nivel de grupo (si lo tuviere) y otorgando al usuario
FINA857 el atributo SPECIAL a nivel del grupo FINANZAS.
Para comprender cómo funcionan los atributos a nivel de grupo, es fundamental explicar el concepto de
“campo de acción de un grupo” (scope of the group), el cual ya ha sido mencionado repetidas veces
pero aún no explicado.
Campo de acción de un grupo

El campo de acción de un grupo está compuesto por una serie de grupos, perfiles de usuario, perfiles de
dataset y perfiles de recursos generales, de acuerdo al siguiente criterio:
Aparte del grupo en cuestión, se encuentran dentro de su campo de acción todos sus subgrupos, los
subgrupos de sus subgrupos, y así sucesivamente, siempre y cuándo se cumpla que el owner de un
grupo sea su grupo superior. Si el owner de un grupo dentro de la rama del inicial es un usuario (en
lugar de su grupo superior), este grupo (y todos los que se desprendan de él en el árbol) queda fuera del
campo de acción. Es decir, si se cumple que cada grupo tenga como owner su grupo superior, los grupos
dentro del campo de acción de un grupo son exactamente todos aquellos que pertenecen a su rama en el
árbol de grupos.
Ejemplo:
GRUPO1
Owner: GRUPOA
GRUPO2 GRUPO3
Owner: GRUPO1 Owner: GRUPO1
GRUPO4 GRUPO5 GRUPO6

Owner: GRUPO2 Owner: GRUPO3 Owner: USU1
En el diagrama anterior, la flecha significa “tiene como subgrupo a”. Por lo tanto, se tiene que:
o GRUPO1 tiene 2 subgrupos: GRUPO2 y GRUPO3.
o GRUPO2 tiene un único subgrupo: GRUPO4.
o GRUPO3 tiene 2 subgrupos: GRUPO5 y GRUPO6.
o GRUPO4, GRUPO5 y GRUPO6 no tienen subgrupos.
Los grupos que forman parte del campo de acción del GRUPO1 son:
GRUPO1, GRUPO2, GRUPO3, GRUPO4 y GRUPO5.

34
GRUPO6 no forma parte del campo de acción de GRUPO1 ya que el owner no es su grupo superior,
sino el usuario USU1.
Los usuarios dentro del campo de acción de un grupo son todos aquellos cuyo owner es un grupo que se
encuentre a su vez dentro del campo de acción. No están dentro del campo de acción aquellos usuarios
cuyo owner sea otro usuario. La eventual pertenencia de un usuario a un grupo dentro del campo de
acción no implica que el usuario se encuentre dentro del campo de acción. En otras palabras, el factor
determinante para establecer si determinado usuario está o no dentro del campo de acción de un grupo
es su owner y no sus conexiones.
En cuanto a perfiles de dataset, se encuentran dentro del campo de acción del grupo aquellos que
cumplen con alguna de las siguientes condiciones:
Su owner es un grupo que está dentro del campo de acción.
Su owner es un usuario dentro del campo de acción.
Su HLQ es un usuario o grupo dentro del campo de acción.
En lo referido a perfiles de recursos generales, se encuentran dentro del campo de acción del grupo
aquellos que cumplen con alguna de las siguientes condiciones:
Su owner es un grupo que está dentro del campo de acción.
Su owner es un usuario dentro del campo de acción.
Por ejemplo, volviendo al caso del diagrama, perfiles de recursos generales cuyo owner es GRUPO5
están dentro del campo de acción de GRUPO1, mientras que aquellos cuyo owner es GRUPO6 no lo
están. Asimismo, si USU2 es un usuario cuyo owner es GRUPO2 y USU22 es un usuario cuyo owner
es USU2, entonces USU2 está dentro del campo de acción de GRUPO1, mientras que USU22 no. En
consecuencia, todo perfil de recursos generales cuyo owner sea USU2 está dentro del campo de acción
de GRUPO1, mientras que aquellos cuyo owner sea USU22 están afuera.
Atributo SPECIAL a nivel de grupo

Básicamente, un usuario con atributo SPECIAL a nivel de un grupo tiene total autoridad para
administrar los recursos que están dentro de su campo de acción. Se trata pues de un usuario SPECIAL
pero cuya injerencia se ve restringida al campo de acción del grupo al cual se encuentra conectado con
el atributo SPECIAL.
En cuanto a la definición de nuevos perfiles, se tiene que:
o Puede definir nuevos perfiles de dataset cuyo HLQ sea un grupo o un usuario dentro de su
campo de acción.
o Para crear nuevos perfiles de recursos generales debe tener CLAUTH sobre la clase
correspondiente.
o Para crear nuevos usuarios debe tener CLAUTH en la clase USER.
Limitaciones:
o Un usuario con atributo SPECIAL a nivel de grupo no puede modificar opciones que afecten
globalmente al sistema. Por lo tanto, no tiene autoridad suficiente para modificar la
configuración global de RACF establecida en la SETROPTS.
o No puede otorgar los atributos SPECIAL, AUDITOR ni OPERATIONS a "nivel de sistema"
(aunque si puede otorgarlos a nivel de grupo, para grupos que se encuentren dentro del campo
de acción). Para otorgar CLAUTH sobre una clase debe tener él mismo CLAUTH sobre esa
misma clase.
o Aún dentro del campo de acción del grupo, se enfrenta con restricciones similares con respecto
a las opciones de auditoría a las que tiene un usuario con atributo SPECIAL a "nivel de
sistema".

35
Atributo AUDITOR a nivel de grupo

Un usuario con atributo AUDITOR a nivel de grupo tiene las mismas autoridades que uno con atributo
AUDITOR a nivel de sistema, pero restringida a los recursos (grupos, usuarios, perfiles de dataset y de
recursos generales) que se encuentran dentro de su campo de acción. No está habilitado a modificar
opciones globales de auditoría, aunque si está autorizado a listar la información completa de la
SETROPTS.
Atributo OPERATIONS a nivel de grupo

Un usuario con atributo OPERATIONS a nivel de grupo tiene las mismas autoridades que uno con
atributo OPERATIONS a nivel de sistema, pero restringida a los recursos (perfiles de dataset y de
recursos generales) que están dentro de su campo de acción.
Atributo REVOKE a nivel de grupo

Un usuario con atributo REVOKE a nivel de un determinado grupo no puede acceder al sistema
especificando ese grupo como "grupo de conexión" ni puede obtener acceso a un recurso protegido
como miembro del grupo. En definitiva, estar conectado a un grupo con la conexión revocada es
similar, desde el punto de vista de seguridad, a no pertenecer al mismo.
Con respecto al uso del REVOKE con fecha, ya se analizó previamente cómo funciona a "nivel de
usuario", siendo el comportamiento a nivel de grupo análogo.
Atributo GRPACC a nivel de grupo

Sólo actúa si el grupo en cuestión es el “actual grupo de conexión” del usuario. Su funcionamiento es
entonces igual al del atributo GRPACC a nivel de sistema (afectará a todos los “perfiles de dataset de
grupo” que defina el usuario, siempre y cuando esté conectado al grupo dado por el HLQ, aún cuando
éste no se encuentre dentro del campo de acción del grupo sobre el que tiene efectivamente el atributo
GRPACC).
Atributo ADSP a nivel de grupo

Sólo actúa si el grupo en cuestión es el “actual grupo de conexión” del usuario. En tal caso, funciona
igual que el atributo ADSP a nivel de sistema. Se trata, como ya hemos observado, de un atributo muy
poco utilizado.
3.14 - Conexión de un usuario a un grupo

Un usuario queda conectado automáticamente a su grupo default al ser dado de alta. Para conectarlo a
otro grupo, o bien para modificar características de una conexión ya existente, debe usarse el comando
CONNECT, en tanto que para desconectarlo debe emplearse el comando REMOVE. A continuación,
analizaremos en detalle ambos comandos.
Comando CONNECT
Sintaxis:
CONNECT|CO userid [GROUP(nombre)] [OWNER(usuario/grupo)] [AUTHORITY(nivel)]
[REVOKE(mm/dd/aa)] [RESUME(mm/dd/aa)] [ADSP|NOADSP] [AUDITOR|NOAUDITOR]
[GRPACC|NOGRPACC] [OPERATIONS|NOOPERATIONS]
[SPECIAL|NOSPECIAL] UACC(nivel)
Como ya señalamos, este comando también se utiliza para modificar algún parámetro de una conexión
ya existente (no existe un comando exclusivo de modificación de conexión). Si la conexión ya existe, el
comando solo modifica los parámetros especificados (no se aplica ningún valor por defecto).
El userid es requerido y debe estar inmediatamente a continuación del comando CONNECT.

36
Si no se codifica GROUP, el comando conecta por defecto al usuario al “actual grupo de conexión” de
quién ejecuta el comando (que suele ser su grupo default). Debe tenerse cuidado con esto, ya que
muchas veces no es el efecto buscado, sino que simplemente se omite el grupo por distracción.
El OWNER de la conexión es totalmente irrelevante. Su valor por defecto es el identificador del usuario
que ejecuta el comando CONNECT.
AUTHORITY indica el nivel de autoridad del usuario como miembro del grupo, que analizaremos en
detalle más adelante en este mismo capítulo. USE es el valor por defecto.
Por defecto, no se le asigna al usuario ningún atributo a nivel del grupo.
UACC asume por defecto el valor NONE.
Autoridad requerida
Para conectar un usuario a un grupo (o modificar parámetros de una conexión ya existente) a través del
comando CONNECT, el usuario que ejecuta el comando debe cumplir alguna de las condiciones
siguientes:
Tener el atributo SPECIAL a nivel de grupo, y el grupo al cual se pretende conectar al usuario
encontrarse dentro de su campo de acción.
Estar conectado al grupo con nivel de autoridad CONNECT o JOIN. En caso de tener nivel de
autoridad CONNECT, no puede conectar al usuario con nivel de autoridad JOIN (suponiendo
que no detente otro tipo de atributo que se lo permita, como SPECIAL a nivel de sistema).
Para otorgar o quitar los atributos SPECIAL, AUDITOR u OPERATIONS a “nivel del grupo”, el
usuario que ejecuta el comando debe tener el atributo SPECIAL, ya sea a nivel de sistema, o a nivel de
un grupo que tenga al grupo en cuestión dentro de su campo de acción.
Comando REMOVE
Sintaxis:
REMOVE|RE userid [GROUP(nombre)] [OWNER(usuario/grupo)]
Este comando desconecta un usuario de un grupo. No permite modificar parámetros de la conexión
(esto debe hacerse con el comando CONNECT).
El userid es requerido y debe estar inmediatamente a continuación del comando REMOVE.
GROUP indica el nombre del grupo del cual se desea desconectar al usuario. Si se omite, asume por
defecto el nombre del “actual grupo de conexión” de quien ejecuta el comando REMOVE.
Con respecto al operando OWNER, funciona del siguiente modo: supongamos que se pretende
desconectar al usuario A del grupo B.
Si A es owner de perfiles de dataset cuyo HLQ es B, RACF no permite la desconexión, salvo
que se codifique el operando OWNER a través del cual se especifica un usuario o grupo que se
convertirá en el nuevo owner de estos perfiles. Si se pone un usuario como OWNER, debe estar
conectado al grupo.
Si A no es owner de ningún perfil de dataset cuyo HLQ es B, entonces el operando OWNER es
irrelevante y puede omitirse.
Observación:
No se puede desconectar a un usuario de su grupo default. Por lo tanto, suponiendo que el usuario
USUA está conectado únicamente al grupo GRPB (que por lo tanto es su grupo default) y que se

37
pretende que USUA quede conectado únicamente al grupo GRPC, debería ejecutarse una secuencia de
comandos similar a la siguiente:
1. CONNECT USUA GROUP(GRPC) conecta USUA a GRPC
2. ALTUSER USUA DFLTGRP(GRPC) cambia el grupo default de USUA por GRPC
3. REMOVE USUA GROUP(GRPB) desconecta USUA de GRPB
Ya se describió detalladamente en secciones anteriores el significado de los parámetros de la conexión
(ver ejemplo del comando LISTUSER y parámetros a nivel de grupo). Sólo restan por analizar los
posibles niveles de autoridad de un usuario dentro de un grupo.
Autoridad requerida
Para desconectar un usuario de un grupo, el usuario que ejecuta el comando debe cumplir alguna de las
condiciones siguientes:
Tener el atributo SPECIAL a nivel de grupo, y el grupo del cual se pretende desconectar al
usuario encontrarse dentro de su campo de acción.
Estar conectado al grupo con nivel de autoridad CONNECT o JOIN.
Niveles de autoridad de un usuario en un grupo

Los posibles niveles son:
1. USE
2. CREATE
3. CONNECT
4. JOIN
Se enumeraron de modo que cada nivel de autoridad incluye (y excede) los privilegios del anterior.
Nivel USE
Un usuario conectado a un grupo con nivel de autoridad USE está habilitado a:
o Ingresar al sistema especificando ese grupo como “grupo de conexión”.
o Acceder a recursos protegidos a los cuáles el grupo se encuentre autorizado.
Se trata del nivel de autoridad suficiente para la casi totalidad de los casos.
Nivel CREATE
Adicionalmente, el nivel de autoridad CREATE permite:
o Alocar nuevos datasets cuyo HLQ sea el grupo.
o Definir nuevos perfiles de dataset cuyo HLQ sea el grupo. Observemos que si queda el usuario
como owner, puede posteriormente administrarlos.
Sin embargo, salvo que se encuentre autorizado por otro motivo, el nivel de autoridad CREATE no
permite deletear datasets cuyo HLQ sea el grupo en cuestión.
Nivel CONNECT
Adicionalmente, el nivel de autoridad CONNECT permite:
o Conectar al grupo usuarios ya existentes en la base de RACF, otorgándoles nivel de autoridad
USE, CREATE o CONNECT.

38
o Modificar parámetros de la conexión al grupo de usuarios ya conectados.

o Desconectar usuarios del grupo con el comando REMOVE.
o Listar la información del grupo con el comando LISTGRP.
En el caso de ejecutar el comando CONNECT al grupo, puede especificar cualquier operando, con
excepción de SPECIAL|NOSPECIAL, AUDITOR|NOAUDITOR y OPERATIONS|NOOPERATIONS.
Nivel JOIN
Adicionalmente, el nivel de autoridad JOIN permite:
o Si tiene el atributo CLAUTH(USER), definir nuevos usuarios dentro del grupo, con nivel de
autoridad USE, CREATE, CONNECT o JOIN.
o Conectar al grupo usuarios ya existentes en la base de RACF, con nivel de autoridad JOIN.
o Crear nuevos grupos de RACF que sean subgrupos del grupo en cuestión.
o Borrar subgrupos del grupo con el comando DELGROUP.

39
4 - PROTECCIÓN DE DATASETS

Los datasets son, por excelencia, el tipo de recurso que permite proteger RACF. Más aún, en sus
primeras versiones, que datan de la década del 70, los archivos eran los únicos recursos sobre los cuáles
RACF controlaba el acceso. Con el correr del tiempo y la aparición de nuevas versiones, tanto RACF
como los distintos componentes del sistema operativo (y productos) fueron evolucionando, de modo
que hoy en día RACF permite proteger una enorme variedad de recursos aparte de los datasets.
Conceptualmente, es de suma importancia distinguir un “dataset” de un “perfil de dataset”.
Un dataset es simplemente un archivo, cuya existencia es absolutamente independiente de
RACF. Utilizaremos indistintamente los términos dataset y archivo.
Un “perfil de dataset” es una entidad que existe en la base de RACF y se crea, modifica y
elimina a través del uso de comandos de RACF. La clase de RACF que los agrupa es la clase
DATASET.
Ambos se vinculan del siguiente modo: los perfiles de dataset contienen información que emplea RACF
para responder los requerimientos que reciba de acceso a archivos. Dicho más sencillamente, los
perfiles de dataset son una suerte de reglas que protegen el acceso a datasets.
Datasets
En el entorno z/OS, los archivos pueden residir en disco o en cartucho, y vienen identificados por un
nombre cuya longitud máxima es de 44 caracteres. La cadena de caracteres que lo conforma se divide
en calificadores, de longitud mínima 1 y máxima 8, separados entre sí por un punto (.) (los puntos
forman parte del nombre, o sea que cuentan con respecto al máximo de 44).
El primer carácter de cada calificador debe ser alfabético (A hasta Z) o nacional (#, @, $). Los restantes
pueden ser alfabéticos, numéricos (0 a 9), nacionales o un guión (-). No se distinguen mayúsculas de
minúsculas.
No existe un límite para la cantidad de calificadores que pueda tener un dataset, más allá del que surge
obviamente de la longitud máxima permitida en el nombre. El primer calificador se abrevia HLQ (High
level Qualifier).
Ejemplos:
PROD1.FINANZAS.A2009 Nombre válido, con 3 calificadores. PROD1 es el HLQ.
BASEPERS Nombre válido, de un único calificador.
TEST1.2010 Nombre inválido, pues el segundo calificador empieza con
un número, lo que no está permitido.
Perfiles de Dataset
Los perfiles de dataset se dividen en 2 tipos:
• Discretos
• Genéricos.
Más adelante analizaremos en detalle las diferencias entre unos y otros. Por el momento digamos que,
en sus primeras versiones, los únicos perfiles de dataset que admitía RACF eran los discretos, que
protegen un único archivo. Con posterioridad, surgieron los perfiles de dataset genéricos, que resultaron
más prácticos y fáciles de administrar. A diferencia de los discretos, dónde debía existir un perfil por
cada dataset protegido, un único perfil genérico permite proteger una cantidad ilimitada de archivos de
nombres similares. La tendencia actual es a utilizar casi exclusivamente perfiles de dataset genéricos,
aunque para ciertas situaciones muy particulares los perfiles discretos continúan siendo una mejor
opción.

40
Los perfiles de dataset siguen las mismas convenciones para sus nombres que los archivos, con las
siguientes salvedades:
o Deben tener 2 o más calificadores.
o El HLQ debe coincidir con un usuario o grupo existente en la base de RACF. Los
denominaremos “perfil de dataset de usuario” o “perfil de dataset de grupo”, según sea el caso.
o Con excepción del HLQ, pueden utilizarse en los siguientes calificadores los caracteres
comodín: %, *, **. El doble asterisco solo puede usarse si la opción EGN (Enhanced Generic
Naming) está activa en la SETROPTS. Estos 3 símbolos también se denominan caracteres
genéricos o variables.
En todo lo que sigue, vamos a asumir que la clase DATASET está seteada como GENERIC y
GENCMD, y que la opción EGN -que habilita el uso del ** en los perfiles de dataset- está activa, lo
cual es lo habitual en todas las organizaciones. Estas opciones se establecen en la SETROPTS y se
analizarán en detalle en el capítulo correspondiente. Por otro lado, salvo que aclaremos lo contrario,
supondremos que todos los archivos residen en disco (también llamados DASD, sigla de Direct Access
Storage Device).
4.2 - Perfiles discretos

Un perfil discreto de dataset debe tener idéntico nombre que el archivo que pretende proteger. Por lo
tanto, los caracteres %, * y ** no están permitidos.
Los perfiles discretos de dataset guardan una íntima relación con el archivo que protegen. Por ejemplo,
solo es posible definir un perfil discreto de dataset si realmente existe un archivo con ese nombre en el
volumen indicado. Más aún, al proteger un archivo discretamente, ya sea en la VTOC del disco para los
NOVSAM, o en la entrada del catálogo para los VSAM, un bit se activa indicando que el archivo está
protegido por un perfil discreto. Se dice en tal caso que el archivo está RACF-indicado.
Si se deletea un archivo protegido por un perfil discreto, automáticamente se borra de la base de RACF
el perfil de dataset correspondiente.
4.3 - Perfiles genéricos

Los perfiles genéricos, ampliamente más usados que los discretos, pueden o no tener en sus nombres los
caracteres %, * y **. Cuándo no tienen ningún carácter genérico, se los conoce como “perfiles
genéricos completos” y solo protegen al archivo de idéntico nombre, si existiera (lo cual no es requisito
para que se pueda definir el perfil, como en el caso de los discretos). Si, en cambio, tienen alguno de los
caracteres comodín, entonces “cubren” una gran cantidad de eventuales datasets, en virtud del
significado que posee cada uno de los caracteres genéricos, que detallamos a continuación. Como ya
señaláramos, suponemos la opción EGN activa en la SETROPTS. En caso contrario, el ** no es válido
en perfiles de dataset y el * cambia ligeramente su significado.
Signo porcentual (%)
Variable que indica un único carácter cualquiera en esa posición (con excepción del “.”)
Ejemplo: TEST.FINAN.A200%
Asterisco (*)
Para esta variable, caben distintas posibilidades:
Si forma parte de un calificador que contiene otros caracteres, debe ser el carácter final. En tal
caso indica que en esa posición puede haber 0 o más caracteres hasta completar el calificador.
Ejemplo: TEST.FIN*

41
Si constituye un calificador completo, indica que en esa posición puede existir cualquier
calificador pero que debe necesariamente existir uno.
Ejemplo: TEST.*.A2002
Doble asterisco (**)

Esta variable debe usarse como un calificador entero, y no puede utilizarse más de una vez por perfil.
Indica la presencia de 0 o más calificadores en esa posición.
Ejemplo: TEST.**.A2002
Recordemos que el HLQ de todo perfil de dataset debe ser un usuario o grupo definido en la base de
RACF. Por lo tanto, no está permitido el uso de caracteres genéricos en el primer calificador.
4.4 - Cómo determina RACF el perfil protector de un dataset

Diremos que un perfil de dataset “cubre” a un determinado archivo si el nombre del archivo está
alcanzado por el molde establecido por el perfil.
Ejemplo:
Perfiles:
1. TEST.FINANZAS.A2002 discreto
2. TEST.FINANZAS.A2002 genérico completo
3. TEST.FINANZAS.**
4. TEST.FINAN%%%.*
5. TEST.FINAN*.*
6. TEST.*.A*
7. TEST.FINANZAS.A%
8. TEST.*.A2002.*
Los 6 primeros perfiles cubren al archivo TEST.FINANZAS.A2002, mientras que los números 7 y 8 no
lo hacen (el 7 solo contempla un único carácter luego de la “A” del último calificador, mientras que el *
final en el 8 exige la existencia de un cuarto calificador).
Por lo tanto, como muestra el ejemplo, muchos perfiles de dataset pueden cubrir al mismo archivo. Sin
embargo, a la hora de determinar la protección, RACF se guía por el principio del perfil más específico.
Esto significa que, dado un archivo, o bien RACF no lo encuentra protegido, o bien determina un único
perfil que lo protege (que puede resultar discreto o genérico), que llamamos “perfil protector”.
Para determinar el perfil protector, RACF procede del siguiente modo:
Si existe un perfil discreto para el archivo, entonces éste será su perfil protector.
Si no existe un perfil discreto, RACF busca todos los perfiles genéricos que lo cubren (si no existiera
ninguno, simplemente el archivo no estaría protegido), y procede a compararlos, de izquierda a derecha.
En el primer carácter en que encuentre alguna diferencia, se descartan aquellos más genéricos, de
acuerdo al siguiente criterio:
- Los caracteres “no genéricos” son más específicos que las variables.
- Para las variables, el orden, desde el menos al más genérico, es %, * y **.
Siguiendo este procedimiento, RACF siempre determina, a lo sumo, un único perfil protector para un
dataset. Si volvemos al ejemplo anterior, notamos que los perfiles del 1 al 6 están ordenados del más al
menos específico. En este caso, el perfil discreto actúa como perfil protector del archivo
TEST.FINANZAS.A2002
Un perfil discreto se distingue de un genérico completo de igual nombre por no presentar, cuando se lo
lista, el símbolo (G) característico de los perfiles genéricos (ver 4.10).

42
Si el dataset no tiene un perfil discreto, el comando:

LISTDSD DATASET(‘nombre-del-archivo’) GENERIC ALL
lista el perfil protector del dataset codificado en el operando DATASET (o sea, el genérico más
específico que lo cubre). Mas adelante analizaremos el comando LISTDSD en detalle.
Consideraciones importantes:
RACF no brinda la posibilidad de proteger datasets particionados a nivel de miembros
(members). Solo se puede proteger una biblioteca de manera global, a través de un único perfil de
dataset. Por lo tanto, si un miembro particular requiriera un tratamiento diferenciado en cuanto a
su seguridad, se lo debería aislar en otra biblioteca y protegerla de manera adecuada.
En el caso de archivos VSAM, solo es necesario proteger el nombre del cluster. Los nombres de
los restantes componentes del VSAM (data e index) no intervienen en el momento de resolver
sobre una solicitud de acceso.
4.5 - Niveles de autoridad para perfiles de dataset

Tanto en el UACC, como en las listas de acceso, existen distintos niveles de autoridad que se pueden
especificar para perfiles de dataset. Estos son los siguientes:
o NONE
o EXECUTE
o READ
o UPDATE
o CONTROL
o ALTER
Se enumeraron desde el más restrictivo al más permisivo. Cada nivel incluye y excede los privilegios
del anterior. Su significado se muestra en la tabla siguiente:
NONE No permite acceder al dataset.

EXECUTE Se utiliza exclusivamente para bibliotecas de módulos. Este nivel de autoridad permite
ejecutar programas de la librería, pero no autoriza a copiarlos. Su implementación suele
ser problemática. Aconsejamos usar READ en lugar de EXECUTE.
READ Permite acceder al dataset únicamente para lectura. Cabe señalar que READ es suficiente
para copiar o imprimir el archivo.
UPDATE Permite tanto leer como modificar el dataset. No autoriza, sin embargo, a deletearlo,
renombrarlo o moverlo.
Sobre archivos VSAM, permite las operaciones normales de I/O.
CONTROL Para archivos NOVSAM, es equivalente a UPDATE.
Sobre archivos VSAM, permite un nivel de acceso más amplio que UPDATE (improved
control interval processing).
ALTER Permite leer, modificar, renombrar, mover y deletear el dataset.
Sobre perfiles discretos, otorga además la posibilidad de administrar el perfil,
modificando casi cualquier campo -incluida la lista de acceso. También permite borrar el
perfil de la base.
Sobre perfiles genéricos no otorga ningún privilegio administrativo. Autoriza asimismo a
alocar nuevos datasets que queden protegidos por este perfil.

43
4.6 - Administración de perfiles de dataset

Ya señalamos anteriormente las restricciones que existen con respecto al nombre de estos perfiles.
Analizaremos ahora en detalle los comandos necesarios para su administración. A diferencia de los
perfiles de grupo y usuarios, los perfiles de dataset tienen listas de acceso (access lists). Existen 2 tipos:
Lista de acceso estándar

Es la que se utiliza en la enorme mayoría de los casos. Contiene un listado de grupos y usuarios,
acompañados cada uno de un determinado nivel de autoridad. Puede eventualmente también figurar una
entrada *.
Lista de acceso condicional

A través de esta lista se puede otorgar acceso a un dataset siempre y cuando se cumplan ciertas
condiciones (que se encuentren previstas, naturalmente). Por ejemplo, puede autorizarse a un usuario a
acceder a un archivo únicamente cuando se encuentre logueado en una determinada terminal o consola.
No analizaremos en detalle todas las condiciones manejables a nivel de la lista de acceso condicional,
ya que ello escapa al objetivo de este texto introductorio. De todos modos, para los requerimientos
usuales de seguridad, la lista de acceso estándar suele ser suficiente.
4.7 - Definición de un perfil de dataset

Sintaxis:
ADDSD|AD ‘nombre-del-perfil’ [DATA(‘installation-data’)] [OWNER(usuario/grupo)]
[UACC(nivel)] [{GENERIC|MODEL|TAPE}] [{NOSET|SET|SETONLY}]
[FROM(perfil2)] [FCLASS(clase)] [FGENERIC] [FVOLUME(volumen)]
[UNIT(unidad)] [VOLUME(volumen)] [WARNING] [NOTIFY(usuario)]
[AUDIT(tipo-de-acceso(nivel-de-acceso)…)]
El nombre-del-perfil es requerido y debe estar inmediatamente a continuación del comando ADDSD. Si
contiene caracteres genéricos (%, *, o **), entonces el perfil creado resulta genérico, aún cuando se
omita el operando GENERIC. Si el nombre no contiene estos caracteres, entonces se creará un perfil
discreto, a menos que se codifique explícitamente el operando GENERIC, en cuyo caso resultará un
“perfil genérico completo”.
La DATA del perfil es un campo de uso administrativo, de longitud máxima 255 caracteres.
El OWNER del perfil debe ser un usuario o grupo existente. Si es un “perfil de dataset de grupo” y se
especifica un usuario como owner, debe necesariamente estar conectado al grupo. Si no se codifica
OWNER, queda como tal el usuario que ejecutó el comando (salvo que el HLQ sea un usuario distinto,
en cuyo caso éste queda como owner). Notemos que ser dueño de un perfil de dataset no otorga acceso
a los eventuales archivos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de
acceso a través del comando PERMIT.
El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal
Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y
ALTER, que ya se analizaron previamente. Básicamente, el UACC establece el nivel de acceso que
tendrá sobre los archivos protegidos por el perfil todo usuario que no se encuentre explícitamente en la
lista de acceso (ni ninguno de sus grupos) ni que tenga algún nivel de acceso particular por otro motivo
(atributo OPERATIONS, por ejemplo). En un capítulo posterior estudiaremos con todo detalle el
proceso que sigue RACF para determinar el nivel de autoridad de un usuario sobre un recurso. Si no se
especifica UACC, el valor por defecto es el UACC que tiene el usuario que ejecuta el comando en su
“actual grupo de conexión” (que, como señaláramos anteriormente, conviene que sea NONE, por
motivos de seguridad).

44
GENERIC debe obligatoriamente especificarse si se pretende definir un “perfil genérico completo”. Si

el nombre del perfil contiene algún carácter genérico, no es necesario codificar GENERIC (aunque
puede hacerse).
MODEL indica que se va a definir un perfil discreto que luego será utilizado como modelo para la
definición de futuros perfiles de dataset. Si en el nombre del perfil figura algún carácter genérico, el
operando MODEL es ignorado. Si no existen en el nombre tales caracteres, los operando GENERIC y
MODEL son incompatibles, siendo el último codificado el que prevalece. Cuando se especifica
MODEL, no es necesario que exista realmente un archivo cuyo nombre coincida con el del perfil (como
sí es requisito para perfiles discretos comunes), y pueden omitirse los operandos UNIT y VOLUME.
Volveremos sobre la creación de perfiles basados en un modelo en el capítulo dónde analicemos las
opciones de la SETROPTS, ya que allí es dónde se establece que tipo de perfiles de dataset se pretende
modelizar.
TAPE indica que se va a definir un perfil discreto que protege un archivo en cartucho (debe estar la
opción TAPEDSN activa en la SETROPTS, ya que en caso contrario el comando falla). Si el nombre
del perfil contiene algún carácter genérico, el operando TAPE es ignorado.
Cuando se define un perfil discreto, el operando NOSET|SET|SETONLY establece cómo se desea
manejar el “bit indicador” del archivo:
El valor por defecto es SET, que activa el bit indicador dejando al archivo RACF-indicado.
NOSET establece que se cree un perfil discreto pero sin alterar el estado del bit indicador del archivo.
En consecuencia, si el dataset ya estaba RACF-indicado, el operando NOSET lo deja en la misma
condición (en este caso, el valor SET provocaría un error, ya que intentaría activar un bit que ya se
encontraba activado). Es importante tener en cuenta que si el archivo no estaba RACF-indicado y se
codifica NOSET, el perfil creado no lo protegerá.
SETONLY es una opción que se aplica al caso de archivos en cartucho e indica que no se va a crear un
perfil discreto de dataset sino simplemente una entrada en la TVTOC (Tape Volume table of Contents).
En la presente guía no trataremos en detalle la protección de archivos en cartuchos.
Para cualquiera de las opciones -SET, NOSET y SETONLY-, si se especificó GENERIC, o bien el
nombre-del-perfil contiene caracteres genéricos, el operando de seteo es ignorado.
El operando FROM especifica el nombre de un perfil, discreto o genérico, en el cual se va a basar
RACF para la creación del nuevo perfil. Este operando prevalece sobre la eventual modelización de
perfiles que pueda existir para el usuario o grupo dado por el HLQ. Todas las características del perfil
especificado en el operando FROM son replicadas en el nuevo (OWNER, UACC, WARNING,
AUDITING, NOTIFY, DATA, Listas de acceso, etc.), excepto que se codifique explícitamente un valor
distinto para alguno de estos operandos en el comando ADDSD. Puede existir una mínima diferencia en
la lista de acceso del nuevo perfil con respecto al tomado como modelo, en los casos siguientes:
- Si se crea un “perfil de dataset de grupo”, y quien lo hace tiene el atributo GRPACC y está
conectado a él, entonces el grupo se agrega a la lista de acceso con autoridad UPDATE,
independientemente de que figure o no en la lista de acceso del perfil modelo.
- Si la opción ADDCREATOR está activa en la SETROPTS, el usuario que crea el nuevo perfil se
agrega a la lista de acceso con autoridad ALTER, independientemente de que figure o no en la
lista de acceso del perfil modelo.
FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM
(DATASET o cualquier clase definida en la CDT son admisibles). El valor por defecto es DATASET.
RACF ignora el operando FCLASS si no se codificó FROM.
FGENERIC indica a RACF que el perfil especificado en el operando FROM es genérico, aún cuando no
contenga caracteres genéricos. RACF ignora el operando FGENERIC si no se codificó FROM.
Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME debe indicar
el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que

45
corresponde, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se
especificó el operando FROM, o se codificó con un perfil genérico, o con un perfil de una clase que no
sea DATASET, el operando FVOLUME es ignorado.
Los operandos UNIT y VOLUME son requeridos únicamente en el caso de perfiles discretos que
correspondan a archivos no-vsam y no catalogados. En tal caso, UNIT debe indicar el tipo de
dispositivo dónde reside el archivo mientras que VOLUME especifica el volumen. Si el perfil es
genérico, o se especificó el operando MODEL, UNIT y VOLUME son ignorados.
El operando WARNING establece que el perfil se define en modo warning. Esto significa que, si un
usuario requiere acceso a un recurso protegido por el perfil, y RACF determina que no está autorizado,
en lugar de denegar el acceso lo autoriza pero envía un mensaje a la terminal del usuario (y graba uno
similar en el SYSLOG) indicando que el acceso no correspondía pero fue otorgado por estar el perfil
protector en modo warning. En ciertas ocasiones, cuando aún no se logró determinar exactamente que
usuarios deben acceder a los archivos protegidos por un perfil, puede resultar útil definirlo en modo
warning, de modo a no provocar una interrupción en alguna tarea crítica. Sin embargo, debe tenerse
presente que aquellos recursos protegidos por un perfil en modo warning se encuentran accesibles por
cualquier usuario con el máximo nivel de autoridad, o sea que se encuentran básicamente desprotegidos.
Por lo tanto, debe usarse esta facilidad con sumo cuidado, y normalmente por un período muy corto de
tiempo.Si se omite el operando WARNING, el perfil queda definido como NOWARNING, que
llamamos modo fail. Este debe ser el modo en que se encuentren usualmente todos los perfiles de la
base.
NOTIFY especifica un usuario que será notificado cada vez que el perfil sea usado para denegar un
acceso. Hacemos notar que si el perfil es utilizado para rechazar la creación o eliminación de un
archivo, no se envía notificación alguna. Si el usuario especificado en el operando NOTIFY se
encuentra con una sesión activa de TSO, recibirá las notificaciones en tiempo real. En caso contrario las
recibirá en el momento de su próximo logon (no se pierden). Si la cantidad de notificaciones esperadas
es elevada, el usuario debe loguearse frecuentemente a TSO de modo de liberar el espacio que ocupan
sus mensajes pendientes en el archivo SYS1.BRODCAST. De todos modos, no es conveniente tener en
forma permanente un usuario en el campo NOTIFY de un perfil, si se supone que el mismo denegará
gran cantidad de accesos. NOTIFY no admite más de un usuario, ni un grupo de RACF. Si se lo
codifica sin especificar usuario, queda como usuario a ser notificado quien ejecutó el comando
ADDSD. Si se lo omite, ningún usuario será notificado, que es lo más habitual.
El operando AUDIT indica a qué nivel se pretende auditar el uso de este perfil. La información se graba
en registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes, a saber: “tipo de acceso” y “nivel de
acceso”:
Los posibles tipos de acceso son los siguientes:
o NONE indica que ningún intento de acceso será grabado.
o SUCCESS indica que se grabarán accesos exitosos.
o FAILURES indica que se grabarán intentos de acceso fallidos.
o ALL indica que se grabará todo intento de acceso, sea fallido o exitoso.
Los posibles niveles de acceso son los siguientes:
o READ
o UPDATE
o CONTROL
o ALTER
En el operando AUDIT se pueden especificar uno (o más) tipos de acceso acompañados del nivel de
acceso deseado (obviamente NONE no requiere un nivel de acceso asociado). EXECUTE no es un nivel
factible de ser auditado.

46
FAILURES(READ) es el valor por defecto, y provoca que se registre todo intento de acceso denegado
por el perfil (intentos de acceso fallidos superiores a READ también son registrados). Debe tenerse
cuidado en no especificar un nivel de auditoría que genere un volumen grande e inútil de información.
Por ejemplo, SUCCESS(READ), en el caso de un perfil que proteja recursos muy utilizados, generaría
una enorme cantidad de registros tipo 80 de SMF que probablemente no sean necesarios en absoluto.
Más adelante veremos cómo interactúa el nivel de auditoría del perfil con los seteos globales de
auditoría que se establecen en la SETROPTS.
Ejemplos
1) AD ‘conta.balance.a2010’ DATA(‘balance del 2010’) OWNER(conta) UACC(none) -
AUDIT(SUCCESS(update) FAILURES(read))
Define un perfil discreto de dataset para el archivo de nombre CONTA.BALANCE.A2010. Tal
dataset debe estar catalogado, pues en caso contrario el comando fallaría ya que no se especificó
UNIT ni VOLSER. Se decidió auditar todo acceso fallido más los accesos exitosos de nivel
UPDATE (o superior).
2) AD ‘conta.pagos.a2010’ GENERIC DATA(‘pagos del 2010’) UACC(none) -
OWNER(jef254) NOTIFY(jef254)
Define un perfil “genérico completo” para el archivo de nombre CONTA.PAGOS.A2010, ya
que se codificó el operando GENERIC. A diferencia del caso anterior, tal archivo ni siquiera
tiene necesidad de existir en el momento de la creación del perfil. Se decidió establecer como
owner y usuario a ser notificado a JEF254.
3) AD ‘prod.public.**’ DATA(‘archivos de uso publico’) UACC(read)

Define un perfil genérico, dado que el nombre contiene el carácter genérico **.
4) AD ‘conta.provee.a200%.**’ FROM(‘conta.pagos.a2010’) FGENERIC -

DATA(‘pagos a proveedores’)
Define un perfil genérico, basado en el modelo dado por el perfil genérico completo
CONTA.PAGOS.A2010. Como se especificó DATA, este valor prevalece por sobre la
Installation Data que tiene el perfil modelo.
Autoridad requerida para definir perfiles de dataset

Para definir un “perfil de dataset de usuario”, quien ejecuta el comando debe cumplir con alguno de los
siguientes requisitos:
Su identificador de usuario debe coincidir con el HLQ del perfil que pretende definir.
Tener el atributo SPECIAL a nivel de un grupo que tenga al usuario dado por el HLQ del perfil
dentro de su campo de acción.
Para definir un “perfil de dataset de grupo”, el usuario que ejecuta el comando debe cumplir con alguno
de los siguientes requisitos:
Estar conectado al grupo dado por el HLQ con nivel de autoridad CREATE o superior.
Tener el atributo SPECIAL a nivel de un grupo que tenga al grupo dado por el HLQ del perfil
Tener el atributo OPERATIONS a nivel de sistema y no estar conectado al grupo dado por el
HLQ.
Tener el atributo OPERATIONS a nivel de un grupo que tenga dentro de su campo de acción al
grupo dado por el HLQ, y no estar conectado a ese grupo.

47
Para poder usar el operando FROM, que permite crear un nuevo perfil de dataset basándose en uno ya
existente, RACF exige además que el usuario que ejecuta el comando satisfaga alguno de los siguientes
requisitos:
Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil tomado como modelo dentro
de su campo de acción.
Ser el owner del perfil tomado como modelo.
Tener un identificador de usuario que coincida con el HLQ del perfil tomado como modelo.
Si el perfil modelo es discreto, tener autoridad ALTER sobre el perfil.
4.8 - Modificación de un perfil de dataset

Sintaxis:
ALTDSD|ALD ‘nombre-del-perfil’ [DATA(‘installation-data’)|NODATA]
[OWNER(usuario/grupo)] [UACC(nivel)] [GENERIC]
[UNIT(unidad)] [VOLUME(volumen)] [WARNING|NOWARNING]
[NOTIFY(usuario)|NONOTIFY] [AUDIT(tipo-de-acceso(nivel-de-acceso)…)]
Como sucede con todos los comandos de modificación de perfiles, solo es necesario codificar los
operandos que se desee modificar. Los no especificados mantienen sus valores previos (no se aplican
valores por defecto).
No es posible modificar un perfil discreto para convertirlo en “genérico completo”, o viceversa. Si se
pretende realizar esto, debe deletearse el perfil y definirlo nuevamente de la manera deseada.
El operando GENERIC indica simplemente que debe considerarse al perfil como genérico, aún cuando
no contenga tales caracteres en su nombre.
Autoridad requerida
Para modificar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes
requisitos:
Tener el atributo SPECIAL a nivel de un grupo que tenga al perfil dentro de su campo de acción.
Ser el owner del perfil.
Su identificador de usuario debe coincidir con el HLQ del perfil.
Si el perfil es discreto, tener autoridad ALTER sobre el perfil.
4.9 - Eliminación de un perfil de dataset

Sintaxis:
DELDSD|DD ‘nombre-del-perfil’ [GENERIC|NOSET|SET] [VOLUME(volumen)]
La eliminación de un perfil de dataset nunca borra ningún archivo. Fuera de la base de RACF, lo único
que este comando puede eventualmente modificar es el “bit indicador” de protección de un dataset (que,
recordemos, no forma parte del archivo).
GENERIC indica que debe considerarse al perfil como genérico, aún cuando no contenga caracteres
comodín en su nombre.
NOSET se aplica exclusivamente para perfiles discretos. Indica que no se modifique el estado del “bit
indicador” del archivo. Salvo situaciones particulares que así lo justifiquen, debe evitarse el uso de esta
opción, pues no es conveniente dejar marcados como protegidos discretamente archivos que ya no lo
están, pues es fuente de confusión e inconvenientes. El archivo, en este caso, quedaría protegido

48
genéricamente, en caso de que existiera alguno perfil genérico apropiado, o simplemente desprotegido
en caso contrario.
SET es el valor por defecto, y también se aplica exclusivamente a perfiles discretos. Este operando
desactiva el bit de protección del archivo, y requiere que el volumen donde reside esté en línea. Si el
archivo tuviera su bit de protección desactivado, y se especifica SET, el comando falla. En tal caso,
debería codificarse NOSET para poder borrar el perfil.
VOLUME solo es necesario para perfiles discretos, siempre y cuando existan en la base de RACF más
de un perfil discreto con el nombre en cuestión pero con distintos volúmenes asociados. En efecto, en
tal caso, VOLUME es requerido por RACF para saber cuál es exactamente el perfil discreto que debe
borrar de la base.
Autoridad requerida
Para eliminar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes
requisitos:
4.10 - Listado de un perfil de dataset

Sintaxis:
LISTDSD|LD [{DATASET(‘nombre’)|ID(usuario/grupo)|PREFIX(cadena-de-caracteres)}]
[GENERIC|NOGENERIC] [AUTHUSER] [ALL] [DSNS] [VOLUME(volumen)...]
Este comando no efectúa ninguna modificación sobre la base de RACF. Unicamente lista (en la pantalla
de la terminal, si se ejecuta en foreground, o con salida a un dataset o al spool, si se ejecuta en
batchground) información relativa a perfiles de dataset.
DATASET|ID|PREFIX
El operando DATASET especifica el nombre del perfil a listar.
o Si el nombre no presenta caracteres comodín y no se especifica ni GENERIC ni NOGENERIC,
RACF lista la información del perfil discreto y del “genérico completo”. Si ninguno existiese, lo
informa.
o Si el nombre no presenta caracteres comodín y se especifica NOGENERIC, RACF lista la
información del perfil discreto correspondiente. Si no existiese, lo informa.
o Si el nombre no tiene caracteres comodín y se especifica GENERIC, RACF lista la información
del perfil genérico que más se ajusta al nombre del archivo (o sea, de su perfil protector, siempre
y cuando no esté protegido de manera discreta).
o Si el nombre tiene algún carácter comodín, RACF ignora el operando
[GENERIC|NOGENERIC] y lista el perfil genérico que coincide exactamente con el nombre
especificado. Si no existiese, lo informa.
ID debe especificar un usuario o grupo. En tal caso, el comando lista los perfiles cuyo HLQ coincide
con este valor. Se listarán solo discretos, solo genéricos, o todos, según se especifique NOGENERIC,
GENERIC, o se omita este operando.
Si se especifica PREFIX, el comando lista los perfiles cuyos primeros caracteres coincidan exactamente
con el valor especificado. Se listarán solo discretos, solo genéricos, o todos, según como se codifique el

49
operando correspondiente. La cadena de caracteres especificada puede extenderse a más de un

calificador.
En caso de no especificar ni DATASET, ni ID ni PREFIX, el valor que asume por defecto es ID con el
valor del identificador del usuario que ejecuta el comando.
GENERIC indica que deben listarse únicamente perfiles genéricos, mientras que NOGENERIC indica
que solo deben listarse los discretos. Si se omite este operando, y se codificó DATASET, ya se señaló
qué perfiles son listados. En cambio, si se especificó ID o PREFIX, se listan todos los perfiles (discretos
y genéricos) que cumplan con el criterio de selección correspondiente.
AUTHUSER especifica que se debe incluir en la salida del comando la siguiente información:
o Security level, categories y security label
o Lista de acceso estándar
o Lista de acceso condicional
ALL indica que se liste toda la información del perfil. Si no se especifica, el listado no muestra ni las
estadísticas ni las listas de acceso.
El operando DSNS indica que se listen todos los archivos catalogados protegidos por el perfil. Si la
cantidad es muy grande, esta búsqueda cruzada es costosa y puede demorar considerablemente la
ejecución del comando.
El operando VOLUME limita la información listada a los perfiles discretos asociados con estos
volúmenes (se pueden especificar varios). Excepto que se haya codificado NOGENERIC, también se
listan los perfiles genéricos que correspondan.
Observación importante:
Los perfiles genéricos, al ser listados (ya sea con el comando LISTDSD o SEARCH), siempre tienen a
continuación de su nombre el símbolo (G). Por lo tanto, la ausencia de la (G) indica sin lugar a dudas
que se trata de un perfil discreto.
Ejemplo:
LD DA(‘conta.pagos.**’) ALL DSNS
Este comando lista toda la información del perfil genérico CONTA.PAGOS.**, siempre y cuando
exista. La salida tendría el siguiente aspecto:
INFORMATION FOR DATASET CONTA.PAGOS.** (G)
LEVEL OWNER UNIVERSAL ACCESS WARNING ERASE
00 CONTA NONE NO NO
AUDITING
FAILURES(READ)
NOTIFY
CON587
YOUR ACCESS CREATION GROUP DATASET TYPE
NONE ADMIN NON-VSAM
GLOBALAUDIT
NONE
INSTALLATION DATA
AREA DE CONTABILIDAD - PAGOS
SECURITY LEVEL
NO SECURITY LEVEL
CATEGORIES
NO CATEGORIES
SECLABEL

50
NO SECLABEL
CREATION DATE LAST REFERENCE DATE LAST CHANGE DATE
(DAY) (YEAR) (DAY) (YEAR) (DAY) (YEAR)
295 10 NOT APPLICABLE FOR GENERIC PROFILE
ALTER COUNT CONTROL COUNT UPDATE COUNT READ COUNT
NOT APPLICABLE FOR GENERIC PROFILE
ID ACCESS
CONTA ALTER
FINAN READ
FIN2514 UPDATE
ID ACCESS CLASS ENTITY NAME
NO ENTRIES IN CONDITIONAL ACCESS LIST
CATALOGUED DATA SETS AFFECTED BY PROFILE CHANGE
CONTA.PAGOS.A2007
CONTA.PAGOS.A2008
CONTA.PAGOS.A2009
CONTA.PAGOS.PROVEE
CONTA.PAGOS.PROVEE.DATA (D)
CONTA.PAGOS.PROVEE.INDEX (I)
Del listado precedente, se desprende la siguiente información sobre el perfil:

Se trata efectivamente de un perfil genérico, ya que figura el símbolo (G) a continuación del
nombre.
LEVEL es un campo para uso administrativo, que puede tomar cualquier valor entre 00 y 99,
siendo 00 el valor por defecto. No tiene ninguna relevancia en el chequeo de autoridad, y cada
organización lo maneja como desea (aunque es realmente poco utilizado). Un posible uso
consiste en asignarle a todos los perfiles con un cierto grado de sensibilidad un mismo LEVEL,
de modo de disponer de un criterio de selección para la elaboración de informes de auditoría. No
debe confundirse LEVEL con “SECURITY LEVEL”.
El OWNER es CONTA.
Suponemos que es un grupo, aunque en general no es posible determinar con solo mirar un
identificador si se trata de un usuario o de un grupo. De todos modos, cada organización tiene
usualmente una nomenclatura bastante diferente para ambos, con lo cual suele ser mas o menos
evidente para los administradores cuando se trata de un usuario y cuando de un grupo.
El UACC del perfil es NONE.
WARNING en NO indica que el perfil está en modo fail. Esto significa que se denegará todo
acceso no autorizado. Salvo casos excepcionales, todos los perfiles deben estar en modo fail.
El valor YES en campo ERASE a nivel del perfil, combinado con una configuración apropiada
del ERASE a nivel de la SETROPTS, especifica que cuando se deletea un archivo protegido por
este perfil, los datos deben ser físicamente borrados en el disco dónde reside (sobrescribiendo
todos los extents con ceros binarios). Este requerimiento extra de seguridad, que impide
cualquier intento de recuperación de los datos, no suele ser necesario.El valor por defecto es
NO.
FAILURES(READ) en el campo AUDITING indica que se pretende loggear en el SMF
únicamente los intentos de acceso denegados por el perfil. Los accesos exitosos no serán
grabados, cualquiera sea el nivel (excepto que exista algún otro seteo de auditoría que indique lo
contrario, a nivel de la SETROPTS o del GLOBALAUDIT del perfil).
El usuario CON587 recibirá una notificación cada vez que el perfil CONTA.PAGOS.** sea
utilizado para denegar una solicitud de acceso. En este caso, podemos estar seguros que
CON587 es un usuario, ya que el campo NOTIFY no admite grupos.

51
El campo YOUR ACCESS muestra el nivel de autoridad que tiene sobre el perfil el usuario que
ejecuta el comando LISTDSD.
CREATION GROUP indica el “grupo de conexión” que tenía el usuario que definió el perfil en
el momento de la creación.
DATASET TYPE puede tomar los valores NON-VSAM, VSAM, MODEL o TAPE.
GLOBALAUDIT funciona de manera similar al campo AUDIT, pero es únicamente visible y
modificable por usuarios con el atributo AUDITOR a nivel de sistema, o a nivel de un grupo que
tenga al perfil dentro de su campo de acción.
La INSTALLATION DATA es opcional, pero es una buena costumbre usar este campo para
describir brevemente el perfil.
SECURITY-LEVEL, CATEGORIES y SECLABEL son campos relacionados con un nivel extra
de seguridad que brinda RACF y es realmente muy poco utilizado. Si la organización no usa esta
seguridad adicional, los 3 campos deben indicar que no tienen información.
CREATION DATE indica el día y el año en que se definió el perfil. En este caso, el perfil se
creó el día 295 del año 2010.
LAST REFERENCE DATE y LAST CHANGE DATE no se aplican a perfiles genéricos.
Solamente se mantienen estos campos para perfiles discretos.
ALTER COUNT, CONTROL COUNT, UPDATE COUNT y READ COUNT no se aplican a
perfiles genéricos. En el caso de perfiles discretos, solo se mantienen actualizados si está
especificado en la SETROPTS que se mantengan estadísticas para la clase DATASET.
La lista de acceso estándar del perfil tiene entradas constituidas por usuarios o grupos, con su
nivel de acceso correspondiente. En el ejemplo, existen 3 entradas en la lista de acceso estándar
(vale la misma aclaración que se hizo previamente, en el sentido en que no se puede distinguir a
priori si se trata de usuarios o grupos). Eventualmente, también puede figurar en la lista de
acceso una entrada *, que tiene un significado similar -pero no idéntico- al del UACC.
La lista de acceso condicional se encuentra vacía (no contiene ninguna entrada). No nos
ocuparemos en la presente guía de analizar la lista de acceso condicional de un perfil (no es muy
frecuente su uso, por otro lado).
Al haber especificado el operando DSNS en el comando LISTDSD, la salida incluye una lista de
los archivos catalogados que se encuentran protegidos por el perfil. En nuestro caso, existen
4datasets, uno de los cuáles es VSAM (y por eso genera 3 entradas en el listado,
correspondientes a sus distintos componentes).
Es posible que un usuario pueda ejecutar el comando del ejemplo pero que algunos campos no le sean
mostrados por carecer de la autoridad suficiente (por ejemplo, GLOBALAUDIT o listas de acceso).
Autoridad requerida
Para listar un perfil de dataset, quien ejecuta el comando debe cumplir con alguno de los siguientes
requisitos:
Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de sistema.
Tener el atributo SPECIAL, AUDITOR u OPERATIONS a nivel de un grupo que tenga al perfil
Tener autoridad READ o superior sobre el perfil.

52
Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad READ o
superior.
Para que se liste el campo GLOBALAUDIT se debe tener el atributo AUDITOR (ya sea a nivel de
sistema, o a nivel de grupo para un grupo que tenga al perfil dentro de su campo de acción).
Para ver las listas de acceso del perfil, quien ejecuta el comando debe satisfacer alguna de las siguientes
condiciones:
Existir una regla en la GLOBAL que coincida con el perfil y otorgue autoridad ALTER.
Si el perfil es discreto, tener autoridad ALTER.
4.11 - Permisos sobre perfiles de dataset

Las listas de acceso de un perfil de dataset, tanto la estándar como la condicional, se modifican a través
del comando PERMIT. Más aún, con este mismo comando se manejan también las listas de acceso de
cualquier perfil de recursos generales.
Sintaxis:
PERMIT|PE ‘nombre-del-perfil’ [CLASS(clase)] [GENERIC] [ID({usuario/grupo...|*})]
[ACCESS(nivel)|DELETE] [VOLUME(volumen)]
[FROM(‘perfil2’)] [FCLASS] [FGENERIC] [FVOLUME(volumen)]
[RESET(ALL|STANDARD|WHEN)]
[WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})]
[JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})]
[TERMINAL({terminal|*})])]
El nombre-del-perfil es requerido y debe estar inmediatamente a continuación del comando PERMIT.
CLASS indica la clase a la que pertenece el perfil. El valor por defecto es DATASET, por lo cual, en el
caso particular que nos ocupa, puede omitirse.
GENERIC especifica que el perfil es genérico. Debe necesariamente codificarse si se trata de un
“genérico completo”, pues de lo contrario RACF supondrá que el perfil es discreto. Si el nombre
contiene caracteres comodín, GENERIC puede omitirse.
ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar.
Separados por espacios pueden ingresarse más de un usuario/grupo. También se acepta el valor *, que
representa un usuario cualquiera existente en la base de RACF.
ACCESS especifica el nivel de autoridad a otorgarle al usuario/grupo especificado en el operando ID.
Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER. Si se codifica
ACCESS sin poner ningún valor, se asume READ.
DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo
codificado en el operando ID.
Si se especificó ID pero se omitió tanto ACCESS como DELETE, se asume por defecto
ACCESS(READ). En ambos casos, ya sea con ACCESS o DELETE, RACF actúa sobre la lista de
acceso estándar, excepto que se codifique explícitamente el operando WHEN, en cuyo caso se modifica
la lista de acceso condicional.

53
VOLUME es necesario únicamente si se trata de un perfil discreto que corresponde a un archivo no

catalogado.
FROM especifica el nombre de otro perfil, genérico o discreto, del cual se quieren copiar las listas de
acceso (estándar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas
de acceso correspondiente. Por lo tanto, el operando FROM no convierte en idénticas las listas de
acceso de ambos perfiles. Más aún, si una entrada que figura en la lista de acceso del perfil2 ya se
encuentra en la del perfil en cuestión, entonces la misma no se modifica.
FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite
FCLASS y se codificó FROM, se asume por defecto que perfil2 pertenece a la misma que clase que el
perfil en cuestión (DATASET, en nuestro caso).
contenga caracteres genéricos. RACF ignora el operando FGENERIC si no se codificó FROM.
Si el operando FROM especifica un perfil discreto de DATASET, el operando FVOLUME indica el
volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al
perfil2, o si se omite y existe más de un perfil discreto con ése nombre, el comando falla. Si no se
El operando RESET indica que se quiere vaciar una o ambas listas de acceso, es decir eliminar todas las
entradas. RESET(STANDARD) vacía únicamente la lista de acceso estándar, en tanto que
RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vacía ambas listas de acceso. Si se
codifica RESET sin ningún valor, se asume por defecto ALL.
El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los
distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectúan sobre la lista de
acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de
acceso condicional).
Ejemplos:
1) PE ‘conta.balance.a2010’ ID(conta) ACCESS(update)
Otorga UPDATE en la lista de acceso estándar del perfil discreto CONTA.BALANCE.A2002 al
grupo CONTA. Si el grupo ya figuraba, modifica su nivel a UPDATE, mientras que si no estaba,
lo incorpora con este nivel de acceso.
2) PE ‘conta.pagos.a2010.**’ FROM(‘conta.provee.a2010’) FGENERIC -
ID(jef234 jef587) ACCESS(ALTER)
Copia al perfil genérico CONTA.PAGOS.A2010.** las entradas de las listas de acceso del perfil
“genérico completo” de nombre CONTA.PROVEE.A2010. Independientemente de las entradas
que se copien, la presencia de ID y ACCESS indica que los usuario JEF234 y JEF587 serán
incorporados a la lista de acceso estándar del perfil CONTA.PAGOS.A2010.** con nivel de
autoridad ALTER.
3) PE ‘conta.a2010.**’ RESET ID(*) ACCESS(READ)
Vacía las listas de acceso (estándar y condicional) del perfil genérico CONTA.A2010.** e
incorpora en la lista estándar la entrada * con nivel de acceso READ. El orden de los operandos
no tiene importancia en este caso, pudiendo haberse especificado RESET al final (si se codifican
ambos operandos -RESET y ID-, primero se vacía la lista de acceso y luego se procesa el ID).
Autoridad requerida
Para ejecutar exitosamente el comando PERMIT sobre un perfil de dataset, el usuario debe satisfacer
alguna de las siguientes condiciones:

54

Para poder especificar el operando FROM, quien ejecuta el comando necesita adicionalmente autoridad
sobre el perfil del cual se pretende copiar las listas de acceso.
4.12 - Perfiles de dataset: discretos versus genéricos

Como ya se ha señalado, originalmente los únicos perfiles de dataset que admitía RACF eran los que
hoy se conocen como discretos. Posteriormente, con la aparición de la posibilidad de definir perfiles de
dataset genéricos, la mayoría de las organizaciones fueron abandonando paulatinamente la utilización
de los perfiles discretos, llegando en muchos casos a su eliminación total. Esto es entendible, y hasta
aconsejable, teniendo en cuenta que los perfiles genéricos son más sencillos de administrar, y es
necesaria una menor cantidad de los mismos para proteger la totalidad de los archivos.
Sin embargo, debe tenerse cuidado de no abusar en este sentido, ya que la existencia de una gran
cantidad de perfiles genéricos con idéntico HLQ puede traer aparejado importantes problemas de
performance. En efecto, dado un archivo, la localización de su perfil protector es más rápida en el caso
de estar protegido discretamente que en el caso de estarlo genéricamente, ya que en este último caso
RACF debe realizar una búsqueda de tipo secuencial hasta dar con el perfil más ajustado. Por lo tanto,
si bien es muy aconsejable el uso de perfiles de dataset genéricos, no debe caerse en el extremo de
definir una cantidad tal que impacte negativamente en la performance (por ejemplo, 500 perfiles
genéricos con igual HLQ no parece apropiado).
Los perfiles discretos tienen pues aún su lugar, y en algunos casos particulares continúan siendo una
mejor opción. Por otro lado, IBM no tiene previsto discontinuarlos en un futuro cercano, de modo que
no hay ninguna razón para no utilizarlos si resultan mas apropiados para resolver una determinada
situación. Por ejemplo, si existieran 2 datasets de idéntico nombre (uno de ellos necesariamente
descatalogado) que requirieran distinta protección, solo sería posible lograrlo mediante el uso de
perfiles discretos.
4.13 - Creación de nuevos datasets

Ya hemos visto, al analizar el comando ADDSD, la autoridad que se requiere para definir un nuevo
perfil de dataset. Veremos ahora que autoridad exige RACF para definir un nuevo archivo.
Supondremos, para simplificar, que la opción PROTECTALL de la SETROPTS está activa en modo
FAIL. Básicamente, esto significa que los archivos no protegidos por un perfil en la clase DATASET
resultan inaccesibles. Volveremos sobre este punto en el capítulo dónde estudiemos en detalle las
opciones de la SETROPTS. Recordemos que un archivo, para poder estar efectivamente protegido por
RACF, debe tener como HLQ un usuario o grupo (pues esto es requisito insalvable para perfiles). Por lo
tanto, los datasets se dividen en “datasets de usuario” y “datasets de grupo”.
Para crear un “dataset de usuario”, quien lo hace debe satisfacer alguna de las condiciones que se
enumeran a continuación:
El dataset quedará protegido por un perfil genérico y, se cumple alguno de los requisitos
siguientes:
- Tiene autoridad ALTER sobre tal perfil.
- Tiene autoridad ALTER a través de una regla en la GLOBAL.
- El HLQ del archivo coincide con su identificador de usuario.

55
Tener el atributo ADSP y el HLQ del dataset coincidir con su identificador de usuario. En este
caso, se le creará automáticamente un perfil discreto.
Para crear un “dataset de grupo”, quien lo hace debe satisfacer alguna de las condiciones que se
enumeran a continuación:
El dataset quedará protegido por un perfil genérico y, se cumple alguno de los requisitos
siguientes:
- Tiene autoridad ALTER sobre tal perfil.
- Tiene autoridad ALTER a través de una regla en la GLOBAL.
- Está conectado al grupo dado por el HLQ con autoridad CREATE o superior.
Tener el atributo ADSP y el HLQ ser un grupo al cual esté conectado con autoridad CREATE o
superior. En este caso, se le creará automáticamente un perfil discreto.
Tener el atributo OPERATIONS a nivel de sistema y no cumplir simultáneamente:
- Estar conectado al grupo dado por el HLQ con nivel USE
- Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá.
Tener el atributo OPERATIONS a nivel de grupo, el HLQ del archivo ser un grupo dentro del
campo de acción y no cumplir simultáneamente:
- Estar conectado al grupo dado por el HLQ con nivel USE
- Tener autoridad menor que ALTER sobre el perfil genérico que lo protegerá.
Es importante recalcar que si se pretende que el dataset se catalogue, el usuario que lo define debe
asimismo tener autoridad UPDATE sobre el catálogo correspondiente (USERCAT o MASTERCAT,
dependiendo de la existencia o no del ALIAS apropiado).

56
5 - OPCIONES GLOBALES DE RACF

Resultan de vital importancia para el funcionamiento de RACF ciertas opciones globales de
configuración que se establecen y modifican a través del comando SETROPTS. Esta configuración se
encuentra almacenada dentro de la base de RACF (en el primer bloque, llamado ICB –Inventory
Control Block-), y puede ser modificada dinámicamente. Con excepción de las opciones globales
relativas a auditoría, que requieren el atributo AUDITOR a nivel de sistema, el resto de los parámetros
exige el atributo SPECIAL a nivel de sistema para ser modificados.
Una adecuada configuración de la SETROPTS es fundamental para dotar a la organización de un
adecuado nivel de seguridad. A lo largo del presente capítulo vamos a examinar en detalle las opciones
de la SETROPTS, indicando en muchos casos la configuración que consideramos más conveniente,
tanto desde el punto de vista administrativo como desde el de la seguridad del sistema.
Cuando RACF se instala por primera vez, la SETROPTS provista por IBM es a todas luces insuficiente
para brindar una seguridad razonable a un entorno productivo. La configuración global por defecto es
totalmente abierta y permisiva, lo cual es entendible para cuando se afrontan las primeras etapas de la
construcción de un sistema. Sin embargo, antes de empezar a utilizarlo productivamente, el
administrador de RACF debe configurar adecuadamente la SETROPTS, para lo cual debe tener bien en
claro el significado e impacto de cada una de sus opciones.
5.2 - Posit Value de una clase

Toda clase de RACF, ya sea provista por IBM o definida por la organización, tiene asociado un número
comprendido entre 0 y 1023, denominado posit value. Varias clases pueden compartir el mismo
número. En efecto, IBM otorga igual posit value a clases que están íntimamente relacionadas, como ser
todas aquellas vinculadas con un mismo producto. Los rangos 0-18, 57-127 y 528-1023 están
reservados para uso exclusivo de IBM, por lo cual no debe utilizarse ningún número en alguno de estos
rangos para una clase definida por la organización.
La importancia del posit value radica en el hecho de que todos los operandos del comando SETROPTS
que se aplican a una clase resultan automáticamente aplicados a todas aquellas otras que comparten el
mismo posit value.
Por ejemplo, todas las siguientes clases, relacionadas con CICS, comparten el posit value 5:
TCICSTRN, GCICSTRN, PCICSPSB, QCICSPSB, FCICSFCT, HCICSFCT, JCICSJCT, KCICSJCT,
DCICSDCT, ECICSDCT, SCICSTST, UCICSTST, MCICSPPT, NCICSPPT, ACICSPCT,
BCICSPCT.
En consecuencia, el comando “SETROPTS AUDIT(TCICSTRN)” no solo auditará la clase TCICSTRN
sino que automáticamente hará lo propio con el resto de las clases mencionadas.
5.3 - Listado de la SETROPTS

Para listar el contenido de la SETROPTS se requiere tener el atributo SPECIAL o AUDITOR, ya sea a
nivel de sistema o a nivel de grupo. Como ya indicáramos, los usuarios con atributo SPECIAL no
pueden visualizar las opciones relativas a auditoría.
Sintaxis:
SETROPTS|SETR LIST
No existe la posibilidad de listar parcialmente información de la SETROPTS. Para ver la configuración
de un determinado parámetro, no queda mas remedio que buscarlo dentro del listado completo que
brinda el comando “SETR LIST”. Mostramos a continuación, a modo de ejemplo, el listado de la
SETROPTS que podría tener una organización típica.

57
ATTRIBUTES = INITSTATS WHEN(PROGRAM -- BASIC) TERMINAL(READ) SAUDIT CMDVIOL OPERAUDIT

STATISTICS = NONE
AUDIT CLASSES = DATASET USER GROUP ACCTNUM ACICSPCT AIMS ALCSAUTH APPCLU
APPCPORT APPCSERV APPCSI APPCTP APPL BCICSPCT CACHECLS
CBIND CCICSCMD CDT CFIELD CIMS CONSOLE CPSMOBJ CPSMXMP
CRYPTOZ CSFKEYS CSFSERV DASDVOL DBNFORM DCEUUIDS DCICSDCT
DEVICES DIGTCERT DIGTCRIT DIGTNMAP DIGTRING DIMS DIRAUTH
DIRECTRY DLFCLASS DSNADM DSNR ECICSDCT EJBROLE FACILITY
FCICSFCT FIELD FILE FIMS FSOBJ GCICSTRN GCPSMOBJ GCSFKEYS
GDASDVOL GDSNBP GDSNCL GDSNDB GDSNJR GDSNPK GDSNPN GDSNSC
GDSNSG GDSNSM GDSNSP GDSNSQ GDSNTB GDSNTS GDSNUF GDSNUT
GEJBROLE GIMS GINFOMAN GLOBAL GMBR GMQADMIN GMQCHAN GMQNLIST
GMQPROC GMQQUEUE GMXADMIN GMXNLIST GMXPROC GMXQUEUE GMXTOPIC
GSDSF GSOMDOBJ GTERMINL GXCSFKEY GXFACILI HCICSFCT HIMS
IBMOPC IDIDMAP IIMS ILMADMIN INFOMAN IPCOBJ JAVA JCICSJCT
JESINPUT JESJOBS JESSPOOL JIMS KCICSJCT KERBLINK KEYSMSTR
LDAPBIND LFSCLASS LIMS LOGSTRM MCICSPPT MDSNBP MDSNCL
MDSNDB MDSNJR MDSNPK MDSNPN MDSNSC MDSNSG MDSNSM MDSNSP
MDSNSQ MDSNTB MDSNTS MDSNUF MDSNUT MGMTCLAS MIMS MQADMIN
MQCHAN MQCMDS MQCONN MQNLIST MQPROC MQQUEUE MXADMIN MXNLIST
MXPROC MXQUEUE MXTOPIC NCICSPPT NDSLINK NETCMDS NETSPAN
NODES NODMBR NOTELINK NVASAPDT OIMS OPERCMDS PCICSPSB
PERFGRP PIMS PMBR PRINTSRV PROCESS PROGRAM PROPCNTL PSFMPL
PTKTDATA PTKTVAL QCICSPSB QIMS RACFEVNT RACFHC RACFVARS
RACGLIST RACHCMBR RAUDITX RCICSRES RDATALIB REALM RIMS
RMTOPS RODMMGR ROLE RRSFDATA RVARSMBR SCDMBR SCICSTST
SDSF SECDATA SECLABEL SECLMBR SERVAUTH SERVER SFSCMD SIMS
SMESSAGE SOMDOBJS STARTED STORCLAS SUBSYSNM SURROGAT SYSMVIEW
TAPEVOL TCICSTRN TEMPDSN TERMINAL TIMS TMEADMIN TSOAUTH
TSOPROC UCICSTST UIMS UNIXMAP UNIXPRIV VCICSCMD VMBATCH
VMBR VMCMD VMEVENT VMLAN VMMAC VMMDISK VMNODE VMPOSIX
VMRDR VMSEGMT VMXEVENT VTAMAPPL VXMBR WBEM WCICSRES WIMS
WRITER XCSFKEY XFACILIT
ACTIVE CLASSES = DATASET USER GROUP RVARSMBR RACFVARS DASDVOL GDASDVOL
TERMINAL GTERMINL TCICSTRN GCICSTRN PCICSPSB
QCICSPSB GLOBAL GMBR DSNR FACILITY FCICSFCT HCICSFCT
JCICSJCT KCICSJCT DCICSDCT ECICSDCT SCICSTST UCICSTST
MCICSPPT NCICSPPT ACICSPCT BCICSPCT PMBR PROGRAM TSOPROC
ACCTNUM TSOAUTH FIELD CCICSCMD VCICSCMD OPERCMDS CONSOLE
SURROGAT SDSF GSDSF STARTED
GENERIC PROFILE CLASSES = DATASET DASDVOL TERMINAL TCICSTRN PCICSPSB
FACILITY FCICSFCT JCICSJCT DCICSDCT SCICSTST
MCICSPPT ACICSPCT FIELD CCICSCMD OPERCMDS CONSOLE
SDSF STARTED
GENERIC COMMAND CLASSES = DATASET DASDVOL TERMINAL TCICSTRN PCICSPSB
FACILITY FCICSFCT JCICSJCT DCICSDCT SCICSTST
MCICSPPT ACICSPCT FIELD CCICSCMD OPERCMDS CONSOLE
SDSF STARTED
GENLIST CLASSES = NONE
GLOBAL CHECKING CLASSES = DATASET
SETR RACLIST CLASSES = RACFVARS TERMINAL DSNR FACILITY TSOPROC ACCTNUM
TSOAUTH FIELD OPERCMDS CONSOLE SURROGAT SDSF STARTED
GLOBAL=YES RACLIST ONLY = TCICSTRN CCICSCMD
LOGOPTIONS "ALWAYS" CLASSES = NONE
LOGOPTIONS "NEVER" CLASSES = NONE
LOGOPTIONS "SUCCESSES" CLASSES = NONE
LOGOPTIONS "FAILURES" CLASSES = NONE
LOGOPTIONS "DEFAULT" CLASSES = DATASET ACCTNUM ACICSPCT AIMS ALCSAUTH
APPCLU APPCPORT APPCSERV APPCSI APPCTP
APPL BCICSPCT CACHECLS CBIND CCICSCMD

58
CDT CFIELD CIMS CONSOLE CPSMOBJ CPSMXMP

CRYPTOZ CSFKEYS CSFSERV DASDVOL DBNFORM
DCEUUIDS DCICSDCT DEVICES DIGTCERT DIGTCRIT
DIGTNMAP DIGTRING DIMS DIRACC DIRAUTH
DIRECTRY DIRSRCH DLFCLASS DSNADM DSNR
ECICSDCT EJBROLE FACILITY FCICSFCT FIELD
FILE FIMS FSOBJ FSSEC GCICSTRN GCPSMOBJ
GCSFKEYS GDASDVOL GDSNBP GDSNCL GDSNDB
GDSNJR GDSNPK GDSNPN GDSNSC GDSNSG GDSNSM
GDSNSP GDSNSQ GDSNTB GDSNTS GDSNUF GDSNUT
GEJBROLE GIMS GINFOMAN GLOBAL GMBR GMQADMIN
GMQCHAN GMQNLIST GMQPROC GMQQUEUE GMXADMIN
GMXNLIST GMXPROC GMXQUEUE GMXTOPIC GSDSF
GSOMDOBJ GTERMINL GXCSFKEY GXFACILI HCICSFCT
HIMS IBMOPC IDIDMAP IIMS ILMADMIN INFOMAN
IPCOBJ JAVA JCICSJCT JESINPUT JESJOBS
JESSPOOL JIMS KCICSJCT KERBLINK KEYSMSTR
LDAPBIND LFSCLASS LIMS LOGSTRM MCICSPPT
MDSNBP MDSNCL MDSNDB MDSNJR MDSNPK MDSNPN
MDSNSC MDSNSG MDSNSM MDSNSP MDSNSQ MDSNTB
MDSNTS MDSNUF MDSNUT MGMTCLAS MIMS MQADMIN
MQCHAN MQCMDS MQCONN MQNLIST MQPROC MQQUEUE
MXADMIN MXNLIST MXPROC MXQUEUE MXTOPIC
NCICSPPT NDSLINK NETCMDS NETSPAN NODES
NODMBR NOTELINK NVASAPDT OIMS OPERCMDS
PCICSPSB PERFGRP PIMS PMBR PRINTSRV PROCACT
PROCESS PROGRAM PROPCNTL PSFMPL PTKTDATA
PTKTVAL QCICSPSB QIMS RACFEVNT RACFHC
RACFVARS RACGLIST RACHCMBR RAUDITX RCICSRES
RDATALIB REALM RIMS RMTOPS RODMMGR ROLE
RRSFDATA RVARSMBR SCDMBR SCICSTST SDSF
SECDATA SECLABEL SECLMBR SERVAUTH SERVER
SFSCMD SIMS SMESSAGE SOMDOBJS STARTED
STORCLAS SUBSYSNM SURROGAT SYSMVIEW TAPEVOL
TCICSTRN TEMPDSN TERMINAL TIMS TMEADMIN
TSOAUTH TSOPROC UCICSTST UIMS UNIXMAP
UNIXPRIV VCICSCMD VMBATCH VMBR VMCMD VMEVENT
VMLAN VMMAC VMMDISK VMNODE VMPOSIX VMRDR
VMSEGMT VMXEVENT VTAMAPPL VXMBR WBEM WCICSRES
WIMS WRITER XCSFKEY XFACILIT
AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT
ENHANCED GENERIC NAMING IS IN EFFECT
REAL DATA SET NAMES OPTION IS ACTIVE
JES-BATCHALLRACF OPTION IS ACTIVE
JES-XBMALLRACF OPTION IS ACTIVE
JES-EARLYVERIFY OPTION IS ACTIVE
PROTECT-ALL IS ACTIVE, CURRENT OPTIONS:
PROTECT-ALL FAIL OPTION IS IN EFFECT
TAPE DATA SET PROTECTION IS INACTIVE
SECURITY RETENTION PERIOD IN EFFECT IS 0 DAYS.
ERASE-ON-SCRATCH IS ACTIVE, CURRENT OPTIONS:
ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE
SINGLE LEVEL NAMES NOT ALLOWED
LIST OF GROUPS ACCESS CHECKING IS ACTIVE.
INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS.
DATA SET MODELLING NOT BEING DONE FOR GDGS.
USER DATA SET MODELLING IS BEING DONE.
GROUP DATA SET MODELLING NOT BEING DONE.

59
PASSWORD PROCESSING OPTIONS:

PASSWORD CHANGE INTERVAL IS 30 DAYS.
PASSWORD MINIMUM CHANGE INTERVAL IS 1 DAYS.
MIXED CASE PASSWORD SUPPORT IS IN EFFECT.
15 GENERATIONS OF PREVIOUS PASSWORDS BEING MAINTAINED.
AFTER 5 CONSECUTIVE UNSUCCESSFUL PASSWORD ATTEMPTS,
A USERID WILL BE REVOKED.
PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS.
INSTALLATION PASSWORD SYNTAX RULES:
RULE 1 LENGTH(6:8) LLLLLLLL
LEGEND:
A-ALPHA C-CONSONANT L-ALPHANUM N-NUMERIC V-VOWEL W-NOVOWEL *-ANYTHING
c-MIXED CONSONANT m-MIXED NUMERIC v-MIXED VOWEL $-NATIONAL
INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION.
INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.
SECLEVELAUDIT IS INACTIVE
SECLABEL AUDIT IS NOT IN EFFECT
SECLABEL CONTROL IS NOT IN EFFECT
GENERIC OWNER ONLY IS NOT IN EFFECT
COMPATIBILITY MODE IS NOT IN EFFECT
MULTI-LEVEL QUIET IS NOT IN EFFECT
MULTI-LEVEL STABLE IS NOT IN EFFECT
NO WRITE-DOWN IS NOT IN EFFECT
MULTI-LEVEL ACTIVE IS NOT IN EFFECT
CATALOGUED DATA SETS ONLY, IS IN EFFECT. CURRENT OPTIONS:
"CATDSNS FAIL" OPTION IS IN EFFECT
USER-ID FOR JES NJEUSERID IS : ????????
USER-ID FOR JES UNDEFINEDUSER IS : ++++++++
PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS 30 DAYS.
APPLAUDIT IS NOT IN EFFECT
ADDCREATOR IS NOT IN EFFECT
KERBLVL = 0
MULTI-LEVEL FILE SYSTEM IS NOT IN EFFECT
MULTI-LEVEL INTERPROCESS COMMUNICATIONS IS NOT IN EFFECT
MULTI-LEVEL NAME HIDING IS NOT IN EFFECT
SECURITY LABEL BY SYSTEM IS NOT IN EFFECT
PRIMARY LANGUAGE DEFAULT : ENU
SECONDARY LANGUAGE DEFAULT : ENU
Analizaremos a continuación el significado de las distintas opciones.
5.4 - Estadísticas iniciales

Sintaxis:
SETROPTS|SETR INITSTATS|NOINITSTATS
Autoridad requerida: SPECIAL a nivel de sistema
Opción sugerida: INITSTATS.
El parámetro INITSTATS indica que RACF guardará, en el perfil de cada usuario, las siguientes
estadísticas básicas:
Día y hora de la última vez que RACF verificó la identidad del usuario, valor que normalmente
coincide con el día y la hora de su último logon (campo LAST-ACCESS en la salida del
comando LISTUSER).
Día y hora de la última vez que RACF verificó la identidad del usuario para cada uno de los
grupos a los que se encuentra conectado (campo LAST-CONNECT en la salida del comando
LISTUSER).

60
Cantidad de veces que RACF verificó la identidad del usuario para cada grupo a los que se
encuentra conectado (campo CONNECTS en la salida del comando LISTUSER).
Recordemos que los campos LAST-CONNECT y CONNECTS solo se actualizan para el grupo default,
salvo que se especifique uno distinto en la pantalla de logon de la aplicación –si lo permitiera-.
Varias otras opciones de la SETROPTS solo funcionan si INITSTATS está vigente (INACTIVE,
REVOKE, HISTORY, WARNING). Es absolutamente recomendable tener la opción INITSTATS, que
por otro lado es la que viene por defecto en una base recién inicializada.
NOINITSTATS establece que RACF no guardará la información detallada previamente.
5.5 - Control de programas

Sintaxis:
SETROPTS|SETR WHEN(PROGRAM)|NOWHEN(PROGRAM)
Opción sugerida: WHEN(PROGRAM)
El operando WHEN(PROGRAM) especifica que RACF activará el control de programas a través de
perfiles en la clase PROGRAM. Este control se activa exclusivamente de este modo, siendo irrelevante
que la clase PROGRAM se encuentre o no activa. Esta es una particularidad de la clase PROGRAM,
que resulta peculiar en varios aspectos más.
NOWHEN(PROGRAM) es la opción por defecto en una base recién inicializada. Sin embargo, es
conveniente cambiar este parámetro y tener activo el control de programas (solo es necesario definir
perfiles en la clase PROGRAM para aquellos programas que se necesite efectivamente controlar).
En un capítulo posterior analizaremos con un poco más de detalle el funcionamiento y alcance de la
clase PROGRAM.
5.6 - Terminales no protegidas

Sintaxis:
SETROPTS|SETR TERMINAL(NONE|READ)
Opción sugerida: TERMINAL(READ)
Esta opción establece el UACC que asignará RACF a terminales que no estén protegidas por ningún
perfil en la clase TERMINAL (o su agrupadora, GTERMINL). Sólo tiene efecto si la clase TERMINAL
se encuentra activa, es decir si RACF está verificando efectivamente la autorización de usuarios sobre el
uso de terminales.
El valor por defecto en una base recién inicializada es READ. Si se pretende especificar
TERMINAL(NONE), debe estarse completamente seguro de que toda terminal tiene un perfil protector
con una adecuada lista de acceso. Usualmente, un control tan estricto no es necesario, y el valor NONE
puede resultar contraproducente. Aconsejamos el valor READ.
5.7 - Auditoría de usuarios con atributo SPECIAL

Sintaxis:
SETROPTS|SETR SAUDIT|NOSAUDIT
Autoridad requerida: AUDITOR a nivel de sistema
Opción sugerida: SAUDIT

61
SAUDIT, que significa special audit, indica que para todos los usuarios con atributo SPECIAL (tanto a
nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF cada vez que ejecuten
exitosamente comandos de RACF (con excepción de los comandos LISTUSER, LISTGROUP,
LISTDSD, RLIST y SEARCH, que nunca se registran ya que no se consideran críticos pues no realizan
ninguna modificación).
SAUDIT es la opción en efecto en una base recién inicializada. Como los usuarios con atributo
SPECIAL tienen un enorme poder dentro de la organización, y deben ser pocos, resulta aconsejable
monitorear detalladamente su actividad, por lo cual aconsejamos especificar SAUDIT.
5.8 - Auditoría de violación de comandos

Sintaxis:
SETROPTS|SETR CMDVIOL|NOCMDVIOL
Opción sugerida: CMDVIOL
CMDVIOL, que significa command violation, indica que se grabarán registros tipo 80 de SMF cada vez
que se intente ejecutar un comando de RACF que resulte fallido por carecer el usuario de la autoridad
necesaria (con excepción de los comandos LISTUSER, LISTGROUP, LISTDSD, RLIST y SEARCH,
cuyas ejecuciones fallidas no se registran).
CMDVIOL es la opción en efecto en una base recién inicializada. Los intentos fallidos de ejecución de
comandos de RACF deben ser analizados. Si se trata de un comando que corresponde, debe otorgarse al
usuario la autoridad necesaria para que pueda ejecutarlo exitosamente. Si, en cambio, se trata de un
usuario que intenta ejecutar un comando de RACF que no le compete, deben tomarse las medidas que
se consideren convenientes. En cualquier caso, la cantidad de comandos fallidos de RACF no debería
ser elevada.
5.9 - Auditoría de usuarios con atributo OPERATIONS

Sintaxis:
SETROPTS|SETR OPERAUDIT|NOOPERAUDIT
Opción sugerida: sin sugerencia
OPERAUDIT, que significa operations audit, indica que para todos los usuarios con atributo
OPERATIONS (tanto a nivel de sistema como a nivel de grupo) se grabarán registros tipo 80 de SMF
en las siguientes situaciones:
Acceso exitoso a un recurso protegido posibilitado por el atributo OPERATIONS.
Ejecución exitosa de los comandos ADDSD y RDEFINE posibilitada por el atributo
OPERATIONS.
Definición de un nuevo recurso cuya creación esté controlada por RACF (la alocación de un
nuevo dataset, por ejemplo) y que resulte exitosa gracias al atributo OPERATIONS.
Por ejemplo, supongamos que está OPERAUDIT en efecto, que el usuario USUA tiene el atributo
OPERATIONS a nivel de sistema y que intenta modificar un archivo protegido por el perfil PROD.**
que tiene UACC(NONE).
- Si USUA figura en la lista de acceso de PROD.** con autoridad UPDATE (o superior), el acceso
resulta exitoso, no por el atributo OPERATIONS, sino por su presencia en la lista de acceso. Por
lo tanto, en este caso, el parámetro OPERAUDIT no provocará la grabación de un registro de
auditoría.

62
- Si ni USUA ni ninguno de los grupos a los que está conectado figura en la lista de acceso de
PROD.** (ni existe una regla en la GLOBAL que posibilite el acceso), entonces el acceso
resultará exitoso debido a la autoridad ALTER que otorga implícitamente el atributo
OPERATIONS sobre el perfil PROD.**. Por lo tanto, el parámetro OPERAUDIT provocará la
grabación de un registro de auditoría reflejando el evento.
NOOPERAUDIT es la opción en efecto en una base recién inicializada. Como ya hemos señalado, no
es aconsejable tener en la base usuarios con el atributo OPERATIONS. Sin embargo, si la organización
decide lo contrario, debe tenerse en cuenta que un usuario con este atributo y una intensa actividad (por
ejemplo, el usuario asociado al DFHSM), puede generar un volumen enorme de registros de SMF. En
tal caso, NOOPERAUDIT sería lo más apropiado. En cambio, si existen pocos usuarios con el atributo
OPERATIONS y su actividad es reducida, monitorearlos a través de la opción OPERAUDIT puede ser
una buena idea.
5.10 - Clases con estadísticas

Sintaxis:
SETROPTS|SETR {STATISTICS|NOSTATISTICS}(clase…|*)
Opción sugerida: NOSTATISTICS para todas las clases
Se puede especificar con el operando STATISTICS|NOSTATISTICS la clase DATASET o cualquier
otra clase definida en la CDT. Si se codifica *, todas las clases resultan afectadas (con excepción de las
clases USER y GROUP).
Si una clase está bajo STATISTICS, RACF mantendrá un determinado conjunto de estadísticas para sus
perfiles discretos. En tal caso, en cada perfil discreto se almacenará la siguiente información:
- Cantidad de veces que se accedió al recurso para cada nivel de autoridad.
- Fecha de la última referencia.
- Fecha de la última modificación.
- Para cada entrada en la lista de acceso, la cantidad de veces que se otorgó acceso al recurso.
Tales estadísticas nunca se mantienen para perfiles genéricos.
No deben confundirse estas estadísticas con aquellas a las que se refiere la opción INITSTATS que
analizamos previamente.
Los operandos STATISTICS y NOSTATISTICS afectan no solo a la clase especificada sino también a
todas aquellas otras que eventualmente compartan el mismo posit value.
El mantenimiento de estadísticas, cuando la cantidad de perfiles discretos es importante, afecta la
performance negativamente. Por lo tanto, salvo que exista una fuerte necesidad de contar con dicha
información, resulta aconsejable no tener ninguna clase bajo STATISTICS.
5.11 - Clases auditadas

Sintaxis:
SETROPTS|SETR {AUDIT|NOAUDIT}(clase…|*)
Opción sugerida: AUDIT para todas las clases, activas o no, con excepciones muy puntuales
Se puede especificar con el operando AUDIT|NOAUDIT las clases USER, GROUP, DATASET o
cualquier otra clase definida en la CDT. Si se codifica *, todas las clases resultan afectadas.
Si una clase tiene AUDIT, entonces se generarán registros de SMF cada vez que se ejecute un comando
de RACF que afecte perfiles de esa clase (con excepción de los comandos que únicamente listan

63
información). También grabarán registros las solicitudes de DEFINE para esa clase (por ejemplo, si está
la clase DATASET bajo AUDIT, toda alocación de un nuevo archivo).
Para los usuarios con atributo SPECIAL, el ya mencionado parámetro SAUDIT provoca la generación
de registros de SMF toda vez que ejecutan comandos de RACF. Si la clase a la que pertenece el perfil
afectado está bajo AUDIT, no se generarán dos registros distintos por el mismo evento, sino que se
grabará un único registro. No debe pues temerse la redundancia que pueden presentar los parámetros
SAUDIT, OPERAUDIT y AUDIT usados conjuntamente, ya que no aumentan la cantidad de registros
de grabados.
Los operandos AUDIT y NOAUDIT afectan no solo a la clase especificada sino también a todas
aquellas otras que eventualmente compartan el mismo posit value.
Recomendamos tener bajo AUDIT a todas las clases de RACF. Recordemos que, si una determinada
clase no se encuentra activa, RACF no la utiliza para controlar accesos a recursos, pero ello no significa
de ninguna manera que no se puedan definir, modificar o borrar perfiles. Por lo tanto, con el objeto de
monitorear toda modificación sobre la base de RACF, es conveniente auditar todas las clases, lo cual se
logra de manera sencilla ejecutando el comando:
SETROPTS AUDIT(*)
La única excepción que creemos debería valorarse es el caso de las clases relacionadas con auditoría de
actividad en z/OS USS (Unix System Services), pues pueden generar un gran volumen de registros de
poca utilidad (Ej: FSOBJ, IPCOBJ y PROCESS). Para ellas, luego de ejecutado el comando anterior,
puede sacárselas de la categoría AUDIT mediante el comando “SETROPTS NOAUDIT(clase)”.
En una base de RACF recién inicializada, está en efecto la opción NOAUDIT(*), lo cual significa que
ninguna clase está bajo AUDIT. Esto debería modificarse antes de empezar a utilizar el sistema para
tareas productivas.
5.12 - Clases activas

Sintaxis:
SETROPTS|SETR {CLASSACT|NOCLASSACT}(clase…|*)
Opción sugerida: depende de cada organización
Se puede especificar con el operando CLASSACT|NOCLASSACT cualquier clase de recursos
generales. Las clases USER, GROUP y DATASET se encuentran siempre activas y no se las puede
desactivar.
Únicamente si una determinada clase se encuentra activa RACF utilizará sus perfiles para controlar el
acceso a recursos. Es decir, a los efectos del chequeo de autoridad de un usuario sobre un recurso, una
clase inactiva no cumple ninguna función.
Los operandos CLASSACT y NOCLASSACT afectan no solo a la clase especificada sino también a
todas aquellas otras que eventualmente compartan el mismo posit value.
Es recomendable tener activas solo las clases que resulten importantes para la organización, las cuáles
son usualmente muchas menos que las más de 230 provistas por IBM. Alrededor de 60 clases activas
suele ser suficiente para una organización promedio.
Toda clase tiene asociado un DFTRETC (Default Return Code) especificado en la CDT, que puede ser
0, 4 u 8. Este valor indica el código de retorno que RACF devolverá a la aplicación solicitante en caso
de no encontrar un perfil que proteja el recurso en cuestión (suponiendo que la clase se encuentre
activa). Su significado es el siguiente:

64
0 El requerimiento de acceso se acepta

4 Se informa a la aplicación que no existe perfil protector
8 El requerimiento de acceso se rechaza
En cualquier caso, recordemos que es siempre la aplicación la que autoriza o rechaza una solicitud de
acceso. Aún cuando reciba un código de retorno 0 u 8, la aplicación puede no cumplir con las directivas
de RACF (aunque esto es muy poco frecuente).
La mayoría de las clases tienen un DFTRETC igual a 4, con lo cual la inexistencia de un perfil protector
del recurso deja en manos de la aplicación la decisión de otorgar o rechazar el pedido de acceso.
Existen algunas clases cuyo DFTRETC es 8 (JESSPOOL, por ejemplo). En tales casos, si la clase está
activa, aquellos recursos no protegidos resultan inaccesibles. Activar una clase con DFTRETC igual a 8,
sin antes definir adecuadamente todos los perfiles necesarios, puede acarrear graves inconvenientes de
acceso. Por tal motivo, RACF emite el siguiente mensaje informativo al momento de su activación:
“ICH14073I WARNING: Class class-name was activated by the SETROPTS command. Authorization
checks might fail.”
El comando “SETROPTS CLASSACT(*)” activa todas las clases con excepción de aquellas cuyo
DFTRETC sea igual a 8. En cambio, el comando “SETROPTS NOCLASSACT(*)” inactiva todas las
clases, independientemente de su DFTRETC (con excepción de USER, GROUP y DATASET).
En cualquier caso, activar una clase es una acción de suma importancia, y no debe hacerse sin tener bien
en claro su funcionamiento y alcance.
En una base recién inicializada, está en efecto la opción NOCLASSACT(*), lo cual significa que
ninguna clase está activa (con excepción, claro está, de USER, GROUP y DATASET). Por lo tanto,
antes de empezar a utilizar el sistema para tareas productivas, deben definirse los perfiles apropiados y
activar las clases necesarias.
5.13 - Clases con perfiles genéricos

Sintaxis:
SETROPTS|SETR {GENERIC|NOGENERIC}(clase…|*)
Se puede especificar con el operando GENERIC|NOGENERIC la clase DATASET o cualquier clase de
recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y
aquellas que, según su definición en la CDT, no admitan perfiles genéricos (SECLABEL, por ejemplo).
La opción GENERIC para una clase indica que RACF tendrá en cuenta sus eventuales perfiles
genéricos para responder sobre un requerimiento de acceso. Naturalmente, también utilizará los perfiles
discretos que existan.
En cambio, la opción NOGENERIC significa que RACF no considerará sus perfiles genéricos a la hora
de decidir sobre un requerimiento de acceso. Por lo tanto, en este caso, los eventuales perfiles genéricos
de la clase no cumplen función alguna en el momento de otorgar o denegar una solicitud de acceso.
Los operandos GENERIC y NOGENERIC afectan no solo a la clase especificada sino también a todas
aquellas otras que eventualmente compartan el mismo posit value (con excepción de las eventuales
clases agrupadoras).
En una base de RACF recién inicializada, está en efecto la opción NOGENERIC(*), lo cual significa
que para ninguna clase se toman en cuenta perfiles genéricos para decidir sobre requerimientos de

65
acceso. Siempre que sea posible utilizarlos, los perfiles genéricos facilitan la administración. Por lo
tanto, se aconseja especificar GENERIC para todas las clases activas que admitan perfiles genéricos.
5.14 - Clases con comandos genéricos

Sintaxis:
SETROPTS|SETR {GENCMD|NOGENCMD}(clase…|*)
Opción sugerida: depende de cada organización, pero las mismas que bajo GENERIC
Se puede especificar con el operando GENCMD|NOGENCMD la clase DATASET o cualquier clase de
recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo) y
aquellas que, según su definición en la CDT, no admitan perfiles genéricos (SECLABEL, por ejemplo).
La opción GENCMD para una clase indica que RACF permitirá procesar comandos que afecten a sus
perfiles genéricos. A veces resulta necesario desactivar momentáneamente el chequeo de perfiles
genéricos para determinada clase, pero mantener al mismo tiempo la posibilidad de definir, modificar o
deletear perfiles genéricos existentes. En tal caso, el comando “SETROPTS NOGENERIC(clase)
GENCMD(clase)” permite realizar las tareas de mantenimiento deseadas. Si se especifica GENERIC
para una clase, automáticamente se le aplica también el operando GENCMD. Por el contrario, si se
codifica la opción NOGENERIC, NOGENCMD no se aplica de manera automática. En una situación
normal, el listado de clases bajo GENERIC y GENCMD debería ser idéntico.
Los operandos GENCMD y NOGENCMD afectan no solo a la clase especificada sino también a todas
las otras que eventualmente compartan el mismo posit value (con excepción de las eventuales clases
agrupadoras).
En una base de RACF recién inicializada, está en efecto la opción NOGENCMD(*). Se aconseja
especificar GENCMD para todas las clases activas que admitan perfiles genéricos.
5.15 - Clases con perfiles genéricos compartidos en memoria (GENLISTeadas)

Sintaxis:
SETROPTS|SETR {GENLIST|NOGENLIST}(clase…)
Opción sugerida: ninguna clase
La opción GENLIST establece que los perfiles genéricos de la clase se cargarán en memoria, en un
espacio compartido accesible por las distintas aplicaciones. En efecto, en lugar de existir una copia del
perfil genérico en cada address space que lo requiera, se lo copiará a un sector común de la memoria la
primera vez que se lo necesite, y permanecerá allí de modo que cualquier otra aplicación pueda
utilizarlo sin tener que extraerlo nuevamente de la base. Esto no solo ahorra espacio en memoria sino
que eventualmente mejora la performance, ya que resulta mucho más rápido acceder a un perfil en
memoria que buscarlo en la base de RACF residente en disco a través de un costoso I/O. En
contrapartida, cada vez que se modifique un perfil genérico de la clase bajo GENCMD, será necesario
reemplazar la versión desactualizada almacenada en memoria mediante la ejecución del comando:
SETROPTS GENERIC(clase) REFRESH
No todas las clases admiten esta opción, y la misma es excluyente con la opción RACLIST que veremos
a continuación. En la CDT está indicado qué clases admiten este parámetro. Usualmente, las clases
tienen definidos tanto perfiles genéricos como discretos, en cuyo caso suele ser mas ventajoso, si es
posible, RACLISTearlas en lugar de ponerlas bajo GENLIST. En virtud de esto, resulta frecuente no
tener ninguna clase GENLISTeada.

66
Los operandos GENLIST y NOGENLIST afectan no solo a la clase especificada, sino también a todas
las otras que tengan el mismo posit value y sean pasibles de ser GENLISTeadas.
En una base de RACF recién inicializada, está en efecto la opción NOGENLIST(*), es decir que
ninguna clase se encuentra bajo GENLIST.
5.16 - Clases en la GLOBAL

Sintaxis:
SETROPTS|SETR {GLOBAL|NOGLOBAL}(clase…|*)
Opción sugerida: DATASET + otras que la organización considere apropiadas
Se puede especificar con el operando GLOBAL|NOGLOBAL la clase DATASET o cualquier clase de
recursos generales, excepto las clases agrupadoras (GDASDVOL o GTERMINL, por ejemplo).
Si una clase está bajo GLOBAL en la SETROPTS, ello significa que RACF utilizará la información del
perfil correspondiente de la clase GLOBAL para eventualmente otorgar un acceso solicitado. Veremos
de manera precisa en un capítulo posterior de qué manera actúa la clase GLOBAL en el proceso de
chequeo de autoridad de un usuario sobre un recurso.
Los operandos GLOBAL y NOGLOBAL afectan no solo a la clase especificada sino también a todas
aquellas otras que tengan idéntico posit value (con excepción de las eventuales clases agrupadoras).
En una base de RACF recién inicializada, está en efecto la opción NOGLOBAL(*), es decir que para
ninguna clase RACF procesa la información de la GLOBAL. Es altamente recomendable tener al menos
la clase DATASET bajo GLOBAL, ya que existen seguramente archivos de uso público muy frecuente
(catálogos de usuario, por ejemplo), en cuyo caso una regla apropiada en la GLOBAL puede mejorar
sensiblemente la performance.
5.17 - Clases con perfiles genéricos y discretos compartidos en memoria –RACLISTeadas-

Sintaxis:
SETROPTS|SETR {RACLIST|NORACLIST}(clase…)
Opción sugerida: todas las clases activas que lo admitan (salvo que sean de muy poco uso)
La opción RACLIST establece que los perfiles genéricos y discretos de la clase se cargarán en memoria,
en un sector compartido (data space) que estará disponible para las distintas aplicaciones. Como ya
mencionáramos, para una clase dada, RACLIST y GENLIST son operandos excluyentes.
Sólo las clases que tienen RACLIST=ALLOWED especificado en la CDT pueden ser RACLISTeadas.
No se puede especificar RACLIST para una clase agrupadora (GCICSTRN o VCICSCMD, por
ejemplo). De todos modos, si la correspondiente “clase de miembros” (member class) está
RACLISTeada, al cargarse la información de sus perfiles en memoria ésta se combina con la contenida
en los perfiles de la clase agrupadora. Esto se analizará en detalle en un capítulo posterior.
Cada vez que se modifique un perfil -genérico o discreto- de una clase RACLISTeada, será necesario
actualizar la información almacenada en memoria ejecutando el comando:
SETROPTS RACLIST(clase) REFRESH
De todos modos, RACF informa con un mensaje por pantalla que los cambios no serán reflejados hasta
que el comando de REFRESH haya sido ejecutado.
Aún si se modificó información de un perfil de una clase agrupadora, el comando de REFRESH debe
ejecutarse especificando la “clase de miembros”.

67
Los operandos RACLIST y NORACLIST afectan no solo a la clase especificada, sino también a todas
las otras que eventualmente compartan el mismo posit value (y sean pasibles de ser RACLISTeadas).
Las siguientes clases provistas por IBM, en caso de estar activas, deben obligatoriamente estar
RACLISTeadas:
APPCSERV DEVICES NODES PTKTDATA STARTED

APPCTP DIGTNMAP OPERCMDS RACFVARS SYSMVIEW
CSFKEYS FIELD PROPCNTL SECLABEL UNIXPRIV
CSFSERV IDIDMAP PSFMPL SERVAUTH VTAMAPPL
Adicionalmente, IBM recomienda RACLISTear las siguientes clases, suponiendo que estén activas:
ACCTNUM DIGTCERT JESJOBS PTKTVAL SURROGAT

APPL DIGTCRIT JESPOOL PRINTSRV TERMINAL
CDT DIGTRING LDAPBIND RRSFDATA TSOAUTH
CONSOLE DSNR MGMTCLAS SDSF TSOPROC
DASDVOL FACILITY PERFGRP STORCLAS WRITER
En cuanto al resto de las clases activas y factibles de ser RACLISTeadas, el hacerlo o no es una
decisión que debe tomar cada organización. Si se trata de una clase con muy poca actividad, no se gana
demasiado RACLISTeándola (aunque tampoco resultaría perjudicial hacerlo, de no ser por la necesidad
de refrescar los perfiles cada vez que se efectúa alguna modificación). En cambio, si se trata de una
clase con perfiles utilizados con relativa frecuencia, resulta sin duda conveniente RACLISTearla.
En una base de RACF recién inicializada ninguna clase está RACLISTeada. Esta configuración inicial
debe cambiarse de acuerdo a lo señalado en el párrafo anterior.
5.18 - Clases RACLISTeadas vía RACROUTE REQUEST=LIST, GLOBAL=YES

Si observamos la salida del comando “SETROPTS LIST”, vemos que a continuación del listado de las
clases RACLISTeadas con el comando “SETROPTS RACLIST(clase)”, aparece un listado de clases
bajo el rótulo “GLOBAL=YES RACLIST ONLY”. En el ejemplo que nos ocupa, figuran allí las clases
TCICSTRN y CCICSCMD, ambas relacionadas con CICS.
Estas clases no han sido RACLISTeadas por un administrador de RACF con atributo SPECIAL, sino
que las ha RACLISTeado alguna aplicación que las utiliza. En nuestro ejemplo, la primera región CICS
que se levanta se encarga de RACLISTear ambas clases. Si se ejecutara el comando “SETROPTS
LIST” en un momento en que ninguna región CICS se encuentre activa, entonces ninguna de estas
clases aparecería RACLISTeada.
Mas allá de esta diferencia, las clases RACLISTeadas de este modo se comportan de manera idéntica a
aquellas que lo han sido a través del comando “SETROPTS RACLIST(clase)”. Una diferencia que vale
la pena mencionar es que, para las clases bajo “GLOBAL=YES RACLIST ONLY”, RACF no informa
la necesidad de ejecutar el comando de REFRESH si se quiere que tome efecto una modificación, como
sí lo hace en el caso de aquellas RACLISTeadas por comando.

68
5.19 - Opciones de logging para clases

Sintaxis:
SETROPTS|SETR LOGOPTIONS(nivel(clase…)...)
Opción sugerida: todas las clases con LOGOPTIONS en DEFAULT
Se puede especificar con el operando LOGOPTIONS la clase DATASET o cualquier otra definida en la
CDT. Los posibles niveles son:
ALLWAYS
NEVER
SUCCESSES
FAILURES
DEFAULT
El nivel especificado determina qué tipo de intentos de acceso se pretende registrar en SMF. Su
significado es el siguiente:
ALLWAYS indica que todo acceso a un recurso, exitoso o fallido, que involucre la consulta de
un perfil de la clase, generará un registro de auditoría. ALLWAYS tiene prioridad sobre la
configuración de auditoría que tenga cada perfil. Por lo tanto, aunque un determinado perfil
tenga especificado únicamente FAILURES(READ) como opción de auditoría, si la clase se
encuentra bajo LOGOPTIONS(ALLWAYS), se grabarán registros aún para los accesos exitosos
(a cualquier nivel).
NEVER establece que ningún acceso que involucre la consulta de un perfil de la clase generará
un registro de auditoría. NEVER tiene prioridad sobre la configuración de auditoría a nivel de
perfil. Por lo tanto, no se grabará ningún registro, aún cuando los perfiles tengan opciones de
auditoría que indiquen lo contrario.
SUCCESSES indica que se generará un registro auditoríapor cada acceso exitoso que involucre
la consulta de un perfil de la clase. En este caso, este nivel de auditoría se agrega al que ya tiene
especificado el perfil. Por ejemplo, si un perfil tiene especificado únicamente
FAILURES(UPDATE) y la clase está bajo LOGOPTIONS(SUCCESSES), se generarán
registros para todo acceso exitoso y los intentos fallidos de UPDATE (o superior).
FAILURES determina que se generará un registro de auditoría por cada acceso fallido que
involucre la consulta de un perfil de la clase. En este caso, al igual que para SUCCESSES, este
nivel de auditoría se agrega al propio del perfil. Por ejemplo, si un perfil tiene especificado
únicamente SUCCESS(UPDATE) y la clase está bajo LOGOPTIONS(FAILURES), se
generarán registros para todo acceso fallido y todo intento exitoso de UPDATE (o superior).
DEFAULT indica que el nivel de auditoría sobre un recurso estará dado por el establecido en su
perfil protector.
Cada clase puede tener un único nivel de LOGOPTIONS. Por lo tanto, para cambiar el nivel de una
determinada clase, basta con asignarle el nuevo.
El operando LOGOPTIONS afecta no solo a la clase especificada, sino también a todas aquellas otras
que eventualmente compartan el mismo posit value.
En una base recién inicializada, todas las clases se encuentran bajo LOGOPTIONS(DEFAULT).
Recomendamos mantener esta configuración, y controlar el nivel de auditoría a través de las opciones
propias de los perfiles.
Una excepción son ciertas clases relacionadas con z/OS USS, que si bien no admiten perfiles, permiten
controlar, a través de la SETROPTS, el nivel de auditoría sobre ciertos eventos (en algunos casos al

69
ponerlas bajo AUDIT, y en otros mediante LOGOPTIONS). Por ejemplo, la clase FSSEC permite
auditar las modificaciones sobre los permisos de archivos y directorios del z/OS USS. Especificar
LOGOPTIONS(ALLWAYS) para FSSEC podría ser, por lo tanto, una opción a considerar.
5.20 - Protección automática de datasets

Sintaxis:
SETROPTS|SETR ADSP|NOADSP
Opción sugerida: NOADSP
La opción NOADSP de la SETROPTS establece que RACF no aplicará la “protección automática de
datasets” aún para aquellos usuarios que tengan el atributo ADSP (a nivel de sistema o a nivel de
grupo). En este caso, el listado de la SETROPTS muestra la leyenda:
AUTOMATIC DATASET PROTECTION IS NOT IN EFFECT
Por el contrario, la opción ADSP en la SETROPTS indica que la “protección automática de datasets”
está globalmente activa, pero solo será aplicada para los usuarios que tengan efectivamente el atributo
ADSP. Por lo tanto, si ningún usuario tiene el atributo ADSP, las opciones ADSP|NOADSP a nivel de
la SETROPTS resultan equivalentes.
En una base recién inicializada, se encuentra activa la opción ADSP. Debido a la ya comentada
tendencia a utilizar exclusivamente perfiles genéricos de dataset, recomendamos cambiarla por
NOADSP. Esto elimina de raíz la posibilidad de que algún usuario genere de manera automática
perfiles discretos.
5.21 - Uso del ** en perfiles genéricos de dataset

Sintaxis:
SETROPTS|SETR EGN|NOEGN
Opción sugerida: EGN
EGN significa Enhanced Generic Naming, y se refiere a la posibilidad de emplear el símbolo ** en
perfiles de dataset (y entradas en la GLOBAL para reglas de DATASET). La opción EGN|NOEGN
afecta únicamente a la clase DATASET. El uso del ** en perfiles de recursos generales está siempre
permitido y no guarda ninguna relación con este parámetro.
Como ya hemos señalado, el uso del ** hace realmente más cómoda la administración de perfiles
genéricos de dataset, por lo cual recomendamos activar la opción EGN. En el caso de estar en efecto la
opción NOEGN, el significado del * en perfiles genéricos de dataset varía con respecto al que tiene
cuando EGN está activa (no entraremos en detalles al respecto). En cualquier caso, si se han definido
perfiles conteniendo ** (con la opción EGN activa, naturalmente), debe tenerse cuidado en no cambiar
con posterioridad a la opción NOEGN, ya que ello provocaría sin duda problemas y confusión en la
protección de datasets.
La opción EGN activa en la SETROPTS se manifiesta a través de la siguiente leyenda:
ENHANCED GENERIC NAMING IS IN EFFECT
En una base recién inicializada, se encuentra en efecto la opción NOEGN. Resulta conveniente
modificar esta opción.

70
5.22 - Nombres reales de dataset

Sintaxis:
SETROPTS|SETR REALDSN|NOREALDSN
Opción sugerida: REALDSN
Ya sea a través de la implementación de una “tabla de convención de nombres” (naming convention
table) o mediante la implementación de una exit apropiada, se puede convertir el nombre real de un
archivo antes de que sea pasado a RACF. Esto permite, por ejemplo, proteger archivos cuyos nombres
reales no tengan una nomenclatura admitida por RACF.
La opción REALDSN establece que, tanto en los registros de SMF como en los mensajes de operador,
se mostrará el nombre real del archivo, aún cuando el mismo haya sido modificado a los efectos del
chequeo de autoridad. Por el contrario, si la opción en efecto es NOREALDSN, el nombre mostrado en
ambos casos no será el real sino el modificado que recibe RACF.
A menos que exista una fuerte necesidad al respecto, no se aconseja de ninguna manera convertir los
nombres de los archivos que se le comunican a RACF, ya que ello complica la administración.
La opción REALDSN activa en la SETROPTS se manifiesta a través de la siguiente leyenda:
REAL DATA SET NAMES OPTION IS ACTIVE
En una base recién inicializada, se encuentra en efecto la opción NOREALDSN. Aconsejamos cambiar
por la opción REALDSN, aún cuando esto resulta irrelevante si la organización, tal como
recomendamos, no utiliza una “tabla de convención de nombres” o exits que modifiquen, con miras al
chequeo de seguridad, el nombre real de los archivos.
5.23 - Opciones relativas a JES

Sintaxis:
SETROPTS|SETR JES([BATCHALLRACF|NOBATCHALLRACF]
[EARLYVERIFY|NOEARLYVERIFY]
[XBMALLRACF|NOXBMALLRACF]
[NJEUSERID(userid)]
[UNDEFINEDUSER(userid)])
Opciones sugeridas: BATCHALLRACF, EARLYVERIFY, XBMALLRACF, usuarios por defecto
Existen varias opciones en la SETROPTS relativas a JES, que describimos brevemente a continuación:
BATCHALLRACF exige que todo job batch tenga una identidad válida. A tal efecto, caben las
siguientes posibilidades:
La tarjeta job contiene explícitamente usuario y password. Esta opción es poco recomendable,
ya que debe evitarse la exposición de passwords en texto claro.
Las credenciales se reciben propagadas, por ejemplo al utilizar el comando SUBMIT de TSO.
Se trata de la opción más frecuente.
La tarjeta job solo tiene especificado usuario, y quién submite tiene la autorización apropiada en
la clase SURROGAT para ejecutar jobs en nombre del usuario de ejecución.
Si el job no tiene una identidad válida de RACF, entonces cancela.
Si NOBATCHALLRACF está en efecto, la ausencia de un usuario no impide que el job se ejecute.
Naturalmente, es probable que encuentre problemas de autorización si trata de acceder a recursos

71
protegidos para los cuales ni la GLOBAL ni el UACC del perfil protector son suficientes para otorgar el
acceso solicitado.
EARLYVERIFY hace referencia a un control de usuario, password y grupo que efectúa JES invocando
a la SAF en caso de no recibir información propagada. Con las versiones actuales de JES esto se realiza
siempre, independientemente de la codificación de este parámetro en la SETROPTS. Por lo tanto,
EARLYVERIFY|NOEARLYVERIFY se ha convertido en una opción irrelevante.
XBMALLRACF es idéntico a BATCHALLRACF pero para jobs que se ejecutan bajo el Execution
Batch Monitor.
La opción NJEUSERID define el usuario que se asignará a los jobs o sysouts que reciba el sistema y no
tengan RTOKEN u UTOKEN. El valor por defecto en una base recién inicializada es ????????, el cual
sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no debe
existir en la base de RACF.
La opción UNDEFINEDUSER establece el usuario que se asignará a los jobs locales que ingresen al
sistema sin un usuario asociado. El valor por defecto en una base recién inicializada es ++++++++, el
cual sugerimos conservar. En cualquier caso, si se desea cambiarlo, el usuario que se especifique no
debe existir en la base de RACF.
En una base recién inicializada, se encuentran en efecto las opciones NOBATCHALLRACF,
NOEARLYVERIFY y NOXBMALLRACF. Recomendamos activar los 3 tipos de control (aunque en el
caso de EARLYVERIFY, es actualmente irrelevante). En el listado de la SETROPTS, las leyendas:
JES-BATCHALLRACF OPTION IS ACTIVE
JES-XBMALLRACF OPTION IS ACTIVE
JES-EARLYVERIFY OPTION IS ACTIVE
USER-ID FOR JES NJEUSERID IS : ????????
USER-ID FOR JES UNDEFINEDUSER IS : ++++++++
indican que los 3 tipos de control se encuentran activos y que se mantuvo el valor default para ambos
usuarios.
5.24 - Protect-all
Sintaxis:
SETROPTS|SETR PROTECTALL(FAILURES|WARNING)|NOPROTECTALL
Opción sugerida: PROTECTALL(FAILURES)
Se trata de una opción sumamente importante, que establece cómo se comportará RACF cuando se
pretenda definir o acceder a archivos no protegidos por ningún perfil de dataset. Este parámetro solo
afecta a la clase DATASET. Existen 3 seteos posibles, que describimos a continuación:
PROTECTALL en FAILURES indica que RACF no permitirá definir ni acceder a archivos que no se
encuentre protegidos por algún perfil de dataset (los archivos temporarios generados por el sistema
quedan exceptuados). Con esta configuración, los datasets “no protegidos” resultan inaccesibles, salvo
en alguna de las situaciones siguientes:
El usuario tiene el atributo SPECIAL a nivel de sistema. En este caso, si bien se autoriza el
acceso, se envía un mensaje al usuario informando que el archivo se encuentra desprotegido. El
usuario no puede, sin embargo, definir archivos desprotegidos.
El acceso lo solicita una started task que está marcada como TRUSTED o PRIVILEGED. En
este caso, se autoriza el acceso pero no se envía ningún mensaje informativo.
Existe una entrada en la GLOBAL que autoriza el acceso.

72
PROTECTALL en WARNING funciona de manera similar al modo FAILURES, pero con una
diferencia fundamental. RACF, en lugar de rechazar el pedido, lo autoriza y remite, tanto al usuario
como al SYSLOG, un mensaje informando que archivo no se encuentra protegido.
Se debe ser cuidadoso, ya que mientras RACF tiene PROTECTALL en modo WARNING, los archivos
“no protegidos” pueden ser accedidos por cualquier usuario con el máximo nivel de autoridad. Sin
embargo, esta opción resulta sumamente útil en las etapas iniciales de la construcción de la base de
RACF, pues permite identificar e ir protegiendo paulatinamente los archivos en uso que se encuentran
desprotegidos, sin causar interrupciones en las tareas. Luego de un tiempo prudencial, pasado el cual se
estima que ya se han identificado todos los archivos en uso, se debe cambiar al modo FAILURES.
NOPROTECTALL implica que cualquier usuario puede acceder a archivos “no protegidos” con el
máximo nivel de autoridad, así como también definir nuevos archivos desprotegidos. A diferencia del
modo WARNING, ningún mensaje de alerta es generado. Esta opción es totalmente desaconsejada para
un entorno productivo.
En nuestro ejemplo, la leyenda:
PROTECT-ALL IS ACTIVE, CURRENT OPTIONS:
PROTECT-ALL FAIL OPTION IS IN EFFECT
indica que está activa la opción PROTECTALL en modo FAILURES.
En una base recién inicializada, se encuentra vigente la opción NOPROTECTALL. Se recomienda la
opción PROTECTALL en modo FAILURES, que robustece notablemente la seguridad del sistema.
5.25 - Protección de archivos en cartucho

Sintaxis:
SETROPTS|SETR TAPEDSN|NOTAPEDSN
Opción sugerida: NOTAPEDSN
La opción TAPEDSN indica que RACF controlará el acceso a archivos en cartuchos a través de perfiles
en la clase DATASET, de manera similar a como lo hace para datasets en disco. Existe una importante
relación entre esta opción y la clase TAPEVOL, que debe estudiarse cuidadosamente para comprender
exactamente su alcance. Sin embargo, no ahondaremos en ello en la presente guía.
NOTAPEDSN establece que RACF no controlará el acceso a archivos en cartuchos mediante perfiles
de dataset (excepto que se habilite este chequeo a través del miembro DEVSUPxx de la PARMLIB). De
todos modos, si el chequeo en la clase DATASET está inhibido, pueden protegerse globalmente los
volúmenes mediante perfiles en la clase TAPEVOL.
En nuestro ejemplo, se encuentra establecida la opción NOTAPEDSN, como muestra la siguiente
leyenda en el listado de la SETROPTS:
TAPE DATA SET PROTECTION IS INACTIVE
En una base recién inicializada, se encuentra en efecto la opción NOTAPEDSN. Recomendamos
NOTAPEDSN, tener la clase TAPEVOL inactiva y habilitar el chequeo de autoridad sobre archivos en
cartucho en la clase DATASET a través de la configuración del miembro DEVSUPxx residente en la
PARMLIB.
5.26 - Período de retención para archivos en cartucho

Sintaxis:
SETROPTS|SETR RETPD(valor)
Opción sugerida: depende de la organización

73
El período de retención, solo aplicable a datasets en cartucho, determina la cantidad de días en que la
protección permanecerá vigente, contados desde el día de creación del archivo. El valor establecido en
la SETROPTS se aplicará por defecto, siempre que no se establezca un valor específico para el archivo.
Se puede codificar cualquier valor comprendido entre 0 y 65533, o el valor reservado 99999 que indica
que la protección nunca expira.
El RETPD especificado en la SETROPTS solo actúa si se encuentra activa la opción TAPEDSN. En
caso contrario, resulta irrelevante. Si se activa TAPEDSN, y no se especifica un RETPD, el valor por
defecto es 0.
5.27 - Borrado físico de archivos

Sintaxis:
SETROPTS|SETR ERASE(ALL|SECLEVEL(nivel)|NOSECLEVEL)|NOERASE
Opción sugerida: ERASE(NOSECLEVEL)
En general, cuando se elimina un archivo en disco, el sistema borra la entrada correspondiente de la
VTOC del volumen dónde reside, al mismo tiempo que lo descataloga (o sea, elimina su entrada del
catálogo dónde se esté catalogado). El espacio ocupado por el archivo queda entonces disponible para
un futuro dataset, o la extensión de uno existente. Sin embargo, hasta que efectivamente se grabe allí
nueva información, los datos del archivo deleteado siguen presentes, solo que no resultan accesibles por
los medios habituales.
Existe la posibilidad de tomar una medida de seguridad adicional, que garantice la irrecuperabilidad de
los datos luego del borrado lógico del archivo, que consiste en físicamente sobrescribirlo con ceros
binarios. Sin embargo, esto resulta costoso, y puede degradar la performance, por lo cual solo estaría
justificado para el caso de información altamente sensible.
La opción ERASE de la SETROPTS permite establecer en qué casos se desea un borrado físico de un
archivo (solo se aplica a datasets en disco). Veremos a continuación las distintas opciones posibles:
ALL establece que se deben borrar físicamente todos los archivos que se borren, independientemente de
lo que indique el campo ERASE del perfil protector. Esto incluye también a los datasets temporarios. Se
trata de una medida de seguridad extrema, que realmente no se justifica en absoluto y puede impactar
negativamente en la performance del sistema.
ERASE(SECLEVEL(nivel)) indica que se debe proceder al borrado físico de todos aquellos archivos
que se deletean y cuyo perfil protector tenga un SECLEVEL (security level) mayor o igual al
especificado. En este caso, también resulta irrelevante el valor del campo ERASE del perfil de dataset.
Si el perfil protector tiene especificado ERASE=YES pero su SECLEVEL es inferior al valor de la
SETROPTS, el archivo no es borrado físicamente al ser deleteado. Como no aconsejamos, para no
complicar la administración, el uso de “niveles de seguridad”, no recomendamos tampoco la
implementación de esta opción.
ERASE(NOSECLEVEL) indica que RACF no tendrá en cuenta el SECLEVEL del perfil protector para
determinar si debe procederse o no al borrado físico del archivo. En cambio, el factor determinante para
esta decisión pasa a ser el valor del campo ERASE del perfil. Recomendamos establecer esta opción, y
únicamente codificar ERASE=YES para perfiles de dataset que protejan archivos altamente
confidenciales. Si se especifica ERASE sin ningún parámetro, el valor que asume por defecto es
NOSECLEVEL.
En nuestro ejemplo, ésta es la opción establecida, como lo muestra la leyenda:
ERASE-ON-SCRATCH IS ACTIVE, CURRENT OPTIONS:
ERASE-ON-SCRATCH BY SECURITY LEVEL IS INACTIVE

74
NOERASE indica que en ningún caso se procederá al borrado físico de los archivos,
independientemente del valor del campo ERASE del perfil protector. NOERASE es el valor que se
encuentra vigente en una base de RACF recién inicializada.
5.28 - Archivos de un único calificador

Sintaxis:
SETROPTS|SETR PREFIX(grupo)|NOPREFIX
Opción sugerida: NOPREFIX
Si la opción NOEGN se encuentra activa, RACF no permite proteger archivos que tengan un único
calificador. En tal caso, si la organización tiene tales archivos, existe la posibilidad de protegerlos
especificando un PREFIX en la SETROPTS.
Si la opción EGN está activa, el dataset ARCH1 puede protegerse por el perfil genérico ARCH1.**, por
lo cual no tiene sentido especificar un PREFIX en la SETROPTS.
La opción PREFIX(grupo) establece un prefijo que se antepondrá como HLQ, solo a los efectos del
chequeo por parte de RACF, para aquellos archivos que tengan un único calificador. El valor
especificado en el operando PREFIX debe ser un grupo existente en la base de RACF, y no deben
existir ni archivos ni perfiles de dataset cuyo HLQ sea ese grupo.
NOPREFIX no establece ningún prefijo. Como recomendamos tener la opción EGN activa, sugerimos
asimismo establecer NOPREFIX. En cualquier caso, no parece conveniente hacer uso de archivos que
tengan un único calificador, para evitar este tipo de disquisiciones. Esta es la opción vigente en nuestro
ejemplo, como lo muestra la leyenda:
SINGLE LEVEL NAMES NOT ALLOWED
NOPREFIX es asimismo el valor que se encuentra en efecto en una base de RACF recién inicializada.
5.29 - Lista de grupos

Sintaxis:
SETROPTS|SETR GRPLIST|NOGRPLIST
Opción sugerida: GRPLIST
GRPLIST establece que, para determinar la autoridad de un usuario sobre un recurso, RACF no solo
considerará el “actual grupo de conexión” del usuario sino todos los grupos a los cuales se encuentre
conectado (con una conexión no revocada). Con esta opción activa, el “grupo de conexión”, a los
efectos del chequeo de autoridad, se vuelve básicamente irrelevante. En consecuencia, el usuario no
debe preocuparse por el grupo que especifica en la pantalla de logon a las aplicaciones.
Es la opción ampliamente preferida en la actualidad, ya que simplifica la tarea al usuario, sin resignar en
absoluto aspectos de seguridad del sistema.
En nuestro ejemplo, GRPLIST se encuentra en efecto, como se deduce de la leyenda siguiente:
LIST OF GROUPS ACCESS CHECKING IS ACTIVE
Si la opción NOGRPLIST está activa, entonces solo el “actual grupo de conexión” del usuario es tenido
en cuenta por RACF en el proceso de chequeo de autoridad.
Antiguamente no existía la opción GRPLIST, por lo que considero que se mantiene la posibilidad de
establecer NOGRPLIST únicamente para mantener una compatibilidad hacia atrás, ya que realmente
presenta varios inconvenientes y ninguna ventaja evidente.
NOGRPLIST es la opción que se encuentra en efecto en una base de RACF recién inicializada.

75
5.30 - Revocación automática por inactividad

Sintaxis:
SETROPTS|SETR INACTIVE(valor)|NOINACTIVE
Opción sugerida: INACTIVE(40)
El valor codificado en el operando INACTIVE establece la cantidad consecutiva de días de inactividad
pasados los cuales RACF revoca automáticamente al usuario. Debe estar comprendido entre 1 y 255.
El chequeo que lleva a cabo RACF es el siguiente:
Cada vez que un usuario se loguea a alguna aplicación (TSO, CICS, IMS, etc.), o se inicia la ejecución
de un job, RACF compara la fecha actual del sistema con la fecha que figura en el campo LAST-
ACCESS del perfil del usuario. Si la diferencia entre ambas fechas excede el valor especificado para
revocación automática por inactividad en la SETROPTS, entonces RACF revoca al usuario.
Recordemos que el campo LAST-ACCESS del perfil del usuario puede modificarse, no solo mediante
el logon efectivo del usuario, sino también en otras circunstancias, como ya viéramos en el capítulo de
administración de usuarios.
RACF revoca al usuario por inactividad cuando efectivamente intenta acceder al sistema. Por ejemplo,
si el parámetro INACTIVE especifica 30 días y un usuario lleva 31 días de inactividad, hasta tanto no
intente ingresar no será efectivamente revocado. Podríamos decir que tal usuario se encuentra
“pendiente de revocación”.
Para los usuarios que nunca ingresaron al sistema (el comando LISTUSER muestra LAST-ACCESS =
UNKNOWN), la inactividad se calcula en relación a la fecha de creación.
En nuestro ejemplo, el valor fijado es de 40 días, tal cual lo muestra la siguiente leyenda:
INACTIVE USERIDS ARE BEING AUTOMATICALLY REVOKED AFTER 40 DAYS.
NOINACTIVE establece que RACF no revocará usuarios automáticamente por inactividad. Esta es la
opción vigente en una base recién inicializada.
Recomendamos especificar la opción INACTIVE, con una cantidad que sea adecuada a las necesidades
de la organización. Un valor entre 30 y 60 días suele ser razonable.
5.31 - Modelización de perfiles de dataset

Sintaxis:
SETROPTS|SETR MODEL([GDG|NOGDG] [GROUP|NOGROUP] [USER|NOUSER])|NOMODEL
Mediante el operando MODEL, se establece en qué casos se desea utilizar la modelización de perfiles
de dataset. Esto permite que nuevos perfiles, al ser definidos, tomen las características de un “perfil
modelo” existente.
MODEL(GDG) establece que RACF intentará proteger miembros de un GDG (Generation Data
Group) que estén RACF-indicados usando un perfil de dataset cuyo nombre coincida con el nombre
base del GDG. Recomendamos la opción NOGDG y proteger todos los GDG-datasets mediante un
único perfil genérico.
MODEL(NOGDG) indica que RACF no tendrá un tratamiento especial para los GDG-datasets, sino que
los tratará del mismo modo que a cualquier otro archivo.
MODEL(GROUP) establece que cada vez que se defina un “perfil de dataset de grupo”, RACF
examirará el perfil del grupo para ver si tiene especificado un perfil modelo. En caso afirmativo, el
nuevo perfil de dataset será creado en base al modelo existente.

76
MODEL(NOGROUP) indica que no se aplicarán modelos para “perfiles de dataset de grupo”, aún
cuando el perfil del grupo correspondiente tenga un perfil modelo especificado.
MODEL(USER) indica que cada vez que se defina un “perfil de dataset de usuario”, RACF examinará
el perfil del usuario para ver si tiene especificado un perfil modelo. En tal caso, el nuevo perfil de
dataset será creado en base al modelo existente.
MODEL(NOUSER) indica que no se aplicarán modelos para “perfiles de dataset de usuario”, aún
cuando el perfil del usuario correspondiente tenga un perfil modelo especificado.
En nuestro ejemplo, establecimos que únicamente se aplique la modelización para “perfiles de dataset
de usuario”, tal cual indica la leyenda siguiente:
DATA SET MODELLING NOT BEING DONE FOR GDGS.
USER DATA SET MODELLING IS BEING DONE.
GROUP DATA SET MODELLING NOT BEING DONE.
NOMODEL establece que no se aplicará modelización de perfiles de dataset en ninguno de los 3 casos
(GDG, GROUP y USER). Esta es la opción en efecto en una base recién inicializada.
5.32 - Opciones relativas a PASSWORD

Sintaxis:
SETROPTS|SETR PASSWORD([HISTORY(valor)|NOHISTORY]
[INTERVAL(valor)]
[MINCHANGE(valor)]
.[MIXEDCASE)|NOMIXEDCASE]
[REVOKE(valor)|NOREVOKE]
[RULEn(LENGTH(min:max) tipo(posición))|NORULEn|NORULES]
[WARNING(valor)|NOWARNING]
Opciones sugeridas: HISTORY(15), INTERVAL(30), MINCHANGE(1), MIXEDCASE, REVOKE(5)
LLLLLLLL, WARNING(5)
La password de un usuario se almacena en su perfil, no en texto claro sino encriptado. Este campo no es
visible en la salida del comando LISTUSER. Tampoco está presente en la bajada plana de la base que se
obtiene a través del utilitario IRRDBU00. Sin embargo, debe destacarse que RACF no encripta la
password propiamente dicha. El valor guardado es el resultado de encriptar, vía DES (Data Encryption
Standard), el identificador de usuario, usando como clave de encriptación su password. En el momento
de autenticación, RACF reencripta el usuario con la password recibida, y si el valor resultante coincide
con el almacenado la autenticación es exitosa. Este mecanismo tiene una consecuencia interesante: 2
usuarios con idéntica password tendrán distintos valores guardados en la base de RACF. Por lo tanto,
crackear la password de un usuario no significa que se haya igualmente crackeado a otros que puedan
eventualmente tener su misma password.
Vamos a describir a continuación en detalle el significado de cada uno de los suboperandos del
operando PASSWORD.
Historial
HISTORY establece la cantidad de passwords previas del usuario que se almacenan en la base con el
objeto de que no las pueda reusar. Esto es -suponiendo que se tenga esta opción en 15, como en nuestro
ejemplo-, un usuario, al cambiar su password (ya sea voluntariamente, o porque RACF se lo exige), no
podrá especificar, ni la actual, ni ninguna de las últimas 15 que haya utilizado. El valor del operando
HISTORY debe estar comprendido entre 1 y 32.

77
Por una cuestión de seguridad, es importante utilizar esta opción con el objeto de evitar que los usuarios
mantengan siempre una misma password. Sugerimos un valor relativamente alto. Muchas
organizaciones usan incluso 32 (el valor máximo).
En nuestro ejemplo el HISTORY se fijó en 15, como se desprende de la siguiente leyenda del listado de
la SETROPTS:
De todos modos, para que este control no sea fácilmente burlado, es importante establecer asimismo un
valor apropiado para el operando MINCHANGE, que analizamos más adelante. En caso contrario,
RACF no impedirá que un usuario, al verse forzado a cambiar su password, lo haga intencionalmente en
forma consecutiva tantas veces como sea necesario para poder volver a usar su favorita. Por ejemplo, si
se guardan 15 en el historial, basta con que el usuario cambie su password 17 veces para poder volver a
especificar la actual.
Es importante hacer notar la siguiente sutileza. Supongamos que se tiene HISTORY en 15, y se decide
reducir el valor a 10. En tal caso, las passwords almacenadas entre la 11 y la 15 seguirán utilizándose en
la comparación con la nueva, aún cuando el HISTORY se encuentre en 10. Por lo tanto, como nunca
serán descartadas, quedarán eternamente prohibidas para el usuario. Existen, de todos modos,
herramientas desarrolladas para limpiar esta historia residual. Una de ellas es el utilitario CUTPWHIS,
que si bien no está oficialmente soportado por IBM, puede descargarse de su página y funciona
correctamente.
Una password “no expirada” otorgada por un usuario con capacidad administrativa mediante el
comando ALTUSER no está sujeta al chequeo contra el historial.
NOHISTORY establece que la nueva password solo será comparada con la actual. El usuario puede
entonces especificar cualquier password con la única condición de que sea diferente de la vigente. Por
lo tanto, con esta opción en efecto, un usuario podría alternar permanentemente entre 2 passwords.
NOHISTORY es la opción en efecto en una base recién inicializada. Como ya señalamos, esto no es
satisfactorio desde el punto de vista de seguridad. En nuestro ejemplo, seteamos el valor en 15, como se
observa en la siguiente leyenda del listado de la SETROPTS:
Validez máxima
INTERVAL establece la cantidad máxima de días en que la password del usuario permanecerá válida.
Superada esa cantidad, RACF fuerza al usuario a cambiarla. El valor especificado globalmente en la
SETROPTS, de mínimo 1 y máximo 254, en realidad fija un límite superior. En efecto, para cada
usuario, el intervalo pasado el cual estará obligado a cambiar su password surge del mínimo entre el
INTERVAL de su perfil y el INTERVAL a nivel de la SETROPTS (salvo que el usuario tenga
NOINTERVAL especificado en su perfil, en cuyo caso su password nunca vencerá,
independientemente del INTERVAL de la SETROPTS). Cada vez que un usuario se loguea al sistema,
RACF compara la fecha actual con la fecha del campo PASSDATE del perfil. Si la diferencia entre
ambas excede el mínimo anteriormente mencionado, se obliga al usuario a cambiar su password.
El valor por defecto en una base recién inicializada es 30, que consideramos razonable y coincide con el
fijado en nuestro ejemplo, como se sigue de la siguiente leyenda del listado de la SETROPTS:
PASSWORD CHANGE INTERVAL IS 30 DAYS.
Validez mínima
MINCHANGE establece el tiempo de vida mínimo, medido en días, que debe regir la password. El
usuario no podrá cambiarla hasta tanto hayan transcurrido, como mínimo y contados desde la fecha del
último cambio (almacenada en el campo PASSDATE del perfil), la cantidad de días especificados. El
valor debe estar comprendido entre 0 y 254. 0 indica que los usuarios podrán cambiar su password
tantas veces como quieran, sin restricción alguna. Como ya señalamos, no se trata de un seteo

78
recomendable pues permite burlar el control dado por el historial. Consideramos que 1 es un valor
razonable, pues evita el reciclaje de password a la vez que permite al usuario cambiarla con la
frecuencia que estime apropiada. Recordemos que un usuario debería cambiar inmediatamente su
password si supone que está en conocimiento de un tercero, razón por la cual un valor alto del
MINCHANGE sería contraproducente.
Es importante observar que la restricción fijada por el parámetro MINCHANGE no aplica para usuarios
con capacidad administrativa que cambian la password de otro mediante el comando ALTUSER. Por
ejemplo, aún cuando el MINCHANGE esté seteado en 1, un usuario con atributo SPECIAL a nivel de
sistema podrá cambiar la password de cualquier otro tantas veces al día como considere necesario.
El valor por defecto en una base recién inicializada es 0, que consideramos inapropiado. En nuestro
ejemplo lo establecimos en 1, como muestra la siguiente leyenda del listado de la SETROPTS:
PASSWORD MINIMUM CHANGE INTERVAL IS 1 DAYS.
Passwords sensitivas
Desde el z/OS 1.7, RACF soporta la posibilidad de distinguir entre mayúsculas y minúsculas en los
caracteres de una password. Esta opción, de implementarse, amplía enormemente el universo de
posibles passwords, tornando un intento de crackeo por fuerza bruta prácticamente inviable. En
cualquier caso, es de suma importancia proteger adecuadamente las bases activas de RACF (primaria y
backup) y todos sus resguardos –tanto en disco como en cartucho– de modo que estos intentos de
cracking ni siquiera puedan ocurrir.
MIXEDCASE indica que RACF efectivamente distinguirá entre mayúsculas y minúsculas. Es
fundamental comprender que el soporte de passwords sensitivas tiene dos puntas, por un lado la
aplicación dónde se loguea el usuario (CICS, TSO, FTP, etc.) y por otro RACF. No alcanza con que se
habilite en RACF esta opción si la aplicación no la soporta (por ejemplo, convirtiendo a mayúsculas la
password antes de presentársela a RACF). En la actualidad, todas las aplicaciones de IBM para z/OS
soportan passwords sensitivas, pero es posible que la organización use algún aplicativo propio, o de un
tercero, que no lo haga. En tal caso, hay que proceder muy cuidadosamente antes de setear
MIXEDCASE, evaluando detenidamente el impacto que puede ocasionar sobre la correspondiente
aplicación.
NOMIXEDCASE establece que RACF no distinguirá entre mayúsculas y minúsculas.
Independientemente de cómo reciba la password, RACF la convertirá a mayúsculas antes de verificarla.
Con esta opción se logra un comportamiento análogo al existente antes del z/OS 1.7, y es la que está en
efecto en una base recién inicializada.
Advertencia:
Una vez que se habilita la opción MIXEDCASE, la vuelta atrás es problemática y debe evitarse. Si esto
sucediera, aquellos usuarios cuya password contenga algún carácter en minúscula no podrán loguearse.
En efecto, al tener por un lado RACF almacenada la versión con minúsculas y por otro convertir a
mayúsculas la password recibida antes de proceder a su verificación – producto del seteo
NOMIXEDCASE -, ésta siempre resultará fallida. La única salida, en esta situación, es que el usuario
solicite a un administrador una nueva password.
En nuestro ejemplo está habilitada la opción MIXEDCASE, tal como se observa en la siguiente leyenda
del listado de la SETROPTS:
MIXED CASE PASSWORD SUPPORT IS IN EFFECT.
Revocación automática por intentos fallidos

REVOKE establece la cantidad máxima de intentos consecutivos de passwords incorrectas que RACF
tolerará antes de proceder a la revocación automática del usuario. Si el valor especificado es N,
entonces en el (N+1) intento consecutivo de ingreso especificando una password incorrecta el usuario
será automáticamente revocado. Naturalmente, un ingreso válido vuelve la cuenta a 0.

79
El valor especificado debe hallarse comprendido entre 1 y 255. Recomendamos un valor bajo, para
desalentar intentos maliciosos de adivinar la password de otro usuario. Sin embargo, un valor muy bajo
(1 o 2, por ejemplo), ocasiona problemas operativos, ya que es frecuente que un usuario tipee
involuntariamente mal su password. En nuestra opinión, 5 resulta un valor razonable, vigente en nuestro
ejemplo, como indica la leyenda:
AFTER 5 CONSECUTIVE UNSUCCESSFUL PASSWORD ATTEMPTS,
A USERID WILL BE REVOKED.
NOREVOKE indica que RACF no revocará automáticamente a los usuarios por intentos consecutivos
de ingreso con passwords incorrectas (o sea, no hay límite para la cantidad de intentos). Esta es la
opción en efecto en una base recién inicializada. Resulta, sin embargo, inadmisible desde el punto de
vista de la seguridad.
Reglas sintácticas
Con el suboperando RULE se establecen las reglas sintácticas que deben cumplir las passwords. Se
puede especificar hasta un máximo de 8 reglas, que se denominan RULEx, dónde x varía de 1 a 8. Una
password resulta sintácticamente admisible si cumple con alguna de las reglas establecidas. Para cada
regla debe definirse la longitud (mínima y máxima) y el tipo de caracteres permitidos en cada posición.
Los posibles tipos de caracteres son:
ALPHA A Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @).

CONSONANT C Consonantes en mayúscula.
ALPHANUM L Caracteres alfabéticos en mayúscula + caracteres nacionales (#, &, @)
+ caracteres numéricos (0 al 9).
NUMERIC N Caracteres numéricos (0 al 9)
VOWEL V Vocales en mayúscula: A, E, I, O, U.
NOVOWEL W Consonantes en mayúscula + caracteres nacionales (#, &, @) +
caracteres numéricos (0 al 9).
MIXEDCONSONANT c Consonantes en mayúscula o minúscula.
MIXEDNUM m Caracteres alfabéticos en mayúscula o minúscula + caracteres
nacionales (#, &, @) + caracteres numéricos (0 al 9).
MIXEDVOWEL v Vocales en mayúscula o minúscula: A, E, I, O, U, a, e, i, o, u.
NATIONAL $ Caracteres nacionales: #, &, @).
El tipo ALPHANUM exige lo siguiente:

Si existe más de un carácter de este tipo, entonces la password debe tener en esas posiciones al menos
un carácter alfabético en mayúsculas y uno numérico.
El tipo MIXEDNUM exige lo siguiente:

• Si existe un único carácter de este tipo, entonces puede ser cualquiera
• Si existen 2, la password debe tener en esas posiciones alguna de las siguientes combinaciones:
- Carácter alfabético en mayúscula o nacional + carácter alfabético en minúscula
- Carácter alfabético en mayúscula o nacional + carácter numérico
- Carácter alfabético en minúscula + carácter numérico
• Si existen 3 o más, la password debe tener en esas posiciones al menos un carácter alfabético en
mayúsculas o nacional, uno alfabético en minúsculas y uno numérico.

80
Los tipos c, m y v, que involucran caracteres alfabéticos en minúsculas, solo deben usarse si la opción
MIXEDNUM está en efecto.
La longitud admisible de la password para cada regla se establece a través del parámetro
LENGHT(min:max), dónde min indica la longitud mínima y max la máxima (max puede ser a lo sumo
igual a 8). Naturalmente, min debe ser menor o igual a max. Si se omite max, se asume max=min por lo
que la regla impone una longitud exacta.
Asimismo, para cada regla, se establece qué tipo de carácter es admisible en cada posición. La sintaxis
quedará clara a través del siguiente ejemplo:
RULE1(LENGTH(6:8) CONSONANT(1) ALPHANUM(2:6) NOVOWEL(8)
Esta regla establece que la password debe: tener una longitud mínima de 6 y máxima de 8; empezar con
una consonante; tener caracteres alfanuméricos de la posición 2 a la 6 inclusive, y un carácter “no
vocal” en la última posición. En la posición 7, no existiendo ninguna exigencia explícita, cualquier
carácter alfanumérico es aceptado. Por ejemplo, la password T4RUJY4@ cumple con la regla
establecida. Por el contrario, YHGTRF8 no la satisface, ya que entre las posiciones 2 y 6 no hay ningún
carácter numérico y ALPHANUM(2:6) exige que haya por lo menos un carácter alfabético y uno
numérico en el rango.
De todos modos, no recomendamos complicarse fijando reglas sofisticadas que seguramente serán
frecuentemente olvidadas por lo usuarios. Es conveniente, en la medida de lo posible, habilitar la opción
MIXEDCASE. En caso de no poner en práctica esta opción, la única regla establecida en nuestra
SETROPTS de ejemplo suele ser satisfactoria desde el punto de vista de seguridad.
INSTALLATION PASSWORD SYNTAX RULES:
RULE 1 LENGTH(6:8) LLLLLLLL
Observaciones:
Cuando se otorga una password expirada (lo cual sucede siempre que un administrador la otorga,
salvo que especifique explícitamente lo contrario), la misma no tiene necesidad de satisfacer las
reglas sintácticas. En cambio, si se otorga una clave no expirada, entonces debe cumplir con las
reglas globales de la organización fijadas en la SETROPTS.
Los eventuales cambio en las reglas para passwords de la SETROPTS toman efecto
inmediatamente. Sin embargo, esto no significa que un usuario cuya password vigente no
cumple con las nuevas reglas esté forzado a cambiarla de inmediato. Solo cuando cambie
voluntariamente su password, o sea forzado por RACF a hacerlo por haberse excedido el tiempo
de validez, deberá establecer una nueva que cumpla con las reglas actuales.
En una base recién inicializada no hay ninguna regla establecida. Como ya indicáramos, una única regla
estableciendo passwords de 6 a 8 caracteres alfanuméricos es una opción simple y por lo general
satisfactoria.
Warning
Existe la posibilidad de informar con determinada anticipación a un usuario de TSO (en el momento del
logon), o en el log del job en el caso de un trabajo batch, que su password está próxima a vencer y
tendrá que cambiarla. La cantidad de días antes del vencimiento en que el usuario recibirá los mensajes
se establece con el parámetro WARNING. El valor especificado debe estar comprendido entre 1 y 255.
En la práctica, no resulta una opción de gran utilidad. De todos modos, ya que está disponible,
recomendamos usarla. No debe fijarse un valor superior al especificado en INTERVAL, ya que ello
provocaría mensajes de advertencia al inicio de cada sesión, lo cual sería sumamente molesto. Un valor
de 5 días resulta razonable, como tenemos en nuestro ejemplo, tal cual indica la siguiente leyenda:
PASSWORD EXPIRATION WARNING LEVEL IS 5 DAYS.

81
NOWARNING, que es la opción por defecto en una base recién inicializada, indica que no se avisará
anticipadamente a los usuarios sobre el vencimiento de su password.
5.33 - Passwords del RVARY

Sintaxis:
SETROPTS|SETR RVARYPW([SWITCH(password)] [STATUS(password)])
Opción sugerida: establecer passwords para ambos comandos (no dejar el valor default)
No analizaremos en este capítulo el comando RVARY, que merece un estudio detallado que haremos
más adelante. Tanto la función SWITCH como ACTIVE|INACTIVE del comando RVARY exigen el
ingreso de una password para ejecutarse exitosamente. Estas passwords, una para SWITCH (operando
SWITCH) y otra para STATUS (operando ACTIVE|INACTIVE) se especifican en la SETROPTS.
Naturalmente, no se muestran en el listado.
Si no se establecen estas passwords, el valor por defecto es la palabra YES. Es absolutamente
recomendable que la organización fije passwords para estos comandos, y las almacene bajo sobre en
algún lugar seguro.
En nuestro ejemplo se han establecido ambas passwords, tal cual se desprende de la siguiente leyenda
que aparece en el listado de la SETROPTS:
INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION.
INSTALLATION DEFINED RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.
En una base recién inicializada, las claves en efecto son las default, o sea YES, en ambos casos.
5.34 - Opciones de auditoría relativas a security levels y security labels

Sintaxis:
SETROPTS|SETR [SECLABELAUDIT|NOSECLABELAUDIT]
[SECLEVELAUDIT(nivel)|NOSECLEVELAUDIT]
Opciones sugeridas: NOSECLABELAUDIT y NOSECLEVELAUDIT
Ambas opciones solo cobran sentido en organizaciones que usen security levels, categories o security
labels.
SECLABELAUDIT y SECLEVELAUDIT incorporan un nivel extra de auditoría, basado en security
labels y security levels. Ambas opciones requieren el atributo AUDITOR a nivel de sistema para ser
modificadas.
Como ya hemos comentado, no consideramos necesario adoptar este nivel extra de seguridad, por lo
cual recomendamos tener estas opciones inactivas. Este es el default en una base recién inicializada, y
así se encuentran en nuestro ejemplo, como se deduce de la siguiente leyenda:
SECLEVELAUDIT IS INACTIVE
SECLABEL AUDIT IS NOT IN EFFECT
5.35 - Restricción para la creación de perfiles más específicos que perfiles existentes
Sintaxis:
SETROPTS|SETR GENERICOWNER|NOGENERICOWNER

82
GENERICOWNER limita la posibilidad de crear perfiles más específicos que otros ya existentes, en
cualquier clase de recursos generales, con excepción de la clase PROGRAM.
Si la opción GENERICOWNER está en efecto, un usuario solo puede crear un perfil más específico que
uno existente si, además de tener autoridad para definir perfiles en la clase (ver atributo CLAUTH),
cumple alguna de las siguientes condiciones:
Tiene el atributo SPECIAL a nivel de sistema.
Es el owner del perfil inmediatamente superior.
Tiene el atributo SPECIAL a nivel de un grupo que tenga al perfil inmediatamente superior
GENERICOWNER solo limita la creación de perfiles cuando existe un perfil menos específico que el
que se pretende definir. Tengamos presente que esta opción tampoco limita la creación de una
protección más específica a través de un perfil en una clase agrupadora, suponiendo que la clase en
cuestión la tenga.
A modo de ejemplo, supongamos la siguiente situación:
o El usuario JEF2574 tiene el atributo CLAUTH(OPERCMDS) y no tiene el atributo SPECIAL,
ni a nivel de sistema ni a “nivel de ningún grupo”.
o OPERA es un grupo de RACF.
o Los perfiles existentes en la clase OPERCMDS, con sus respectivos owner, están dados por la
siguiente tabla:
Perfil Owner
MVS.** OPERA
MVS.START.** JEF2574
JES2.** JEF2574
En esta situación, el usuario JEF2574 podría definir los perfiles JES2.CANCEL.** y

MVS.START.STC.**, pues en ambos casos es el owner del perfil genérico existente que más se ajusta
al perfil que está definiendo (JES2.** y MVS.START.**, respectivamente). También podría definir el
perfil RACF.**, pues no existe ningún perfil menos específico. Sin embargo, no podría definir el perfil
MVS.STOP.**, ya que no es el owner de MVS.** y tampoco tiene el atributo SPECIAL a nivel de
sistema o a nivel de un grupo que tenga al perfil MVS.** dentro de su campo de acción.
NOGENERICOWNER no establece la limitación anterior para la creación de perfiles más específicos
que otros existentes. Es la opción en efecto en una base recién inicializada, y es asimismo la vigente en
nuestro ejemplo tal como indica la leyenda:
GENERIC OWNER ONLY IS NOT IN EFFECT
5.36 - Otras opciones vinculadas a security levels y security labels

Sintaxis:
SETROPTS|SETR [COMPATMODE|NOCOMPATMODE]
[MLACTIVE[(FAILURES|WARNING)]|NOMLACTIVE]
[MLQUIET|NOMLQUIET]
[MLS[(FAILURES|WARNING)]|NOMLS]
[MLSTABLE|NOMLSTABLE]
[SECLABELCONTROL|NOSECLABELCONTROL]

83
Opciones sugeridas: NOCOMPATMODE, NOMLACTIVE, NOMLQUIET, NOMLS, NOMLSTABLE

NOSECLABELCONTROL
Estas opciones, excepto MLQUIET|NOMLQUIET, solo tienen sentido en organizaciones que usen
security labels. No vamos a analizar su significado en esta guía, ya que no nos ocupamos de analizar
este nivel extra de seguridad.
La opción MLQUIET, mientras se encuentra vigente, permite únicamente a las started task, los
operadores de consola y los usuarios con atributo SPECIAL loguearse, ejecutar jobs o acceder a
recursos protegidos. Es una opción que reduce al mínimo la actividad, y solo tendría sentido para alguna
tarea específica de mantenimiento. En cualquier caso, es extremadamente raro que deba recurrirse a
ella. NOMLQUIET no establece las citadas restricciones.
En una base recién inicializada, todas estas opciones están en NO, al igual que en nuestro ejemplo, tal
cual se ve en las siguientes leyendas del listado de la SETROPTS:
SECLABEL CONTROL IS NOT IN EFFECT
(...)
COMPATIBILITY MODE IS NOT IN EFFECT
MULTI-LEVEL QUIET IS NOT IN EFFECT
MULTI-LEVEL STABLE IS NOT IN EFFECT
NO WRITE-DOWN IS NOT IN EFFECT
MULTI-LEVEL ACTIVE IS NOT IN EFFECT
5.37 - Acceso a datasets no catalogados

Sintaxis:
SETROPTS|SETR CATDSNS(FAILURES|WARNING)|NOCATDSNS
Opción sugerida: CATDSNS(FAILURES)
Se trata de una opción importante que determina cómo se comportará RACF cuando se intente acceder
a archivos “no catalogados”. Este seteo afecta igualmente a datasets no catalogados residentes en
cartucho, si se habilitó para ellos el control en la clase DATASET mediante la apropiada configuración
el miembro DEVSUPxx de la PARMLIB.
CATDSNS en FAILURES indica que RACF no permitirá acceder a archivos que no se encuentren
catalogados (o temporarios generados por el sistema). Con esta configuración, estos datasets resultan
inaccesibles, salvo en alguna de las situaciones siguientes:
Si un job define un archivo y no lo cataloga, puede accederlo mientras dure la ejecución.
Archivos protegidos por perfiles discretos pueden ser accedidos aún cuando no estén
catalogados, siempre y cuando el perfil protector lo permita.
Para datasets no catalogados y no protegidos discretamente, se construye un recurso de nombre
ICHUNCAT.dsname, dónde dsname es el nombre del archivo (solo los 30 primeros caracteres
se consideran). RACF chequea a continuación la autoridad del usuario sobre este recurso en la
clase FACILITY, y si es READ (o superior), entonces no rechaza el acceso por “dataset no
catalogado”.
Si el usuario tiene el atributo SPECIAL a nivel de sistema, no se rechaza el acceso por “dataset
no catalogado”, pero se envía al usuario (y al SYSLOG) un mensaje informando que el archivo
no está catalogado. Se graba asimismo un registro de SMF reflejando el evento.
Si el acceso lo solicita una started task definida como TRUSTED o PRIVILEGED, entonces no
se rechaza el requerimiento por “dataset no catalogado”.
En los casos mencionados, la condición de “no catalogado” del archivo no impide el acceso, pero el
usuario debe de todos modos tener acceso al dataset a través de los canales habituales.

84
En nuestro ejemplo, la opción en efecto es CATDSNS(FAILURES), tal cual se desprende de la

siguiente leyenda:
CATALOGUED DATA SETS ONLY, IS IN EFFECT. CURRENT OPTIONS:
CATDSNS FAIL OPTION IS IN EFFECT
CATDSNS en WARNING funciona de manera similar al modo FAILURES, pero con una diferencia
fundamental: RACF, en lugar de rechazar el pedido por “dataset no catalogado”, continúa con su
chequeo habitual pero envía, tanto al usuario como al SYSLOG, un mensaje informando que el archivo
no se encuentra en catálogo. Se graba asimismo un registro de SMF reflejando el evento. Esta opción
resulta útil en las etapas iniciales de la construcción de un sistema, ya que permite identificar los
archivos en uso que no se encuentran catalogados, sin causar interrupciones en las tareas por problemas
de falta de autoridad. Luego de un tiempo prudencial, se sugiere cambiar al modo FAILURES.
NOCATDSNS establece que RACF no rechazará el acceso a un archivo por no estar catalogado. Esta es
la opción vigente en una base recién inicializada.
5.38 - Máximo global y default para la validez de la clave de una sesión

Sintaxis:
SETROPTS|SETR SESSIONINTERVAL(n)|NOSESSIONINTERVAL
SESSIONINTERVAL(n) establece el máximo valor para el operando INTERVAL, medido en días, que
se puede especificar en el segmento SESSION en un perfil de la clase APPCLU. Este valor resulta
también el defecto cuando se define un nuevo perfil en esta clase con segmento SESSION pero no se
codifica INTERVAL. El valor n debe estar comprendido entre 1 y 32767 inclusive.
En una base recién inicializada, el valor por defecto es 30, que es asimismo el vigente en nuestro
ejemplo, lo cual se desprende de la siguiente leyenda:
PARTNER LU-VERIFICATION SESSIONKEY INTERVAL MAXIMUM/DEFAULT IS 30 DAYS.
La opción NOSESSIONINTERVAL no establece ningún máximo global.
5.39 - Auditoría de transacciones APPC

Sintaxis:
SETROPTS|SETR APPLAUDIT|NOAPPLAUDIT
APPLAUDIT habilita globalmente la auditoría para transacciones APPC (registra inicio y fin). Sin
embargo, para que efectivamente se grabe esta información, debe auditarse el correspondiente perfil de
la clase APPL.
NOAPPLAUDIT inhabilita globalmente este tipo de auditoría. Con esta opción en efecto no se graba la
información correspondiente aún cuando el perfil en la clase APPL esté debidamente auditado. Esta es
la opción por defecto en una base recién inicializada, y es asimismo la vigente en nuestro ejemplo,
como muestra la leyenda:
APPLAUDIT IS NOT IN EFFECT

85
5.40 - Opción ADDCREATOR

Sintaxis:
SETROPTS|SETR ADDCREATOR|NOADDCREATOR
Opción sugerida: NOADDCREATOR
La opción ADDCREATOR establece que toda vez que un usuario defina un perfil de dataset o de
recursos generales automáticamente se agregará su identificador en la lista de acceso estándar con nivel
de autoridad ALTER.
En la práctica, más que una ventaja resulta una molestia, ya que es sumamente frecuente que el creador
del perfil no necesite acceso a los recursos que protege. Por lo tanto, recomendamos la opción
NOADDCREATOR, que no coloca automáticamente al usuario creador del perfil en la lista de acceso.
En una base recién inicializada, la opción en efecto es NOADDCREATOR. En nuestro ejemplo, esta es
la opción elegida, como se ve en la leyenda:
ADDCREATOR IS NOT IN EFFECT
5.41 - Lenguaje
Sintaxis:
SETROPTS|SETR LANGUAJE([PRIMARY(lenguaje)] [SECONDARY(lenguaje)])
Opción sugerida: ENU para ambos
A nivel de la SETROPTS, pueden establecerse los lenguajes globales que usará el sistema (uno
primario y otro secundario, que pueden coincidir o ser diferentes). Naturalmente, solo pueden
especificarse lenguajes que estén disponibles en la instalación, para lo cual debe consultarse a los
responsables del sistema operativo.
El valor por defecto para ambos lenguajes, en una base recién inicializada, viene identificado por la
sigla ENU, que significa inglés americano. Esta es la opción vigente en nuestro ejemplo, tal cual
muestra la leyenda:
PRIMARY LANGUAGE DEFAULT : ENU
SECONDARY LANGUAGE DEFAULT : ENU
5.42 - Comandos de REFRESH

Los comandos de RACF que definen, modifican o borran perfiles, actúan directamente sobre la base
RACF (residente en disco). Sin embargo, con el propósito de optimizar la performance, reduciendo lo
más posible la cantidad de operaciones de I/O sobre la base –muy costosas–, en muchos casos RACF
carga información en memoria virtual y la reutiliza tantas veces como le sea requerida, evitando
extraerla nuevamente de la base. Esto mejora sensiblemente el tiempo de respuesta, ya que es
muchísimo más rápido el acceso a memoria que a disco. Ahora bien, como contrapartida, toda vez que
se modifique información de un perfil que RACF mantiene en memoria, será necesario una
actualización. Esta operación, conocida como REFRESH (refrescamiento), se logra ejecutando el
comando SETROPTS con los operandos adecuados. No existe un único comando de REFRESH, ya que
el mismo varía de acuerdo al tipo de información a actualizar y a las características de la clase a la que
pertenecen los perfiles.
Clases RACLISTeadas
Una clase puede estar RACLISTeada mediante alguna de las siguientes maneras:

86
• A través del comando “SETROPTS RACLIST(clase)”, en cuyo caso aparece bajo RACLIST en
el listado de la SETROPTS.
• Por una aplicación, en cuyo caso aparece bajo “GLOBAL=YES RACLIST ONLY” en el listado
de la SETROPTS.
En ambos casos, RACF carga en un data space en memoria la información de todos los perfiles
(discretos y genéricos) de la clase. La información de este data space es consultada toda vez que una
aplicación requiera que RACF resuelva una solicitud de acceso que involucre a esta clase.
Si la clase RACLISTeada tiene una clase agrupadora, RACF realiza una operación de merge cuando
carga en memoria los perfiles, con el objeto de combinar adecuadamente la información de ambas
clases –la de miembros y la agrupadora–. En estos casos, por lo tanto, la información en el data space
es una versión procesada de los perfiles existentes en la base.
Toda modificación que se efectúe sobre perfiles (discretos o genéricos) de una clase RACLISTeada, o
sobre aquellos de su eventual clase agrupadora, solo tomarán efecto una vez que se haya refrescado la
información del data space, para lo cual es necesario ejecutar el comando:
SETROPTS RACLIST(clase) REFRESH
La clase especificada no debe ser una clase agrupadora. Si se modificó información de perfiles de una
clase agrupadora (y la clase de miembros asociada se encuentra RACLISTeada), el comando de
REFRESH debe ejecutarse siempre sobre la clase de miembros.
Este comando genera un nuevo data space. Hasta tanto concluya su creación, las aplicaciones seguirán
usando la información del antiguo. Una vez que el comando se complete exitosamente, las distintas
aplicaciones empezarán inmediatamente a apuntar al nuevo data space, y el antiguo es borrado.
Es importante destacar que no solo se refresca la información de los perfiles de la clase especificada,
sino también de todas aquellas otras clases que eventualmente compartan el mismo posit value.
Autoridad requerida
Para ejecutar el comando anterior sobre una determinada clase, el usuario debe satisfacer alguna de las
siguientes condiciones:
Tener el atributo SPECIAL a nivel de sistema
Tener el atributo AUDITOR a nivel de sistema
Tener CLAUTH sobre la clase
Clases no RACLISTeadas que tienen perfiles genéricos

Si una clase no se encuentra RACLISTeada, pero tiene perfiles genéricos definidos, estos se cargan en
memoria cuando son referenciados (en un espacio común, en algunos casos, o en cada address space, en
otros). Por lo tanto, una modificación efectuada sobre un perfil genérico de la clase puede no tomar
efecto inmediatamente (si el address space que lo requiere tiene, por ejemplo, información del perfil
cargada en su propia memoria). En tal caso, para actualizar la información existente debe ejecutarse el
comando:
SETROPTS GENERIC(clase) REFRESH
Este comando no solo refresca la información de los perfiles genéricos de la clase especificada sino
también los de aquellas otras que eventualmente compartan el mismo posit value.
Autoridad requerida
Para poder ejecutar el comando anterior sobre una determinada clase, el usuario debe satisfacer alguna
de las siguientes condiciones:

87
Tener el atributo SPECIAL, AUDITOR u OPERATIONS, ya sea a nivel de sistema o a nivel de

grupo.
Tener CLAUTH sobre la clase.
Observación:
Para una clase no GENLISTeada, el comando “SETROPTS GENERIC(clase) REFRESH” se ejecuta
casi instantáneamente. Esto se debe a que RACF simplemente modifica un contador, residente en
memoria y específico de la clase. Sin embargo, su efecto concreto es el de invalidar todas las copias de
perfiles genéricos de la clase que puedan existir en los distintos address space. En efecto, éstos saben
qué valor tenía el contador la última vez que se cargaron en su memoria de perfiles de la clase y, antes
de reusarlos, verifican que el contador no haya cambiado. Si lo hizo, los perfiles son invalidados y será
necesario volver a cargarlos. En consecuencia, se trata de un comando de ejecución inmediata pero que
puede resultar costoso en términos de procesamiento, si muchos address space tienen almacenados
perfiles de la clase.
Un ejemplo típico es la clase DATASET. El comando “SETROPTS GENERIC(DATASET)
REFRESH” finaliza inmediatamente, pero su impacto negativo en la performance puede ser importante.
Si un usuario de TSO reporta que intentó acceder a un dataset y no pudo por falta de autoridad, en caso
de que se le otorgue la autorización, será normalmente preferible pedirle que vuelva iniciar sesión antes
que ejecutar el comando de REFRESH.
Clase GLOBAL
La información de las tablas de la clase GLOBAL se encuentra siempre cargada en memoria. Toda
modificación, para tomar efecto, requiere la ejecución de un comando de REFRESH. Si se tiene una
clase bajo GLOBAL en la SETROPTS, y se modifica información de la correspondiente tabla, los
cambios solo quedarán vigentes si se ejecuta el comando:
SETROPTS GLOBAL(clase) REFRESH
Este comando no solo afecta la clase especificada sino también a todas aquellas otras que eventualmente
compartan el mismo posit value (y estén bajo GLOBAL en la SETROPTS)
Autoridad requerida
Para ejecutar el comando anterior sobre una clase, el usuario debe satisfacer alguna de las siguientes
condiciones:
Tener CLAUTH sobre la clase.
Clase PROGRAM
La clase PROGRAM es muy particular en varios aspectos, y la forma de refrescarla es uno de ellos. Si
se efectúan modificaciones en sus perfiles, los cambios solo tomarán efecto una vez que se haya
ejecutado el comando:
SETROPTS WHEN(PROGRAM) REFRESH
Autoridad requerida
Para ejecutar el comando anterior, el usuario debe satisfacer alguna de las siguientes condiciones:
Tener CLAUTH en la clase PROGRAM.

88
6 - PROTECCIÓN DE RECURSOS GENERALES
6.1 - Recursos generales y perfiles

Todos los recursos que no sean archivos son considerados recursos generales, y su protección se
establece a través de perfiles en clases de recursos generales. Todas las clases, provistas por IBM o
definidas por la organización, con excepción de USER, GROUP y DATASET, son consideradas clases
de recursos generales.
No debe confundirse un “recurso general” con un “perfil de recursos generales”, del mismo modo que
no debe confundirse un dataset con un perfil de dataset..
El nombre de un recurso general lo establece la aplicación o subsistema correspondiente, y simboliza un
objeto -tangible o intangible- de muy variada naturaleza. Posibles ejemplos son: discos; comandos de
operador; procedimientos de logon a TSO o la facilidad de acceder a cierto archivo no catalogado. La
aplicación, al derivar a RACF el requerimiento de chequeo de autoridad, debe informar a qué clase de
recursos generales (definida en la CDT) pertenece el recurso.
Un perfil de recursos generales, en cambio, es una entidad que existe únicamente en la base de RACF.
Se crea, modifica o borra a través de comandos. Es una regla usada para controlar el acceso a los
recursos propiamente dichos. Está constituido por un segmento base, también llamado “segmento de
RACF”, más eventuales segmentos no base, que varían de acuerdo a la clase a la que pertenece el perfil.
Por ejemplo, el comando de operador “START PROC1”, que inicia una started task llamada PROC1, se
asocia con el nombre de recurso MVS.START.STC.PROC1 en la clase OPERCMDS, que a su vez
podría estar protegido por el perfil genérico MVS.START.**.
Los nombres de los recursos generales son muy variados, al igual que los de los perfiles que los
protegen. Toda clase definida en la CDT tiene especificado el tipo de caracteres que admite y la
longitud máxima permitida. En cualquier caso, los nombres se componen de cadenas de caracteres
llamadas calificadores, separados por puntos (.). A diferencia de los nombres de archivos, la longitud de
un calificador puede exceder los 8 caracteres.
6.2 - Clases de miembros y agrupadoras

Ciertas clases de recursos generales vienen asociadas de a pares, siendo una de ellas la “clase de
miembros” (member class) y la otra la “clase agrupadora” (grouping class). Ambas sirven para proteger
el mismo tipo de recurso.
Un ejemplo típico son las clases TCICSTRN y GCICSTRN, utilizadas para controlar la ejecución de
transacciones CICS. TCICSTRN es la clase de miembros mientras que GCICSTRN es su
correspondiente clase agrupadora.
Los perfiles de la clase de miembros deben tener un nombre que matchee con el del recurso que
pretendan proteger. Por lo tanto, solo permiten proteger un único recurso o varios distintos pero de
nombres similares. Se admiten normalmente perfiles genéricos, suponiendo que la clase se encuentre
bajo GENERIC en la SETROPTS.
Ejemplo:
Supongamos que los perfiles definidos en la clase TCICSTRN son los siguientes:
1. ABC1
2. HYT6
3. ABC%
4. AB*
5. F*
1 y 2 son perfiles discretos, mientras que 3, 4 y 5 son perfiles genéricos.

89
Dentro de la clase de miembros, todo recurso tiene (a lo sumo) un único perfil que más se le ajusta, que
puede ser discreto o genérico. En nuestro ejemplo, para la transacción ABC1 sería el perfil discreto de
idéntico nombre, mientras que para la transacción ABFT, el perfil más ajustado sería el genérico AB*.
La transacción RY54, por otro lado, no estaría cubierta por ningún perfil de la clase TCICSTRN.
En cualquier caso, la protección de un determinado recurso surge de combinar la información
almacenada en ambas clases, la de miembros y la agrupadora, tal cual veremos a continuación.
Los perfiles en la clase agrupadora, a diferencia de lo que sucede con los de la clase de miembros,
tienen nombres de libre elección. Pero poseen una “lista de miembros” cuyos nombres deben matchear
con el nombre del recurso que pretendan proteger. En consecuencia, estos perfiles permiten proteger
recursos de nombres disímiles pero con idéntica necesidad de acceso. No se permiten perfiles genéricos,
aunque sí pueden los perfiles tener “miembros genéricos”. Un mismo miembro puede existir en varios
perfiles.
Ejemplo:
Supongamos que los perfiles definidos en la clase GCICSTRN son los siguientes:
Nombre del perfil Miembros

GRUPOA A*
SISTAB ABC1, ABC2, ABY6, AB*
SISTCONT FTR1, FTR2, FTR3, ABC1, ABC2, VGT8
Los 3 perfiles son discretos (recordemos que no están tolerados los perfiles genéricos para clases
agrupadoras). Los nombres de los perfiles -GRUPOA, SISTAB y SISTCONT- son arbitrarios y no son
chequeados por RACF contra ningún nombre de recurso. En cambio, los miembros que tienen definidos
son los que deben matchear con los nombres de los recursos.
GRUPOA tiene un único miembro, que es genérico.
SISTAB tiene 4 miembros. 3 de ellos discretos (ABC1, ABC2 y ABY6) y el restante genérico (AB*).
SISTCONT tiene 5 miembros, todos ellos discretos.
Dentro de una clase agrupadora, un recurso puede tener más de un perfil de máximo ajuste. Por
ejemplo, para la transacción ABC1, éstos serían SISTAB y SISTCONT, pues ambos tienen al miembro
discreto ABC1. Por otro lado, para la transacción ABC8, el más ajustado sería SISTAB, mientras que
para AX56 sería GRUPOA. La transacción VGT2, en cambio, no estaría protegida por ningún perfil de
la clase GCICSTRN.
Determinación de la protección de un recurso

La manera en que RACF determina la protección de un recurso en el caso de clases de miembros y
agrupadoras es relativamente compleja. Intentaremos describirla con cierto detalle, apoyándonos en los
ejemplos dados para las clases TCICSTRN y GCICSTRN.
Dado un recurso, RACF busca en principio determinar si está protegido discretamente. Para ello
examina ambas clases. En la clase de miembros, puede encontrar a lo sumo un único perfil discreto para
el recurso, mientras que en la clase agrupadora podrían existir eventualmente varios (que tengan al
recurso como miembro discreto). Si RACF efectivamente encontró al recurso protegido de manera
discreta, se pueden presentar los 2 casos siguientes:
RACF encontró un único perfil que cubre discretamente al recurso (que podría estar en la clase de
miembros o en la clase agrupadora). En este caso, este perfil es el que establece la protección del
recurso. Es el caso, en nuestro ejemplo, para las transacciones HYT6 (perfil de igual nombre en la
clase TCICSTRN) y VGT8 (perfil SISTCONT en la clase GCICSTRN).
RACF encontró más de un perfil que cubre discretamente al recurso. Es decir, halló uno en la clase
de miembros y uno o más en la clase agrupadora, o bien no encontró ninguno en la clase de

90
miembros pero encontró 2 o más en la clase agrupadora. Sería el caso, en nuestro ejemplo, de las
transacciones ABC1 (perfil de igual nombre en la clase TCICSTRN junto con perfiles SISTAB y
SISTCONT en la clase GCICSTRN) y ABC2 (perfiles SISTAB y SISTCONT en la clase
GCICSTRN). En este caso, la protección efectiva del recurso surge de combinar la información de
todos los perfiles que lo cubren discretamente, proceso conocido como merge. No describiremos en
detalle este algoritmo, pero mencionaremos los aspectos más relevantes:
Para determinar la lista de acceso del recurso, RACF combina las listas de acceso de todos los
perfiles involucrados, manejándose, en caso de repeticiones, en base al criterio del “nivel más
permisivo”. Esto significa que si un grupo (o usuario) figura en más de una de las listas de acceso,
su nivel de autorización efectivo sobre recurso será el más alto de todos.
En lo que se refiere al UACC del recurso, RACF opera de manera opuesta. El UACC efectivo será
el más restrictivo de los UACC de los perfiles involucrados.
Si RACF no encuentra al recurso cubierto de manera discreta, entonces busca en ambas clases perfiles
que lo cubran de forma genérica. En tal caso, siguiendo un criterio análogo al empleado para perfiles
genéricos de dataset, los compara hasta determinar los que más se ajustan al nombre del recurso.
Si RACF llega a establecer un único perfil que cubre genéricamente al recurso de la manera más
ajustada posible, entonces éste perfil será el protector. Es el caso, en nuestro ejemplo, de la transacción
ABC3. En efecto, si bien tanto el perfil ABC% en la clase TCICSTRN como los perfiles GRUPOA y
SISTAB en la clase GCICSTRN cubren genéricamente al recurso, el más ajustado es el perfil ABC%
(pues tanto A* como AB* son menos específicos).
Si RACF encuentra más de un perfil que cubre genéricamente al recurso de la manera más ajustada
posible, entonces la protección efectiva surge de un proceso de merge idéntico al mencionado en el caso
discreto. Este sería el caso, siempre en nuestro ejemplo, de la transacción ABX9. Tanto el perfil AB* en
la clase TCICSTRN como el perfil SISTAB en la clase GCICSTRN cubren lo más ajustadamente
posible al recurso ABX9 (GRUPOA no entra en juego ya que A* es menos específico). Por lo tanto, la
protección de la transacción ABX9 se establece combinando los perfiles AB* y SISTAB.
Finalmente, si RACF no encuentra al recurso cubierto ni discreta ni genéricamente en ninguna de ambas
clases, entonces concluye que no lo tiene protegido y devuelve a la aplicación solicitante el DFTRETC
especificado para la clase en la CDT. Tal sería el caso, en nuestro ejemplo, para la transacción MKL7.
En el caso concreto de CICS, cabe señalar que el producto deniega el acceso si la transacción no está
protegida, suponiendo que CICS esté efectivamente configurado para que se controle la ejecución de
transacciones.
Recomendaciones:
En virtud de lo expuesto, y con el objetivo de establecer una protección clara de los recursos en el caso
de clases de miembros y agrupadoras, aconsejamos lo siguiente:
No utilizar ambas clases, dentro de lo posible. Esto es, usar solo la clase de miembros o, mejor
aún, solo la clase agrupadora.
No definir el mismo recurso en más de un perfil.
No definir miembros genéricos en perfiles de la clase agrupadora. Es preferible, si fuese
necesario, crear un perfil genérico en la clase de miembros.
6.3 - Perfiles genéricos

La mayoría de las clases de recursos generales admiten perfiles genéricos. Se identifican por la
presencia de algún carácter comodín en su nombre (%, * y **), cuyo significado es similar –aunque no
exactamente idéntico- al que tienen en el caso de perfiles de dataset. No están permitidos, a diferencia
de la clase DATASET, los perfiles genéricos completos. En consecuencia, todo perfil que no contenga
en su nombre al menos un carácter genérico, resulta un perfil discreto. Recordemos que si una clase de

91
recursos generales admite perfiles genéricos, el uso del ** está permitido independientemente del seteo
de la opción EGN de la SETROPTS (que solo afecta a la clase DATASET).
Otras diferencias importantes son las siguientes:
Los perfiles genéricos de recursos generales admiten caracteres comodín en cualquier
calificador, incluso en el primero.
El * al final de un perfil indica la presencia de 0 o mas caracteres, incluyendo eventuales
“puntos”, por lo cual contempla la existencia de calificadores enteros.
Siempre que resulte posible, conviene usar perfiles genéricos, ya que una poca cantidad permite
proteger un gran número de recursos. Valen consideraciones similares a las que se hicieron respecto a
perfiles de dataset. Un abuso en la cantidad de perfiles genéricos, dónde exista casi una relación
biunívoca con los recursos, desvirtúa su naturaleza y puede ocasionar problemas de performance. Los
recursos que necesiten un tratamiento de seguridad particular deben ser protegidos mediante un perfil
discreto. En cualquier caso, a diferencia de la clase DATASET, el uso de perfiles discretos en clases de
recursos generales es muy frecuente (incluso, a veces, obligatorio) y está perfectamente justificado.
6.4 - Niveles de acceso

Los perfiles de recursos generales, como sucede con los perfiles de dataset, tienen un UACC y listas de
acceso -estándar y condicional-, dónde figuran niveles de acceso. Los posibles valores son los
siguientes:
o NONE
o EXECUTE
o READ
o UPDATE
o CONTROL
o ALTER
Están enumerados en orden jerárquico, de manera que cada nivel incluye y muchas veces excede los
privilegios del anterior. Cabe señalar que los nombres de los niveles tienen su origen en los existentes
para perfiles de dataset, dónde tienen un significado claro. Sin embargo, para perfiles de recursos
generales, debe entenderse que se trata simplemente de una escala jerárquica, dónde el alcance de cada
nivel de autoridad lo establece la aplicación correspondiente. NONE tiene obviamente un significado
claro, ya que indica que no se tiene ningún acceso al recurso. EXECUTE, por otro lado, solo es válido
para perfiles en la clase PROGRAM.
Por ejemplo, dentro de CICS, los comandos invocados vía la transacción CEMT se encuentran
protegidos en la clase CCICSCMD (o en la clase agrupadora asociada, VCICSCMD). En particular, la
autoridad para ejecutar comandos sobre terminales se chequea contra el recurso de nombre
TERMINAL. Dependiendo del tipo de comando que se ejecute, el nivel de autoridad requerido por
CICS varía. Así, para hacer un INQUIRE, el usuario debe tener READ, para hacer un SET se requiere
UPDATE y para efectuar un DISCARD se exige ALTER. Cabe indicar que estos niveles de autoridad
requeridos para cada comando los establece CICS y no RACF, que solo se limita a contestar
requerimientos que le son remitidos.
6.5 - Cómo determina RACF la protección de un recurso general

Si el recurso está asociado con una clase que tenga clase agrupadora, ya se describió el proceso que
lleva a cabo RACF para determinar su protección.

92
En caso contrario, o sea para recursos no relacionados con clases de miembros y agrupadoras, RACF
determina a lo sumo un único perfil -discreto o genérico- que protege al recurso, de manera análoga a
como lo hace en el caso de archivos. RACF procede del siguiente modo:
Si el recurso está protegido discretamente, entonces este perfil discreto será su perfil protector.
Si no está protegido discretamente, RACF busca todos los perfiles genéricos que lo alcanzan (si no
existiera ninguno, el recurso simplemente no estaría protegido) y procede a compararlos, de izquierda a
derecha. En el primer carácter en que encuentre alguna diferencia, se descartan aquellos más genéricos,
de acuerdo al siguiente criterio:
- Los caracteres “no genéricos” son más específicos que los genéricos.
- Para las genéricos, el orden, desde el menos al más genérico, es %, * y **.
6.6 - Definición de un perfil de recursos generales

Sintaxis:
RDEFINE|RDEF clase nombre-del-perfil
[DATA(‘installation-data’)] [OWNER(usuario/grupo)] [UACC(nivel)]
[WARNING] [NOTIFY(usuario)] [ADDMEM(miembro…)]
[FROM(perfil2)] [FCLASS(clase)] [FGENERIC] [FVOLUME(volumen)]
Hemos incluido únicamente los operandos más relevantes relativos al segmento base del perfil. Los
segmentos no base se verán en el análisis particular de cada clase.
La clase es un parámetro posicional requerido que debe estar inmediatamente a continuación del
comando RDEFINE.
El nombre-del-perfil es un parámetro posicional requerido que debe estar inmediatamente a
continuación de la clase. Los nombres válidos dependen de cada clase. No debe especificarse el nombre
del perfil entre apóstrofes, ya que los mismos se considerarían parte integrante del nombre (si la clase
los soportara).
La DATA es un campo de uso administrativo, de longitud máxima 255 caracteres.
El OWNER debe ser un usuario o grupo existente. Si no se codifica explícitamente, queda como
OWNER el usuario que ejecutó el comando. Recordemos que ser el dueño de un perfil no otorga acceso
a los recursos que proteja. Para poder acceder a ellos, debe agregarse al usuario en la lista de acceso a
través del comando PERMIT.
El operando UACC es sumamente importante y establece el “nivel de acceso universal” (Universal
Access) del perfil. Puede tomar los valores NONE, EXECUTE, READ, UPDATE, CONTROL y
ALTER, que ya mencionamos previamente (EXECUTE solo es válido si la clase es PROGRAM). Si se
omite, el valor por defecto es el DFTUACC que tiene la clase en la CDT o, en caso de que no lo tuviera
especificado, el UACC que tiene el usuario que ejecuta el comando en su “actual grupo de conexión”
(que, como ya señalamos, conviene que sea NONE por motivos de seguridad).
El operando WARNING establece que el perfil se define en modo warning. Esto significa que si un
usuario requiere acceso a un recurso protegido por el perfil y RACF determina que no está autorizado,
en lugar de rechazar el acceso, lo autoriza pero envía un mensaje a la terminal del usuario (y graba uno
similar en el SYSLOG) indicando que el acceso no correspondía pero fue otorgado por estar el perfil
protector en modo warning. En ciertas ocasiones, cuando aún no se logró determinar exactamente qué
usuarios deben acceder a los recursos protegidos por un perfil, puede resultar útil definirlo en modo
warning, de modo a no provocar una interrupción en alguna tarea crítica. Sin embargo, debe tenerse
presente que aquellos recursos protegidos por un perfil en warning se encuentran accesibles por
cualquier usuario con el máximo nivel de autoridad (ALTER), es decir que están básicamente sin
protección. Por lo tanto, debe usarse esta facilidad con sumo cuidado y normalmente por un período

93
corto de tiempo. Si se omite WARNING, el perfil queda definido como NOWARNING, que llamamos
modo fail. Este es el modo en que deben encontrarse normalmente todos los perfiles de la base. Las
clases PROGRAM y NODES no admiten perfiles en modo warning.
NOTIFY especifica un usuario a ser notificado cada vez que el perfil sea usado para denegar el acceso a
un recurso. Si el usuario especificado se encuentra con una sesión de TSO activa, recibirá las
notificaciones en tiempo real. En caso contrario las recibirá en el momento de su próximo logon (no se
pierden). Si la cantidad de notificaciones esperadas es elevada, el usuario debería loguearse
frecuentemente a TSO afín de liberar el espacio que ocupan sus mensajes pendientes en el archivo
SYS1.BRODCAST. De todos modos, no es conveniente tener en forma permanente un usuario en el
NOTIFY de un perfil, si se supone que rechazará gran cantidad de accesos. NOTIFY no admite más de
un usuario ni un grupo de RACF. Si se lo codifica sin especificar usuario, queda como usuario a ser
notificado quien ejecutó el comando RDEFINE. Si se lo omite, ningún usuario será notificado y el
campo muestra, en la salida del comando RLIST, la leyenda “NO USER TO BE NOTIFIED”.
Con el operando ADDMEM se agregan miembros al perfil, siempre y cuando se trate de una clase
cuyos perfiles los admitan (clases agrupadoras o GLOBAL y PROGRAM, por ejemplo). El significado
y formato de estos miembros varía según la clase.
El operando AUDIT indica a qué nivel se quiere auditar el uso del perfil. La información se graba en
registros tipo 80 del SMF. Se distinguen 2 conceptos diferentes: tipo de acceso y nivel de acceso.
Los posibles tipos de acceso son:
o NONE ningún intento de acceso será grabado.
o SUCCESS se grabarán accesos exitosos.
o FAILURES se grabarán intentos de acceso fallidos.
o ALL se grabará todo intento de acceso, sea fallido o exitoso.
Los posibles niveles de acceso son:
o READ
o UPDATE
o CONTROL
o ALTER
En el operando AUDIT se pueden especificar uno (o más) tipos de acceso acompañados del nivel de
acceso correspondiente. Naturalmente, NONE no requiere un nivel de acceso asociado.
FAILURES(READ) es el valor por defecto, y establece que se registre todo intento de acceso denegado
por el perfil. Intentos de acceso superiores a READ que resulten fallidos son también registrados.
El operando FROM especifica el nombre de un perfil (discreto o genérico) en el cual se va a basar
RACF para la creación del nuevo. Todas las características del perfil especificado en el operando
FROM son replicadas en el nuevo (OWNER, UACC, WARNING, AUDITING, NOTIFY, DATA,
Listas de acceso, etc.), excepto que se codifique explícitamente un valor distinto para alguno de estos
operandos en el comando RDEFINE. Si el perfil modelo tiene miembros, éstos no son copiados al
nuevo perfil. En cuanto a las listas de acceso, puede existir una mínima diferencia en las del nuevo
perfil con respecto al tomado como modelo, en el caso siguiente:
Si la opción ADDCREATOR está activa en la SETROPTS, el usuario que crea el nuevo perfil se agrega
a la lista de acceso estándar con autoridad ALTER, independientemente de que figure o no en la lista de
acceso del perfil modelo.
FCLASS indica la clase de RACF a la que pertenece el perfil especificado en el operando FROM
(DATASET o cualquier clase definida en la CDT son admisibles). Si se omite, RACF asume que el
perfil modelo pertenece a la misma clase que el que se está definiendo.

94
contenga caracteres genéricos. Sólo es necesario si FCLASS es DATASET y perfil2 es un “genérico
completo”. RACF ignora el operando FGENERIC si no se codificó FROM.
el volumen correspondiente del perfil modelo. Si se codifica FVOLUME con un valor distinto al que
corresponde, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se
Autoridad requerida
La autoridad requerida depende de varios factores, como ser:
o Clase a la que pertenece el perfil
o Operandos especificados en el comando RDEFINE
o Seteo de la opción GENERICOWNER de la SETROPTS
No vamos a efectuar un análisis detallado y exhaustivo de todas las situaciones que se pueden presentar.
A grandes rasgos, digamos que los usuarios autorizados a definir nuevos perfiles son aquellos con el
atributo SPECIAL o con CLAUTH sobre la clase.
6.7 - Modificación de un perfil de recursos generales

Sintaxis:
RALTER|RALT clase nombre-del-perfil
[DATA(‘installation-data’)|NODATA] [OWNER(usuario/grupo)] [UACC(nivel)]
[WARNING|NOWARNING] [NOTIFY(usuario)|NONOTIFY]
[{ADDMEM|DELMEM}(miembro)]
Naturalmente, como sucede con todos los comandos de modificación de perfiles, solo es necesario
codificar los operandos a modificar. Aquellos no especificados mantienen sus valores previos (no se
cambian a valores por defecto).
Con el operando DELMEM se borra un miembro del perfil. Si se codifican ambos operandos
-ADDMEM y DELMEM- en el mismo comando, solo se procesa el especificado en último término.
Autoridad requerida
Para modificar un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir
alguno de los siguientes requisitos:
Para ciertos operandos, como ADDMEM, existen restricciones adicionales, pero no entraremos en
detalle sobre las mismas.
6.8 - Eliminación de un perfil de recursos generales

Sintaxis:
RDELETE|RDEL clase nombre-del-perfil

95
Autoridad requerida
Para deletear un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir
6.9 - Listado de un perfil de recursos generales

Sintaxis:
RLIST|RL clase nombre-del-perfil|*
[GENERIC|NOGENERIC] [AUTHUSER] [ALL] [RESGROUP]
Si se codifica * luego de clase, se listarán todos los perfiles de la clase que el usuario esté autorizado a
ver. En caso de existir el perfil genérico *, no hay manera de listarlo individualmente. Por lo tanto, si se
quiere definir un “perfil abarcativo” (backstop profile) en la clase (o sea, un perfil que proteja a todos
los recursos que no se encuentren protegidos por uno más específico), es preferible crear el perfil ** en
lugar de * pues, a diferencia de este último, sí es factible listarlo por separado con el comando “RLIST
clase **”.
Si se codifica el operando GENERIC, la información listada dependerá de lo que se especifique como
nombre de recurso, de acuerdo al siguiente criterio:
o Si nombre-del-perfil no contiene ningún caracter genérico, RACF listará el perfil genérico que
más se ajuste al nombre de recurso especificado. Sin embargo, si existiese un perfil discreto, no
se mostrará (y, sin embargo, resulta ser efectivamente el perfil protector).
o Si nombre-del-perfil contiene algún carácter comodín, entonces RACF listará únicamente el
perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario,
informa sencillamente que el perfil requerido no existe.
o Si en lugar de nombre-del-perfil se codificó *, serán listados todos los perfiles genéricos de la
clase.
NOGENERIC indica que se debe listar el perfil discreto que coincida con el nombre especificado. Si tal
perfil no existiese, RACF lo informa. Si en lugar de nombre-del-perfil se codificó *, serán listados todos
los perfiles discretos de la clase.
Si no se codifica GENERIC o NOGENERIC, la información listada dependerá de lo que se especifique
como nombre de recurso, de acuerdo al siguiente criterio:
o Si nombre-del-perfil no contiene ningún caracter genérico, RACF listará el perfil protector del
recurso, que podrá ser discreto o genérico.
o Si nombre-del-perfil contiene algún carácter comodín, entonces RACF listará únicamente el
perfil que coincida exactamente con el nombre especificado, si existiese. En caso contrario,
informa sencillamente que el perfil no existe.
o Si en lugar de nombre-del-perfil se codificó *, serán listados todos los perfiles (discretos y
genéricos) de la clase.
AUTHUSER indica que se debe incluir en la salida del comando la siguiente información:
o Security level, categories y security label
o Lista de acceso estándar
o Lista de acceso condicional

96
ALL establece que se liste toda la información del segmento base. Si no se especifica, el listado no
muestra ni las estadísticas ni las listas de acceso. Para listar los eventuales segmentos no base, debe
especificarse el parámetro correspondiente.
Si la clase tiene una clase agrupadora, RESGROUP indica que se genere una lista de todos los perfiles
de la clase que tengan al recurso especificado dentro de sus miembros. En caso contrario, el operando
RESGROUP es ignorado.
Autoridad requerida
Para listar un perfil de recursos generales, quien ejecuta el comando debe, básicamente, cumplir con
Tener autoridad READ (o superior) sobre el perfil.
Existir una entrada en la GLOBAL para el perfil que otorgue autoridad READ (o superior).
Para que se liste el campo GLOBALAUDIT, quien ejecuta el comando debe tener el atributo
AUDITOR (ya sea a nivel de sistema, o a nivel de un grupo que tenga al perfil dentro de su campo de
acción).
Para ver las listas de acceso, se debe satisfacer alguna de las siguientes condiciones:
de su campo de acción.
Existir una entrada en la GLOBAL para el perfil que otorgue autoridad ALTER.
6.10 - Permisos sobre perfiles de recursos generales

Las listas de acceso de perfiles de recursos generales, tanto la estándar como la condicional, se
modifican a través del comando PERMIT. Para ciertas clases, las listas de acceso son irrelevantes
(STARTED o GLOBAL, por ejemplo), aunque debe tenerse siempre presente que el nivel de autoridad
ALTER, sobre un perfil discreto, confiere autoridad administrativa (generalmente no deseada).
Sintaxis:
PERMIT|PE ‘nombre-del-perfil’ CLASS(clase)
[ID({usuario/grupo...|*})] ACCESS(nivel)|DELETE]
[FROM(‘perfil2’)] [FCLASS] [FGENERIC] [FVOLUME(volumen)]
[RESET(ALL|STANDARD|WHEN)]
[WHEN([APPCPORT({partner-luname|*})] [CONSOLE({consola|*})]
[JESINPUT({nombre-input-device|*})] [PROGRAM({programa|*})] [SYSID({sysid|*})]
[TERMINAL({terminal|*})])]
El nombre-del-perfil es requerido y debe estar inmediatamente a continuación del comando PERMIT.
CLASS indica la clase a la que pertenece el perfil. Como ya hemos visto, el valor por defecto es
DATASET, por lo cual debe codificarse obligatoriamente para una clase de recursos generales.

97
ID indica el usuario o grupo cuya entrada en la lista de acceso se desea agregar, modificar o eliminar.
Separados por espacios pueden ingresarse más de un usuario/grupo. También se acepta el valor *, que
representa un usuario cualquiera existente en la base de RACF.
ACCESS establece el nivel de autoridad que se quiere otorgar al usuario/grupo especificado en el
operando ID. Los posibles valores son NONE, EXECUTE, READ, UPDATE, CONTROL y ALTER.
Si se codifica ACCESS sin poner ningún valor, se asume READ.
DELETE indica que se pretende borrar de la lista de acceso la entrada correspondiente al usuario/grupo
codificado en el operando ID.
En ambos casos, ya sea con ACCESS o DELETE, RACF actúa sobre la lista de acceso estándar,
excepto que se codifique explícitamente el operando WHEN, que indica que se pretende modificar la
lista de acceso condicional. Si se especificó ID, pero se omitió tanto ACCESS como DELETE, se
asume por defecto ACCESS(READ).
FROM especifica el nombre de otro perfil (discreto o genérico) del cual se quieren copiar las listas de
acceso (estándar y condicional). Las entradas en las listas de acceso del perfil2 son agregadas a las listas
de acceso correspondientes. Es decir, el operando FROM no convierte en idénticas las listas de acceso
de ambos perfiles. Más aún, si una entrada que figura en la lista de acceso del perfil2 ya se encuentra en
la del perfil en cuestión, entonces la misma no se modifica.
FCLASS indica la clase a la que pertenece el perfil especificado en el operando FROM. Si omite
FCLASS y se codificó FROM, se asume por defecto que perfil2 pertenece a la misma clase que el perfil
en cuestión.
contenga caracteres genéricos. Por lo tanto, solo tiene sentido si perfil2 es un perfil de dataset. RACF
ignora el operando FGENERIC si no se codificó FROM.
el volumen correspondiente. Si se codificara FVOLUME con un valor distinto al que corresponde al
perfil2, o si se omite y existe más de un perfil discreto con ese nombre, el comando falla. Si no se
El operando RESET indica que se pretende vaciar una o ambas listas de acceso (es decir, eliminar todas
las entradas). RESET(STANDARD) vacía únicamente la lista de acceso estándar, en tanto que
RESET(WHEN) hace lo propio con la condicional. RESET(ALL) vacía ambas. Si se codifica RESET
sin ningún valor, se asume por defecto ALL.
El operando WHEN indica que se quiere modificar la lista de acceso condicional. No describiremos los
distintos suboperandos que admite. Si se omite WHEN, las modificaciones se efectúan sobre la lista de
acceso estándar (aunque los operandos FROM o RESET pueden impactar igualmente sobre la lista de
acceso condicional).
6.11 - Comando SEARCH

Sintaxis:
SEARCH|SR [CLASS({DATASET|clase})]
[{ALL|GENERIC|NOGENERIC|MODEL|TAPE|VSAM|NOVSAM}]
[CATEGORY(categoría)|EXPIRES(valor)|LEVEL(valor)|
SECLABEL(label)|SECLEVEL(level)|WARNING]
[FILTER(cadena)] [{MASK({cadena1|*}[,cadena2])|NOMASK}]
[USER(usuario)] [AGE(valor)] [CLIST[(‘cadena1’[‘cadena2’])]]
El comando SEARCH permite obtener una lista de los nombres de los perfiles de la base que cumplan
con determinados criterios.

98
CLASS especifica la clase dentro de la cual se buscan los perfiles. Se puede codificar DATASET,
USER, GROUP o cualquier otra clase definida en la CDT. Si se omite, el valor por defecto es
DATASET.
ALL indica que se listen todos los perfiles –genéricos o discretos- que satisfagan los demás criterios
fijados por los restantes parámetros del comando SEARCH. GENERIC restringe la búsqueda a perfiles
genéricos, mientras que NOGENERIC la limita a perfiles discretos. Las opciones
MODEL|TAPE|VSAM|NOVSAM solo tienen sentido para la clase DATASET (son directamente
ignoradas si la clase especificada es otra). El valor por defecto es ALL.
CATEGORY|EXPIRES|LEVEL|SECLABEL|SECLEVEL|WARNING
Mediante estos operandos se establecen criterios de búsqueda. No nos ocuparemos de CATEGORY,
SECLABEL y SECLEVEL.
o EXPIRES solo se aplica a la clase TAPEVOL. El valor debe estar comprendido entre 0 y 65533,
o bien ser 99999 (archivos que nunca expiran). Si se codifica, solo se listarán los volúmenes
tales que todos sus archivos, o bien ya se encuentren expirados, o bien lo harán dentro de la
cantidad de días especificados.
o LEVEL establece que se listen los perfiles cuyo LEVEL coincida con el especificado.
Recordemos que se trata de un campo de uso administrativo, cuyo valor está comprendido entre
00 y 99. Si la clase es USER o GROUP, este operando es ignorado.
o WARNING indica que se listen los perfiles que se encuentre en modo warning. Si la clase es
USER o GROUP, este operando es ignorado.
FILTER permite indicar una cadena de caracteres (incluyendo los caracteres comodín %, * y **), de
modo que sean listados únicamente los perfiles cuyos nombres estén alcanzados por el patrón
establecido. El significado de los caracteres genéricos es similar al que tienen en el caso de perfiles, y
pueden codificarse en cualquier calificador (incluso en el primero):
- % indica un único carácter cualquiera (inclusive % y *)
- * indica la presencia de 0 más caracteres (inclusive genéricos) hasta concluir el calificador. Si es
usado como un calificador completo, exige la existencia de ese calificador en los nombres que
abarca.
- ** indica la presencia de 0 o más calificadores. Sólo puede usarse como un calificador completo.
Ejemplo:
FILTER(a%%.xy*.*.**) alcanzaría a los siguientes nombres de perfiles:
a21.xyzw.asdf.qwe.fin
aa*.xyz%%%.qwe
Sin embargo, no alcanzaría a:
ab23.xyz.efgh.qwe (tiene 4 caracteres en el primer calificador)
a21.xyw* (no tiene un tercer calificador, que es exigido)
El operando MASK, excluyente con el operando FILTER, brinda un medio alternativo para filtrar
perfiles:
o Cadena1 indica una secuencia de caracteres con la que deben empezar los nombres de los
perfiles buscados. Se admiten caracteres genéricos, pero pierden su significado comodín y son
exigidos literalmente. Si se codifica * y la clase es DATASET, el identificador del usuario que
ejecuta el comando se toma como máscara.
o Cadena2 establece, opcionalmente, una segunda cadena de caracteres que debe contener el
nombre del perfil en cualquier lugar a continuación de cadena1. También en este caso se

99
admiten caracteres genéricos, pero no tienen su significado usual sino que son tomados
literalmente.
NOMASK establece que se listen todos los perfiles de la clase que cumplan con el resto de los criterios.
En realidad, solo son listados aquellos que el usuario está autorizado a ver.
Si no se codifica MASK|NOMASK (ni FILTER), entonces el defecto es MASK(*). Notemos que para
todas las clases excepto DATASET, NOMASK y MASK(*) son equivalentes, ya que no fijan
restricciones sobre los nombres de los perfiles.
El operando FILTER es más flexible que MASK, pues permite criterios de búsqueda más sofisticados.
El operando USER(usuario) indica que se deben listar los perfiles que cumplan con los criterios de
selección establecidos y sobre los cuales el usuario codificado tenga autoridad READ o superior, o bien
sea el owner. Si la clase especificada es GROUP, serán listados los grupos para los cuales el usuario
codificado esté conectado con autoridad CONNECT o JOIN, esté conectado con atributo SPECIAL o
AUDITOR, o sea el owner.
AGE establece que se listen únicamente los perfiles que no han sido referenciados dentro de la cantidad
de días especificados (contados hacia atrás desde el actual). El valor codificado debe estar comprendido
entre 0 y 99999. Esta opción funciona únicamente para perfiles discretos de clases para las cuales se
mantengan estadísticas.
Si la clase es USER, se listarán los usuarios cuyo LAST-ACCESS sea anterior a la fecha que resulte de
sustraer a la actual la cantidad de días especificados. En el caso en que LAST-ACCESS tenga el valor
UNKNOWN, se toma la fecha de creación del usuario como referencia.
Si la clase es GROUP, se listarán los grupos que hayan sido creados con anterioridad a la fecha que
resulte de sustraer a la actual la cantidad de días especificados.
El operando CLIST determina que se genere una CLIST (command list) con los nombres de los perfiles
que resulten de la búsqueda (1 registro por cada perfil encontrado). La lista se graba en un archivo de
nombre PREFIX.EXEC.RACF.CLIST, dónde PREFIX indica el prefix de TSO del usuario que ejecuta
el comando SEARCH (si tuviera noprefix en su profile de TSO, su identificador de usuario se usaría
como HLQ del dataset). Es importante recalcar que el comando solo genera la CLIST. No la ejecuta.
o Cadena1, que debe codificarse entre apóstrofes simples, establece el texto que se antepondrá en
cada registro al nombre del perfil.
o Cadena2, que debe estar igualmente entre apóstrofes simples, establece el texto que se agregará
en cada registro inmediatamente a continuación del nombre del perfil.
Adicionalmente, un número de secuencia de 8 posiciones es colocado al principio de cada registro. El
operando CLIST es útil cuando se quiere ejecutar idénticos comandos de RACF sobre los perfiles que
resulten de la búsqueda.
Ejemplo:
Supongamos que se pretende listar la información completa de todos los perfiles de la clase FACILITY
cuyo nombre empiece con la cadena de caracteres STGADMIN. Para ello, debería ejecutarse el
comando:
SEARCH CLASS(facility) MASK(stgadmin) CLIST(‘rlist facility ’‘ all’)
Intencionalmente se han especificado espacios al final de cadena1 y al principio de cadena2, de modo
que los comandos resulten sintácticamente correctos. El archivo grabado podría tener los siguientes
registros:
00000010RLIST FACILITY STGADMIN.ADR.** ALL
00000020RLIST FACILITY STGADMIN.IDC.** ALL
00000030RLIST FACILITY STGADMIN.IGG.** ALL
00000040RLIST FACILITY STGADMIN.** ALL

100
Luego, bastaría ejecutarlos a través del comando EXEC de TSO.
Autoridad requerida
Todo usuario está autorizado a ejecutar el comando SEARCH, solo que únicamente le serán mostrados
los nombres de los perfiles que este autorizado a ver. Básicamente, para poder ver el nombre de un
perfil, quien ejecuta el comando debe cumplir con alguna de las condiciones siguientes:
Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al
perfil dentro de su campo de acción.
Tener el atributo OPERATIONS a nivel de sistema o a nivel de un grupo que tenga al perfil
dentro de su campo de acción y la clase estar alcanzada por este atributo.
Tener autoridad READ (o superior) sobre el perfil.
Para poder usar SEARCH con el operando USER, quien ejecuta el comando debe cumplir con alguna
de las condiciones siguientes:
Tener el atributo SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al
usuario del operando USER dentro de su campo de acción.
Ser el owner del usuario codificado en el operando USER
El usuario codificado en el operando USER debe coincidir con el propio.

101
7 - CLASES PARTICULARES

Existe una gran cantidad de clases de recursos generales, que permiten proteger recursos de muy
variada naturaleza. Como ya comentáramos, una organización puede normalmente manejar
satisfactoriamente su seguridad activando solo una cantidad limitada de ellas. Un administrador de
RACF debe conocer perfectamente el funcionamiento y alcance de las clases que se utilizan
efectivamente en su organización. Algunas de estas clases están descriptas en detalle en la bibliografía
de RACF, mientras que otras son tratadas en profundidad en la documentación del producto que las
utiliza.
Analizaremos a continuación algunas clases de recursos generales que consideramos particularmente
importantes y cuyo uso es muy frecuente.
7.2 - Clase GLOBAL

Podemos imaginar a la “tabla de acceso global”, que abreviaremos GAC (Global Access Checking
Table), como una tabla que contiene una lista de “recursos” asociados con un determinado “nivel de
acceso”. La GAC permite autorizar el acceso a un recurso a cualquier usuario (con excepción
únicamente de aquellos con el atributo RESTRICTED), sin que RACF analice el perfil protector. En
efecto, durante el proceso de chequeo de autorización que lleva a cabo RACF, que estudiaremos en
forma precisa en un capítulo posterior, la GAC se consulta en primera instancia. Si la información que
contiene indica que el acceso debe otorgarse, RACF responde favorablemente sin continuar con el
chequeo habitual de perfiles. Es importante recalcar que la GAC puede autorizar un requerimiento de
acceso, pero nunca rechazarlo. Si no contiene información que autorice el requerimiento, RACF
continúa con su chequeo habitual. Por lo tanto, la GAC solo puede utilizarse para responder
favorablemente solicitudes de acceso.
Únicamente actúa la GAC para aquellas clases que tienen GLOBAL especificado en la SETROPTS. Por
lo tanto, si se pretende definir reglas en la GAC para una determinada clase, debe activarse su chequeo
de la GLOBAL, ejecutando el comando:
SETROPTS GLOBAL(clase)
Recordemos que la clase especificada no puede ser una clase agrupadora.
Construcción y mantenimiento de la GAC

GLOBAL es, en realidad, una clase de RACF. Para definir reglas en la GAC para una determinada
clase, debe definirse en principio un perfil en la clase GLOBAL cuyo nombre coincida con el de la
clase. Las reglas se definen luego como miembros del perfil, a través del operando ADDMEM. Las
reglas se componen de un “nombre de recurso” acompañado del correspondiente nivel de acceso. El
“nombre de recurso” debe seguir los mismos lineamientos que los perfiles de la clase, con las siguientes
importantes flexibilidades adicionales:
o Si la clase en cuestión tiene GENCMD especificado en la SETROPTS, los caracteres genéricos
pueden usarse en cualquier calificador, incluso el primero.
o Los nombres de recurso pueden contener las variables &RACUID y &RACGPID como
calificadores. &RACUID se reemplaza por el usuario actual mientras que la variable
&RACGPID indica su “actual grupo de conexión”.
o Los nombres de recurso pueden incluir variables definidas en la clase RACFVARS.
El nivel de acceso puede ser NONE, READ, UPDATE, CONTROL o ALTER (EXECUTE no está
permitido en la GAC).
Los siguientes comandos muestran como incorporar una regla en la GAC para una determinada clase:

102
RDEFINE GLOBAL clase

RALTER GLOBAL clase ADDMEM(‘nombre-del-recurso’/nivel de acceso)
Para borrar una regla existente, el comando sería:
RALTER GLOBAL clase DELMEM(‘nombre-del-recurso’/nivel-de-acceso)
Debe tenerse cuidado, ya que si en lugar de RALTER se especifica RDELETE, el comando no solo
borraría la regla en cuestión sino que deletearía el perfil, con lo cual se eliminarían todas las reglas de la
GAC para la clase.
En cualquier caso, luego de efectuar una modificación en la GAC para cierta clase, la misma solo entra
en vigencia luego de ejecutar el siguiente comando de refresh:
SETROPTS GLOBAL(clase) REFRESH
Ejemplo:
Vamos a mostrar una secuencia de comandos que define una serie de reglas en la GAC para la clase
DATASET. En este ejemplo, se pretende que todos los archivos cuyo HLQ es SYS1 sean accedidos por
todos los usuarios con autoridad READ, con excepción del dataset SYS1.UADS. Asimismo, se pretende
otorgar UPDATE a todos los usuarios a los catálogos de usuario, cuyos nombres suponemos tienen
HLQ igual a USRCAT (y son los únicos con este HLQ). Asumimos que en la SETROPTS la clase
DATASET está bajo GENCMD y que la opción EGN está activa. Asimismo, suponemos que no existe
el perfil DATASET en la clase GLOBAL y que la misma no está bajo GLOBAL en la SETROPTS.
1) SETROPTS GLOBAL(dataset)
2) RDEFINE GLOBAL DATASET
3) RALTER GLOBAL DATASET ADDMEM(‘sys1.**’/read)
4) RALTER GLOBAL DATASET ADDMEM(‘sys1.uads’/none)
5) RALTER GLOBAL DATASET ADDMEM(‘usrcat.**’/update)
6) SETROPTS GLOBAL(dataset) REFRESH
Cuando RACF analiza el contenido de la GAC para resolver sobre una solicitud de acceso, procede de
manera similar a como lo hace con perfiles. Esto es, RACF detecta la entrada que mas se ajusta al
recurso solicitado y en base a ella decide si debe otorgar el acceso inmediatamente, o bien debe seguir
con el proceso de chequeo habitual. En nuestro ejemplo, si un usuario intenta leer el archivo
SYS1.UADS, RACF consulta las reglas para la clase DATASET en la GAC (ya que DATASET está
bajo GLOBAL en la SETROPTS), y encuentra que la entrada que más se ajusta es SYS1.UADS, cuyo
nivel de acceso asociado es NONE. Por lo tanto, la GAC no permite otorgar el acceso solicitado, y
RACF continúa con el análisis de los perfiles correspondientes (recordemos que la GAC nunca rechaza
por sí misma un requerimiento de acceso).
Consideraciones:
Los usuarios con el atributo RESTRICTED son los únicos que no pueden obtener acceso a un
recurso a través de la GAC.
Aún cuando exista en la GAC una regla que permita acceder a un recurso bajo cierto nivel de
autoridad, es conveniente garantizar idéntico acceso a través del UACC del perfil protector. Esto
evita problemas si involuntariamente se borra la regla de la GAC, o se inhabilita en la
SETROPTS la opción GLOBAL para la clase. Por ejemplo, si tenemos la siguiente regla en la
GAC:
USRCAT.**/UPDATE
resulta conveniente tener asimismo un perfil de dataset ‘USRCAT.**’ con UACC(UPDATE).

103
Para ciertas aplicaciones que utilizan la macro RACROUTE REQUEST=FASTAUTH, la GAC

no actúa. CICS es un ejemplo de ello.
Si el acceso a un recurso es otorgado por la GAC, RACF no actualiza las eventuales estadísticas
que pudiera tener el perfil protector. Mas aún, RACF ni siquiera determina qué perfil protege
efectivamente al recurso.
Si el acceso a un recurso es otorgado por la GAC, RACF no tendrá en cuenta el nivel de
auditoría del perfil protector (ya que dicho perfil no es ni siquiera determinado). Actúa, sin
embargo, la opción global de auditoría para la clase establecida en la SETROPTS a través del
operando LOGOPTIONS.
Una regla en la GAC con nivel de autoridad NONE solo tiene sentido si existe otra regla para la
misma clase con autoridad superior y que sea mas permisiva (ver el ejemplo anterior).
Cuando se listan las reglas existentes en la GAC para una determinada clase, con el comando
“RLIST GLOBAL clase”, las mismas se muestran ordenadas según el criterio de mayor
especificidad.
El uso de la GAC puede mejorar la performance al evitarse, en muchos casos, costosos I/O sobre
la base de RACF. Son excelentes candidatos para la GAC recursos de uso muy frecuente que
deban ser accedidos en forma universal.
7.3 - Clase STARTED

Una started task, también conocida como STC, en un procedimiento que se arranca con el comando de
operador START (o bien asociada directamente con un componente del sistema operativo, como
DFSMS). Reside en bibliotecas de procedimientos declaradas en la parametrización del JES
(SYS1.PROCLIB, por ejemplo).
Las STC, a diferencia de los trabajos batch, no tienen una tarjeta job dónde figure usuario y grupo (o
que se reciban propagados). Por lo tanto, como básicamente solo usuarios o grupos definidos en RACF
pueden acceder a recursos protegidos, es necesario que las STC tengan una identidad asignada.
Naturalmente, el usuario debe estar conectado al grupo especificado.
Si la opción GRPLIST no está activa en la SETROPTS –opción improbable en la actualidad-, entonces
solo se tendrá en cuenta el grupo especificado al momento de resolver solicitudes de acceso del usuario
a recursos protegidos. En cambio, si como recomendamos, está activa la opción GRPLIST, entonces el
grupo de conexión resulta irrelevante y el usuario tendrá acceso a los recursos a través de cualquiera de
sus grupos.
La asignación de usuario y grupo puede realizarse a través de la definición de un perfil en la clase
STARTED o mediante una entrada apropiada en una tabla assembler de nombre ICHRIN03 (Started
Procedures Tables). Si la clase STARTED está activa, RACF busca en principio un perfil en esta clase
que asigne una identidad válida al procedimiento. Si no lo encuentra, recién entonces examina la
ICHRIN03.
La ICHRIN03 es una tabla residente en la LPA (Link Pack Area) o en la MLPA (Modified Link Pack
Area). Debe compilarse y linkeditarse como si se tratara de un programa assembler, aún cuando solo
contenga definiciones de constantes y carezca de instrucciones propiamente dichas. Más aún, luego de
modificado, para que el nuevo módulo entre en vigencia es necesario dar IPL, ya que no es posible
refrescarlo dinámicamente dado el sector de memoria donde se aloja. Estos inconvenientes hacen que la
utilización de esta tabla estática de asignación sea muy poco práctica, razón por la cual IBM introdujo la
clase STARTED, que permite un manejo dinámico. De todos modos, tengamos presente que el módulo
ICHRIN03 debe existir, ya que en caso contrario RACF no inicializa. Recomendamos tener una
ICHRIN03 mínima, con entradas únicamente para ciertas started task críticas del sistema operativo.
Esto permitirá que inicie el sistema operativo ante una eventual inactivación involuntaria de la clase

104
STARTED. No entraremos en detalles en esta guía sobre la construcción de la ICHRIN03, pero

ejemplos concretos se pueden consultar en la documentación de IBM.
Recursos y perfiles de la clase STARTED

En lo que sigue, vamos a suponer que la clase STARTED está activa, RACLISTeada y que admite
perfiles genéricos. Esto se logra ejecutando el siguiente comando:
SETR CLASSACT(STARTED) RACLIST(STARTED) GENERIC(STARTED)
Con las versiones actuales del z/OS, el comando START de MVS permite startear no solo una STC
sino también un job. Para simplificar, vamos a ocuparnos exclusivamente del caso de procedimientos,
ya que es lo más frecuente.
Al arrancarse una STC, si no se especifica en el comando START un jobname distinto, se construye el
nombre de recurso miembro.miembro, dónde miembro indica el miembro de la biblioteca dónde se
encuentra el procedimiento (el nombre del procedimiento propiamente dicho, establecido en la primer
sentencia del JCL, no entra en juego). Si, por el contrario, se especificara el parámetro JOBNAME en el
comando START, el recurso correspondiente sería miembro.jobname. RACF busca entonces el perfil en
la clase STARTED (discreto o genérico) que más se ajuste a este nombre y lo usa para la asignación de
identidad.
Ejemplo:
Supongamos que se ejecuta el siguiente comando de operador:
START cnmproc
RACF, para asignar identidad al procedimiento, busca en la clase STARTED el perfil que más se ajuste
al nombre cnmproc.cnmproc, que podría ser, por ejemplo, el perfil genérico cnmproc.*.
Definición de un perfil de la clase STARTED

Sintaxis:
RDEFINE|RDEF STARTED nombre-del-perfil
[DATA(‘installation-data’)] [OWNER(usuario/grupo)]
[STDATA([USER(usuario|=MEMBER)] [GROUP(grupo|=MEMBER)]
[PRIVILEGED(NO|YES)] [TRUSTED(NO|YES)] [TRACE(NO|YES)])
Notemos que, al no tratarse de perfiles que protejan acceso a recursos, los campos UACC, AUDIT y
listas de acceso, entre otros, resultan irrelevantes. La información determinante de los perfiles de la
clase STARTED se encuentra en el segmento no base denominado STDATA, cuyos campos
describiremos a continuación
USER establece el usuario que se asociará con el procedimiento. Si el usuario codificado no existe en la
base, RACF alerta sobre la situación emitiendo un mensaje, pero la definición se realiza de todos
modos. Existe la opción de codificar el valor “=MEMBER” en lugar de un identificador de usuario, en
cuyo caso RACF asignará el usuario que coincida con el nombre del miembro -si existiera.
GROUP establece el grupo que se asociará con el procedimiento. Si el grupo codificado no existe, o si
el usuario especificado en el operando USER no se encuentra conectado a él, RACF alerta sobre la
situación enviando un mensaje, pero también aquí la definición se realiza de todos modos. Existe la
opción de codificar el valor “=MEMBER” en lugar del nombre de un grupo, en cuyo caso RACF
asignará al procedimiento el grupo que coincida con el nombre del miembro -si existiera.
PRIVILEGED=YES indica que todos los accesos que solicite el procedimiento (salvo contadísimas
excepciones, muy poco frecuentes y que no vale la pena mencionar) serán otorgados, sin efectuar el
chequeo correspondiente. Tales accesos exitosos no actualizarán estadísticas ni generarán registros de
SMF, aún cuando la configuración de auditoría lo requiera. El valor por defecto es PRIVILEGED=NO.

105
TRUSTED=YES se comporta de manera similar a PRIVILEGED=YES, con la diferencia de que sí se

generarán registros de SMF de acuerdo a la configuración de auditoría correspondiente. El valor por
defecto es TRUSTED=NO.
La mayoría de las STC no deben estar marcadas ni TRUSTED ni PRIVILEGED, tal cual es el defecto.
Deben tener un usuario asignado que tenga solo los accesos necesarios. Sin embargo, existen ciertos
procedimientos críticos del sistema operativo para los cuáles IBM recomienda estos atributos, para
evitar que una eventual falta de autorización cause serios trastornos operativos, o incluso que el sistema
no inicie o funcione correctamente. En estos casos, recomendamos usar TRUSTED en lugar de
PRIVILEGED, para contar eventualmente con alguna información de auditoría grabada en registros
SMF. Debe señalarse, de todos modos, que la posibilidad de auditar una tarea marcada TRUSTED es
bastante limitada y poco flexible. En efecto, al otorgarse los accesos sin consulta a los perfiles
protectores, las opciones de auditoría que éstos tengan configuradas no son tomadas en cuenta. Por lo
tanto, sólo se generarán registros de auditoría si el usuario tuviera el atributo UAUDIT, o si la clase a la
que pertenece el recurso estuviera auditada a nivel de la SETROPTS. En el primer caso, se grabaría
información para todos los accesos de la STC, sin posibilidad de discriminación alguna. Si, por el
contrario, se audita una clase específica, no solo se grabaría información para esta STC sino para todos
los accesos a recursos protegidos en la clase, pudiéndose generar un volumen muy grande de
información innecesaria. En definitiva, la auditoría de una STC indicada como TRUSTED, si bien
posible, suele ser problemática. JES2 es un ejemplo de un procedimiento que se aconseja ejecutar como
TRUSTED. Más adelante damos una lista de STC que IBM sugiere ejecutar como TRUSTED.
TRACE=YES indica que RACF informará, mediante un mensaje por consola, toda vez que el perfil sea
usado para la asignación de usuario. Esta opción puede resultar útil como herramienta de diagnóstico
para resolver ciertos problemas. El valor por defecto es TRACE=NO.
Para modificar, borrar o listar perfiles de la clase STARTED se utilizan los comandos habituales de
manejo de perfiles de clases de recursos generales, a saber: RALTER; RDELETE y RLIST.
Para cambiar el valor de un campo del segmento STDATA, debe codificarse el operando STDATA en
el comando RALTER especificando solo el suboperando a modificar.
Para listar la información completa de un perfil de la clase STARTED debe ejecutarse el comando
“RLIST STARTED nombre-del-perfil STDATA”. Si se omite STDATA, solo se mostrará la
información del segmento base y no se visualizará la información determinante para la asignación de
identidad.
Consideraciones:
Si una started task no adquiere una identidad válida, corre bajo un usuario indefinido, y solo
puede acceder a los recursos cuyo UACC sea lo suficientemente permisivo. Estando la clase
STARTED activa –como es absolutamente recomendable-, solo en los casos siguientes RACF
consultará la ICHRIN03:
o No existe un perfil en la clase STARTED
o Existe un perfil pero sin segmento STDATA.
o Existe un perfil con segmento STDATA pero sin usuario especificado.
En cambio, en cualquiera de los casos siguientes, no se consultará la ICHRIN03 y la STC
ejecutará con usuario indefinido:
o Existe un perfil con segmento STDATA pero el usuario especificado no existe en la base.
o Existe un perfil con segmento STDATA pero el grupo especificado no existe en la base.
o Existe un perfil con segmento STDATA, con usuario y grupo válidos, pero el usuario no está
conectado al grupo.

106
En el inicio de una STC, RACF no chequea la eventual revocación del usuario asignado. Esto
determina que el procedimiento efectivamente arrancará, aún cuando el usuario se encuentre
revocado. Sin embargo, es probable que la tarea tenga problemas posteriormente, si alguna
acción que lleve a cabo controle efectivamente esta condición (por ejemplo, si la STC submite
un job al internal reader). Por lo tanto, es aconsejable verificar regularmente que los usuarios
asociados con las STC no se encuentren revocados.
Si un usuario es utilizado exclusivamente para ser asignado a una started task, entonces es un
excelente candidato para otorgarle el atributo PROTECTED. De esta manera se evitan usos
indebidos del usuario, así como también revocaciones maliciosas por intentos de logon fallidos
ingresando passwords incorrectas.
La asignación del usuario a la STC se realiza en el momento de su inicio. En consecuencia, tanto
si se cambia el usuario asignado como si se le otorga (o quita) algún atributo, la modificación
solo tomará efecto una vez que se recicle la STC (es decir, que se pare y reinicie).
Con el objeto de mantener un adecuado control de las STC en el sistema, recomendamos definir
un perfil de contención ** en la clase STARTED, cuyo usuario asignado no tenga ninguna
autorización explícita sobre ningún perfil. De este modo, toda STC que no tenga un perfil más
específico solo podrá acceder a recursos vía UACC (o * en la lista de acceso), lo cual no debería
ser peligroso desde la perspectiva de la seguridad. Una opción aún más radical consistiría en
otorgarle a tal usuario el atributo RESTRICTED, en cuyo caso el procedimiento no podría
acceder a ningún recurso protegido. Es de destacar que estando correctamente definido este
backstop en la clase STARTED, RACF nunca revertirá a la ICHRIN03 en su proceso de
asignación de identidad.
En cualquier caso, lo realmente importante es que toda STC se encuentre perfectamente
identificada y con un usuario debidamente asignado a través de la clase STARTED, que detente
únicamente las autorizaciones necesarias para sus tareas. Asimismo, y de manera
complementaria, deben estar adecuadamente protegidas las bibliotecas de procedimientos
declaradas en JES.
La clase STARTED debe necesariamente estar RACLITeada. Sin embargo, en este caso
particular, RACF no carga en memoria toda la información de sus perfiles sino solo sus
nombres. Una vez que determina el perfil que usará para asignar identidad (operación rápida,
pues tiene los nombres en memoria virtual) hará un I/O sobre la base para extraer el segmento
STDATA correspondiente. Una consecuencia de esto es que, si solo se modifica un campo del
segmento STDATA de un perfil existente, no será normalmente necesario ejecutar el comando
de REFRESH.
IBM recomienda que los siguientes procedimientos se ejecuten como TRUSTED:
CATALOG, DUMPSRV, DFHSM, DFS, GPMSERVE, IEEVMPCR, IOSAS, IXGLOGR, JES2
o JES3, JESXCF, LLA, NFS, OMVSKERN, RACF, RMF, RMFGAT, SMSVSAM, SMF,
TCPIP, VLF, VTAM, XCFAS.
Aconsejo fuertemente seguir las recomendaciones de IBM y asignar TRUSTED siempre que se
lo sugiera.
7.4 - Clase PROGRAM

El funcionamiento de la clase PROGRAM es ciertamente complejo, y exponerlo en detalle está fuera de
los objetivos de este curso introductorio. Por ejemplo, no discutiremos en esta guía ninguno de los
siguientes temas:
Modo de protección ENHANCED. Aporta un nivel de protección mayor que el modo BASIC.
Su implementación requiere un importante esfuerzo de configuración de perfiles en la clase
PROGRAM (y sólidos conocimientos en la materia). No resulta habitualmente necesario. En la

107
primera línea del listado de la SETROPTS se visualiza claramente si el control de programas

está activo y en qué modo.
Acceso a archivos condicionado a la ejecución de determinado programa, esquema conocido
como PADS (Program Access to Data Sets).
Nivel de autoridad EXECUTE y “entorno limpio” (clean environment).
Nos limitaremos pues a exponer ciertas nociones básicas relacionadas con la clase PROGRAM que todo
administrador de RACF debe conocer.
En la gran mayoría de los casos, más que proteger un determinado medio de acceso, como es en
definitiva un programa, deberían centrarse los esfuerzos en proteger adecuadamente los recursos a los
que permite acceder. Así, por ejemplo, no tiene mayor sentido proteger el programa invocado por el
FTP (que no deja de ser uno de los tantos posibles métodos de transferencia), sino que lo fundamental
consiste en proteger los datos, con perfiles de dataset adecuados.
Como ya hemos señalado, la clase PROGRAM presenta ciertas particularidades que ya hemos
mencionado, pero conviene recordar en este punto:
A diferencia de las otras clases, para activar el control de programas bajo RACF no es necesario
activar la clase PROGRAM, sino que debe especificarse WHEN(PROGRAM) como opción en
la SETROPTS.
Si se modifica información de perfiles en la clase PROGRAM, debe ejecutarse el comando
“SETROPTS WHEN(PROGRAM) REFRESH” para que los cambios tomen efecto.
Los perfiles de la clase PROGRAM no soportan el modo warning.
Protección de programas
Todo programa reside en una biblioteca particionada, que puede ser pública, como aquellas que figuran
en la LINKLIST, o de uso privado. Es posible, y realmente frecuente aunque poco recomendable, que el
mismo nombre de programa exista en más de una biblioteca, pudiendo tratarse de distintas o idénticas
versiones, o bien de programas francamente diferentes.
Un programa que se encuentra protegido por un perfil en la clase PROGRAM se denomina programa
controlado. RACF solo permite proteger un programa dentro de una biblioteca específica. El nombre
del perfil debe matchear con el nombre del programa a proteger, mientras que la biblioteca dónde reside
específicamente la versión en cuestión debe definirse como miembro del perfil.
Un programa puede controlarse bajo RACF con diversos objetivos, entre los que podemos mencionar:
Para controlar qué usuarios/grupos están autorizados a ejecutarlo.
Porque es una exigencia del sistema que el programa esté controlado (usualmente, para mantener
lo que se conoce como “entorno limpio”).
Para hacer uso de la funcionalidad PADS.
En lo referente al segundo punto, es altamente recomendable, tal cual veremos en los ejemplos
subsiguientes, definir un perfil ** en la clase PROGRAM con UACC=READ y una lista de bibliotecas
asociadas cuyos programas necesiten estar controlados.
Definición de un perfil de la clase PROGRAM

Sintaxis:
RDEFINE|RDEF PROGRAM nombre-del-perfil
[ADDMEM(‘nombre-de-la-biblioteca’/[volumen]/{PADCHK|NOPADCHK}]
El nombre del perfil, al tener que matchear con el nombre del programa, debe constar de un único
calificador y no exceder los 8 caracteres. Si bien la clase PROGRAM no admite perfiles genéricos, es

108
posible usar el caracter * al final del nombre del perfil, que indica la presencia de 0 o más caracteres
(hasta una longitud máxima de 8). También es posible definir un perfil **. Sin embargo, al listarlos,
como se trata realmente de perfiles discretos, no aparecerá la característica (G) a continuación del
nombre del perfil, como sí sucede con los perfiles genéricos genuinos.
A través del operando ADDMEM se especifica la biblioteca dónde reside el programa a controlar, junto
con ciertos parámetros adicionales. Con posterioridad a la creación del perfil, pueden agregarse o
eliminarse bibliotecas de la lista usando el comando RALTER con los operandos ADDMEM o
DELMEM, según corresponda.
El nombre de la biblioteca debe ponerse entre apóstrofes simples, ya que en caso contrario RACF
antepone automáticamente como HLQ el PREFIX de TSO del usuario que ejecuta el comando.
El volumen es opcional, y especifica el disco dónde reside la biblioteca. Existe la posibilidad de
codificar el valor ‘******’ (incluidos los apóstrofes), lo cual indica que la biblioteca se encuentra
alocada en el SYSRES (disco residente). En caso de no especificarse volumen, que es lo más habitual,
la biblioteca puede existir en cualquier disco.
La opción PADCHK|NOPADCHK hace referencia a la funcionalidad PADS, que no trataremos en esta
guía. Si no se utiliza PADS, es conveniente codificar explícitamente NOPADCHK (el valor por defecto
es PADCHK).
Ejemplos:
1. RDEFINE PROGRAM adrdssu UACC(none) ADDMEM(‘sys1.linklib’//NOPADCHK)
2. RDEFINE PROGRAM fin* UACC(none) ADDMEN(‘finanzas.loadlib’//NOPADCHK)
3. RDEFINE PROGRAM ** UACC(read) ADDMEN(‘sys1.linklib’//NOPADCHK)
En ningún caso se codificó volumen, con lo cual la biblioteca especificada puede residir en cualquiera.
El perfil definido en (1) protege exclusivamente al programa ADRDSSU residente en la biblioteca
SYS1.LINKLIB. Este perfil no protege a otros programas de nombre ADRDSSU que pudieran existir
en otras bibliotecas. Como el UACC del perfil es NONE, solo estarían en condición de ejecutarlo
aquellos usuarios o grupos autorizados vía la lista de acceso correspondiente.
El perfil definido en (2) protege todos los programas cuyo nombre empiece con la cadena FIN y residan
en la biblioteca FINANZAS.LOADLIB, con excepción de aquellos que pudieran estar protegidos por
un perfil más específico.
El perfil definido en (3) es, como ya señalamos, sumamente útil para simplemente controlar –sin
restringir su ejecución- los programas de determinadas bibliotecas (generalmente, del sistema
operativo). Como ya hemos comentamos, conviene definirlo como ** en lugar de *, de modo de poder
listarlo individualmente. En este caso particular, el perfil protege a todos los programas de la biblioteca
SYS1.LINKLIB, con excepción de aquellos que pudieran estar protegidos por un perfil más específico
(como sería el caso de ADRDSSU, en nuestro ejemplo). Obsérvese que este perfil se definió con
UACC=READ, lo cual muestra que su objetivo no es restringir la ejecución de los respectivos
programas sino simplemente convertirlos en controlados. Se le pueden agregar más bibliotecas a través
del comando RALTER, que mencionamos a continuación.
Modificación de un perfil de la clase PROGRAM

Sintaxis:
RALTER|RALT PROGRAM nombre-del-perfil
[ADDMEM(‘nombre-de-la-biblioteca’/[volumen]/{PADCHK|NOPADCHK}]
[DELMEM(‘nombre-de-la-biblioteca’/[volumen])

109
En la lista de datasets del perfil pueden eventualmente existir varias entradas con el mismo nombre de
archivo pero con distintos volúmenes asociados.
Para eliminar una biblioteca de la lista, basta con usar el operando DELMEM especificando el nombre y
el volumen correspondiente (no hace falta codificar PADCHK|NOPADCHK). Si se especifica
únicamente el nombre de la biblioteca, se borrará la entrada que no tenga volumen especificado, si ésta
existiese (en caso contrario, se informa que no existe).
Ejemplo:
RALTER PROGRAM ** ADDMEN(‘tcpip.sezalink’//NOPADCHK)
Este comando agrega a la lista de datasets del perfil ** la biblioteca TCPIP.SEZALINK. En
consecuencia, todos los programas de esta biblioteca pasan a ser programas controlados -pero
ejecutables por todos los usuarios en virtud del UACC(READ) del perfil.
7.5 - Clase FACILITY

La clase FACILITY tiene la particularidad de no estar dedicada a la protección de un tipo de recurso
específico, sino que es utilizada por gran cantidad de aplicaciones, productos y componentes del sistema
operativo para efectuar chequeos de autoridad sobre recursos de la más diversa naturaleza. Es incluso
frecuente, aunque a veces no del todo recomendable, que una organización desarrolle una aplicación
propia cuya seguridad se establezca vía RACF a través de perfiles en la clase FACILITY.
Usualmente, la clase FACILITY se encuentra activa. En tal caso, es altamente recomendable que esté
RACLISTeada y configurada de modo que admita el uso de perfiles genéricos. Los perfiles deben tener
una longitud máxima de 39 caracteres y los nombres están determinados por la aplicación que los
utiliza. Todas las consideraciones hechas previamente sobre clases de recursos generales se aplican para
la clase FACILITY.
Dada la gran variedad de recursos factibles de ser protegidos, no es posible realizar un análisis
exhaustivo de los perfiles en esta clase. Mas aún, considerando que cualquier producto (sea de IBM, de
otra empresa proveedora de software, o desarrollado por la organización) puede potencialmente
chequear recursos en la clase FACILITY, la información sobre esta clase no aparece centralizada en
ninguna documentación, sino que debe recabarse separadamente en la propia de cada producto.
En virtud de lo anterior, no es en absoluto recomendable definir un perfil abarcativo ** en la clase
FACILITY. En general, los productos tienen comportamientos dispares frente a la condición de
“recurso no protegido” (RC=04). Algunos, frente a la ausencia de un perfil protector, autorizan el
acceso. Otros, en cambio, lo rechazan. Si se definiese el perfil **, todos los recursos pasarían a estar
efectivamente protegidos, lo que significaría un cambio cuyas consecuencias –presentes y futuras-
serían difíciles de prever.
Nos limitaremos pues a mencionar, a modo de ejemplo, algunas facilidades de uso frecuente que pueden
ser protegidas en esta clase.
Facilidad para listar perfiles de usuario

Normalmente, la posibilidad de listar el segmento base de cualquier usuario está reservada a aquellos
con el atributo SPECIAL o AUDITOR a nivel de sistema. Ambos atributos, claro está, brindan
autorizaciones mucho más amplias y sensibles que las de simplemente listar la información de un perfil
de usuario. Por lo tanto, dada la necesidad operativa de dotar a ciertos usuarios con la facilidad de
ejecutar el comando LISTUSER (típicamente personal del Helpdesk), RACF brinda la posibilidad de
delegar esta autorización a través de perfiles apropiados de la clase FACILITY. Concretamente, para
otorgar a un usuario la facilidad de listar el segmento base de cualquier otro, se debe proceder del
siguiente modo:

110
1) Definir el perfil IRR.LISTUSER en la clase FACILITY, con UACC=NONE.

2) Darle al usuario nivel de autoridad READ.
3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase
FACILITY se encuentra activa y RACLISTeada).
Observaciones:
Por motivos de seguridad, están explícitamente excluidos del alcance de la autoridad dada por el
recurso IRR.LISTUSER los usuarios con atributo SPECIAL, AUDITOR u OPERATIONS a
nivel de sistema.
Con excepción de los usuarios mencionados en el ítem anterior, la autorización sobre este
recurso permite listar cualquier usuario de la base de RACF. Existe, desde la versión 1.10 del
z/OS, la posibilidad de darle mucha más granularidad a esta facilidad. Por ejemplo, es factible
otorgar a un usuario la posibilidad de listar únicamente aquellos que tengan un determinado
owner, o que se encuentren dentro del campo de acción de determinado grupo. E incluso la
posibilidad de excluir, de este universo, ciertos usuarios específicos. No ahondaremos, sin
embargo, en los detalles de una implementación de este tipo en el presente texto, no por
considerarla innecesaria, sino por estimar que excede los objetivos planteados.
Si el perfil IRR.LISTUSER existe, solo agrega una posibilidad adicional en relación a la
autoridad necesaria para listar perfiles de usuario. Los privilegios habituales siguen siendo
suficientes. Por ejemplo, un usuario con atributo AUDITOR a nivel de sistema no requiere estar
autorizado a este perfil.
Si el perfil IRR.LISTUSER no se encuentra definido, rigen los chequeos de autoridad habituales
para el uso del comando LISTUSER.
En lugar del perfil discreto mencionado, sería posible definir un perfil genérico que proteja al
recurso (ej: IRR.**). Sin embargo, esto no me parece recomendable, ya que este perfil estaría
abarcando a otros recursos que pueden tener una necesidad de acceso diferente (ver ejemplo
posterior).
UACC=NONE es apropiado, ya que solo los usuarios cuyas tareas lo justifiquen deben contar
con esta facilidad.
Niveles de autoridad superiores a READ son equivalentes a READ, y por lo tanto totalmente
innecesarios, con la siguiente salvedad: si el perfil es discreto, autoridad ALTER otorga
privilegios administrativos sobre el perfil, lo cual probablemente constituya un efecto no
buscado.
Este recurso no autoriza a listar segmentos no base (TSO, OMVS, etc.). Para ello, deben
definirse perfiles adecuados en la clase FIELDS.
Facilidad para rehabilitar usuarios y otorgar nuevas passwords

Del mismo modo que surgió la necesidad de permitir listar perfiles de usuario (sin necesidad de otorgar
privilegios excesivos), también apareció naturalmente el requerimiento de dotar a ciertos usuarios de la
posibilidad de rehabilitar a cualquier otro y eventualmente otorgarle una nueva password. Para ello,
debe procederse del siguiente modo:
1) Definir el perfil IRR.PASSWORD.RESET en la clase FACILITY, con UACC=NONE.

2) Darle al usuario el nivel de autoridad deseado, de acuerdo al siguiente detalle:

111
READ Permite rehabilitar un usuario revocado mediante el operando RESUME del

comando ALTUSER. También autoriza a otorgar una nueva password (expirada).
UPDATE Aparte de lo que otorga READ, permite también la posibilidad de dar una nueva
password no expirada.
CONTROL Aparte de lo que otorga UPDATE, permite asimismo dar una nueva password aún
sin que haya pasado el tiempo de vida mínimo.
3) Ejecutar el comando “SETR RACLIST(FACILITY) REFRESH” (suponemos que la clase

FACILITY se encuentra activa y RACLISTeada).
Observaciones:
Por motivos de seguridad, están explícitamente excluidos del alcance de la autoridad dada por el
recurso IRR.PASSWORD.RESET los usuarios con atributo SPECIAL, AUDITOR u
OPERATIONS a nivel de sistema.
Con excepción de los usuarios mencionados en el ítem anterior, la autorización sobre este
recurso permite actuar sobre cualquier usuario de la base de RACF. Existe también en este caso
la posibilidad de darle mucha más granularidad a esta facilidad. Por ejemplo, es factible otorgar
a un usuario la posibilidad de rehabilitar únicamente aquellos que tengan un determinado owner,
o que se encuentren dentro del campo de acción de determinado grupo. E incluso la posibilidad
de excluir, de este universo, ciertos usuarios específicos. No ahondaremos, sin embargo, en los
detalles de una implementación de este tipo.
Si el perfil IRR.PASSWORD.RESET existe, solo agrega una posibilidad extra respecto a la
autoridad necesaria para la rehabilitación de usuarios. Los privilegios habituales siguen siendo
suficientes. Por ejemplo, un usuario con atributo SPECIAL a nivel de sistema no necesita
autorización sobre este perfil.
Si el perfil IRR.PASSWORD.RESET no se encuentra definido, rigen los chequeos de autoridad
habituales para el uso del comando ALTUSER.
El nivel de autoridad ALTER resulta equivalente a CONTROL, con la siguiente salvedad: si el
perfil es discreto, otorga privilegios administrativos sobre el perfil, lo cual probablemente
constituya un efecto no deseado.
Facilidad para acceder a datasets no catalogados

Es frecuente, y recomendable, que la organización tenga la opción CATDSNS en modo FAIL seteada
en la SETROPTS. De este modo, queda fuertemente restringida la posibilidad de acceder a archivos que
no se encuentren catalogados (lo cual debería constituir una situación de excepción).
Sin embargo, suele suceder que usuarios responsables del mantenimiento del sistema operativo
necesiten acceder a datasets no catalogados (por ejemplo, abriendo desde una partición un archivo
catalogado en otra). A tal efecto, es factible definir perfiles apropiados en la clase FACILITY que
brinden esta facilidad, sin necesidad de dar al usuario el atributo SPECIAL (que permite, asimismo, el
acceso a datasets no catalogados).
Como ya hemos comentado en un capítulo anterior, para datasets no catalogados (y no protegidos por
un perfil discreto), RACF construye el recurso de nombre ICHUNCAT.dsname, dónde dsname es el
nombre del archivo (solo los 30 primeros caracteres se consideran). RACF chequea entonces la
autoridad del usuario sobre este recurso en la clase FACILITY, y si es READ (o superior), entonces no
rechaza el acceso por la condición de no catalogado. Niveles de autoridad superiores a READ en este
tipo de perfiles son equivalentes a READ, y por lo tanto innecesarios (este nivel de autoridad no tiene
relación alguna con el nivel de autoridad requerido sobre el perfil de dataset protector del archivo, que

112
depende obviamente del tipo de operación que se pretende realizar). Naturalmente, sortear el chequeo
de “no catalogado” no elimina de ninguna manera los habituales chequeos posteriores (normalmente, en
la clase DATASET).
Ejemplo:
Supongamos que el usuario SYSPRG1 debe acceder a datasets no catalogados cuyos nombres son de la
forma TEST.CONFIG.**, y que éstos están protegidos por perfiles de dataset sobre los cuales el usuario
tiene suficiente autoridad. Para ello, basta definir el perfil genérico ICHUNCAT.TEST.CONFIG.** en
la clase FACILITY y otorgarle al usuario SYSPRG1 autoridad READ.
Si no es requerido este nivel de granularidad, puede definirse únicamente el perfil genérico
ICHUNCAT.**, que brinda a los usuarios autorizados la posibilidad de acceder a cualquier archivo no
catalogado. Sin que ello exceptúe, recalquémoslo nuevamente, los chequeos usuales de acceso a
archivos.

113
8 – PROCESO DE CHEQUEO DE AUTORIDAD

RACF no otorga ni rechaza solicitudes de acceso a recursos. Se limita a responder los requerimientos
que recibe de las distintas aplicaciones, subsistemas y demás componentes del sistema operativo
mediante la devolución de un código de retorno, que puede ser 0, 4 u 8, y cuyo significado es el
siguiente:
0 RACF considera que la solicitud de acceso debe aceptarse

4 RACF no posee información para responder sobre la solicitud de acceso
8 RACF considera que la solicitud de acceso debe rechazarse
En cualquier caso, es finalmente la aplicación la que decide aceptar o rechazar el requerimiento de
acceso. Por ejemplo, una exit propia de la aplicación podría perfectamente denegar una solicitud de
acceso aún cuando reciba de RACF un código de retorno 0. De todos modos, salvo casos excepcionales,
es de esperar que toda aplicación que maneje su seguridad externamente vía RACF actúe en forma
compatible con el código de retorno que reciba. Hecha esta importante aclaración, en lo que sigue,
diremos que RACF autoriza una solicitud de acceso cuando el código de retorno sea 0, y que la rechaza
cuando sea igual a 8.
En este capítulo describiremos en detalle el proceso que lleva a cabo RACF para determinar el código
de retorno que devolverá a la aplicación solicitante frente a un requerimiento de acceso.
8.2 - Autoridad de un usuario sobre un recurso

Recordemos que la solicitud de acceso que recibe RACF consta, esencialmente, de la siguiente
información:
Nombre de la clase
Nombre del recurso
Nivel de acceso requerido (EXECUTE, READ, UPDATE, CONTROL o ALTER)
Identificador del usuario
RACF procesa la solicitud de acceso siguiendo en orden, básicamente, los pasos que enumeramos a
continuación. Si en alguno de ellos RACF autoriza el requerimiento, lo rechaza, o bien devuelve el
código de retorno 4 (código de no protegido), el proceso termina y los pasos subsiguientes son omitidos.
Para simplificar, obviamos toda mención de security levels, categories y security labels, así como
también suponemos no se han implementado exits de RACF (ni del SAF).
Pasos del proceso de chequeo
1. Si RACF no está activo en el sistema, se devuelve el código de “no protegido”.
2. Si se trata de una clase de recursos generales que no se encuentra activa en la SETROPTS,

RACF devuelve el código de “no protegido”.
3. Si la clase debería estar RACLISTeada de acuerdo a lo que especifica la CDT, pero no lo está,
RACF devuelve el código de “no protegido”.
4. Si el requerimiento proviene de una STC marcada TRUSTED o PRIVILEGED, RACF lo

autoriza.

114
5. Si la clase está bajo GLOBAL en la SETROPTS, y la información de la GAC indica que debe
accederse a la solicitud, se autoriza el acceso, excepto que el usuario tenga el atributo
RESTRICTED, en cuyo caso el proceso continúa.
6. RACF busca el perfil protector del recurso. Si no encuentra al recurso protegido y se trata de una
clase de recursos generales, devuelve como código de retorno el DEFRETC de la clase
especificado en la CDT. Si la clase es DATASET y no existe perfil protector, continúa en el
paso 19.
7. Si el recurso es considerado propiedad del usuario, RACF autoriza el requerimiento. Un ejemplo

típico son datasets cuyo HLQ coincida con el identificador del usuario. Notemos que esto no
tiene ninguna relación con el concepto de owner del perfil.
8. RACF busca el identificador del usuario en la lista de acceso estándar del perfil protector del
recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado, RACF autoriza el
requerimiento. Si el usuario figura en ella pero con un nivel inferior al solicitado, RACF
continúa en el paso 14 (por lo tanto, ID(*), UACC y atributo OPERATIONS no cuentan).
9. Si la opción GRPLIST no está activa en la SETROPTS, RACF busca el “actual grupo de

conexión” del usuario en la lista de acceso estándar del perfil protector. Si el grupo figura en ella
con un nivel igual o superior al solicitado, RACF autoriza el requerimiento. Si el grupo figura en
ella pero con un nivel inferior al solicitado, RACF continúa en el paso 14 (por lo tanto, ID(*),
UACC y atributo OPERATIONS no cuentan).
10. Si la opción GRPLIST está activa en la SETROPTS, RACF busca en la lista de acceso estándar
del perfil protector del recurso la presencia de los eventuales grupos a los que el usuario está
conectado. Si uno o más de estos grupos figuran en ella, RACF selecciona el nivel de autoridad
más elevado. Si tal nivel es igual o superior al solicitado, RACF autoriza el requerimiento. Si,
por el contrario, el nivel resultante es inferior, RACF continúa en el paso 14 (por lo tanto, ID(*),
UACC y atributo OPERATIONS no cuentan).
11. RACF busca si existe una entrada * en la lista de acceso estándar del perfil protector. En caso
afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, y el usuario existe
en la base de RACF y no tiene el atributo RESTRICTED, RACF autoriza el requerimiento. Si el
nivel asociado a la entrada * es, en cambio, inferior al solicitado, RACF continúa en el paso 13
(por lo tanto el UACC no cuenta en este caso).
12. Si el UACC del perfil protector es igual o superior al nivel solicitado, y el usuario no tiene el
atributo RESTRICTED, RACF autoriza el requerimiento.
13. Si la clase está alcanzada por el atributo OPERATIONS y el usuario lo posee, ya sea a nivel de
sistema o a nivel de un grupo que tenga al perfil protector dentro de su campo de acción,
entonces RACF autoriza el requerimiento.
14. RACF busca el identificador del usuario en la lista de acceso condicional del perfil protector del
recurso. Si el usuario figura en ella con un nivel igual o superior al solicitado y se cumple la
condición correspondiente, RACF autoriza el requerimiento.
15. Si la opción GRPLIST no está activa en la SETROPTS, RACF busca el “actual grupo de
conexión” del usuario en la lista de acceso condicional del perfil protector. Si el grupo figura en
ella con un nivel igual o superior al solicitado y se cumple la condición correspondiente, RACF
autoriza el requerimiento.

115
16. Si la opción GRPLIST está activa en la SETROPTS, RACF busca en la lista de acceso
condicional del perfil protector la presencia de los eventuales grupos a los que el usuario está
conectado. Si uno o más de estos grupos figuran en ella para la condición dada, RACF
selecciona el nivel de autoridad más elevado. Si tal nivel es igual o superior al solicitado, RACF
autoriza el requerimiento.
17. RACF busca si existe una entrada * en la lista de acceso condicional del perfil protector. En caso
afirmativo, si el nivel de autoridad asociado es igual o superior al solicitado, se cumple la
condición correspondiente, el usuario existe en la base de RACF y no tiene el atributo
RESTRICTED, RACF autoriza el requerimiento.
18. Si el perfil protector está en modo WARNING, RACF autoriza el requerimiento.
19. Si se está intentando acceder a un archivo no protegido y la opción PROTECT-ALL está activa
en la SETROPTS en modo FAILURES, RACF rechaza el requerimiento, excepto que el usuario
tenga el atributo SPECIAL a nivel de sistema, en cuyo caso lo autoriza. Si la opción PROTECT-
ALL no está activa, o lo está pero en modo WARNING, RACF autoriza el requerimiento.
20. RACF finalmente rechaza el requerimiento.
Observaciones:
Si la solicitud de acceso es sobre un dataset no catalogado, RACF toma en cuenta además el
seteo de la opción CATDSNS en la SETROPTS, que ya analizamos en el capítulo
correspondiente.
La lista de acceso estándar se chequea siempre antes que la condicional.
La presencia del usuario, o de alguno de sus grupos de conexión (suponiendo que la opción
GRPLIST está activa en la SETROPTS) en la lista de acceso estándar del perfil protector del
recurso previene el eventual acceso que se pueda obtener vía UACC, ID(*) o atributo
OPERATIONS.
Salvo casos puntuales (acceso a archivos “no catalogados” o “no protegidos”), el atributo
SPECIAL no es chequeado en ningún paso durante el proceso. Esto es coherente con lo que ya
hemos señalado, en el sentido de que tal atributo no otorga acceso a recursos.

116
9 - PROGRAMAS UTILITARIOS

RACF provee varios programas utilitarios que permiten manipular, diagnosticar problemas y extraer
información de la base de RACF. En este capítulo expondremos los que consideramos más importantes.
Los que analizaremos deben ejecutarse en forma batch, por lo cual mostraremos un job a modo de
ejemplo y, en ciertos casos, una salida típica del utilitario. Naturalmente, la tarjeta job debe ser
personalizada de acuerdo a las exigencias de cada organización (nombre del job; código de cuenta;
clase; prioridad; etc.). Los programas invocados por los distintos utilitarios residen en la biblioteca
SYS1.LINKLIB, por lo cual el sistema los localizará sin necesidad de codificar JOBLIB o STEPLIB en
el job.
9.2 - IRRUT100
Este utilitario permite localizar en la base todas las ocurrencias de un usuario o grupo dado. Al ser un
programa que debe examinar todos los perfiles de la base, es recomendable ejecutarlo fuera de horarios
pico de actividad, para no impactar negativamente en la performance del sistema.
Hacemos notar que no existe un comando de RACF que permita, dado un usuario o grupo, listar todos
los perfiles dónde figure en las listas de acceso. El utilitario IRRUT100 puede ser usado para obtener
esta información (aunque también existen otros métodos, que mencionaremos más adelante).
Este utilitario siempre toma la información de la base de RACF activa en la LPAR dónde se ejecuta. No
es posible correr el IRRUT100 especificando una base de RACF distinta de la activa.
Ejemplo de IRRUT100:
//REFX100 JOB cuenta,programmer,
// MSGLEVEL=(1,1),MSGCLASS=clase,CLASS=clase,PRTY=valor
//**********************************************************************
//PASO1 EXEC PGM=IRRUT100
//SYSPRINT DD DSN=RACF.IRRUT100.SALIDA,DISP=OLD
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(20,4))
//SYSIN DD *
jef2514 conta
/*
//
El programa invocado debe ser IRRUT100.

La DD SYSPRINT es obligatoria y define dónde el utilitario grabará la información de salida. Puede
tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de
salida. En nuestro ejemplo, esta información se grabará en el dataset de nombre
RACF.IRRUT100.SALIDA, que suponemos prealocado.
La DD SYSUT1 es obligatoria y define un dataset de trabajo, que debe residir en disco.
La DD SYSIN es obligatoria e indica el dataset de control del utilitario. Consiste de un listado de
usuarios o grupos sobre los que se pretende buscar referencias. Esta información de entrada puede estar
embebida en el mismo jobstream (usando DD *) o bien residir en un archivo (secuencial o
particionado). En nuestro ejemplo, la SYSIN está inserta dentro del jobstream y establece que se busque
toda referencia en la base respecto al usuario JEF2514 y el grupo CONTA (en rigor, tan solo mirando
los identificadores, no es posible distinguir si se trata de grupos o usuarios).

117

Occurrences of JEF2514
In notify field of general resource profile PROGRAM FTPDNS
In standard access list of general resource profile PROGRAM FTPDNS
In standard access list of dataset profile CONTA.** (G)
In standard access list of dataset profile JEF2514.** (G)
First qualifier of profile JEF2514.** (G)
In access list of group CONTA
In access list of group PAGOS
User entry exists
Owner of user CON001
(G) - Entity name is generic
Occurrences of CONTA
In standard access list of general resource profile ACCTNUM CONTABILIDAD
In standard access list of general resource profile TSOPROC IKJCONTA
In standard access list of general resource profile TERMINAL FINA* (G)
In standard access list of general resource profile TAPEVOL CON* (G)
In standard access list of dataset profile CONTA.** (G)
First qualifier of profile CONTA.** (G)
In standard access list of dataset profile CONTA.A200%.** (G)
First qualifier of profile CONTA.A200%.** (G)
In standard access list of dataset profile PAGOS.PROVEE.** (G)
In standard access list of dataset profile PUBLIC.** (G)
Group name exists
In subgroup list of group FINANZAS
Connect group for user CONJF01
Default group for user CONJF01
Connect group for user CONJF02
Default group for user CONJF02
Connect group for user JEF2514
(G) - Entity name is generic.
Observemos que la salida no solo muestra la presencia del usuario o grupo en las listas de acceso, sino
también en cualquier otro campo de los perfiles, como ser OWNER o NOTIFY. Incluso informa si el
usuario o grupo especificado es el HLQ de algún perfil de dataset.
Una desventaja importante de la información que brinda el IRRUT100 es que no especifica el nivel de
autoridad con que figura el usuario/grupo en las listas de acceso del los perfiles. Por ejemplo, nos
informa, en nuestro caso, que el usuario JEF2514 está en la lista de acceso estándar del perfil de dataset
CONTA.**, pero no especifica si figura con nivel de autoridad NONE, EXECUTE, READ, UPDATE,
CONTROL o ALTER. En consecuencia, si se pretende definir un nuevo usuario o grupo que tenga
exactamente las mismas autorizaciones que otro existente, no es suficiente la información suministrada
por el IRRUT100.
Autoridad requerida
Para ejecutar el IRRUT100 especificando un determinado usuario o grupo, se debe tener el atributo
SPECIAL o AUDITOR a nivel de sistema o a nivel de un grupo que tenga al usuario o grupo en
cuestión dentro de su campo de acción.

118
9.3 - IRRUT200
Este utilitario tiene los siguientes usos básicos:
Identifica inconsistencias en la organización interna de la base de RACF. Es solo una
herramienta de diagnóstico, ya que en caso de detectar errores no realiza ninguna reparación.
Informa el porcentaje de utilización efectiva del espacio en la base de RACF. Esta información
es útil para decidir si es necesario un redimensionamiento.
Permite realizar una copia exacta (bloque a bloque) de la base de RACF. Es pues una
herramienta extremadamente útil para realizar un backup en disco de la base.
Permite sincronizar las bases de uso primario y backup.
Ejemplo de IRRUT200 para diagnóstico:

//DIAG200 JOB cuenta,programmer,
//**********************************************************************
//SYSRACF DD DSN=SYS1.BASERACF,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(20)),DCB=(LRECL=4096,RECFM=F)
//SYSUT2 DD SYSOUT=clase
//SYSPRINT DD SYSOUT=clase
//SYSIN DD *
INDEX [FORMAT]
MAP [ALL]
END
/*
//

La DD SYSRACF define el dataset de la base de RACF sobre el que se pretende efectuar la verificación
(recordemos que la base de RACF puede estar particionada en más de un dataset). Puede tratarse de un
dataset activo o no. En cualquier caso, si SYSUT1 ya contiene una copia del archivo a analizar,
entonces la DD SYSRACF puede omitirse.
La DD SYSUT1 define un archivo de trabajo que debe residir en disco y tener idénticas características
que el dado por SYSRACF (en nuestro ejemplo asumimos que SYS1.BASERACF tiene un tamaño de
20 cilindros). El utilitario IRRUT200 procede, como primera medida, a copiar el dataset definido en
SYSRACF al especificado en SYSUT1 (para ello utiliza internamente el programa IEBGENER).
Terminada la copia, se libera SYSRACF y el programa prosigue realizando las verificaciones
pertinentes sobre la copia recién obtenida. De esta manera se minimiza el tiempo en que el utilitario
mantiene la reserva sobre la base de RACF. SYSUT1 debe ser distinto a SYSRACF, sino el utilitario
falla. Tampoco SYSUT1 puede especificar un dataset de RACF activo, pues también el job fallaría.
Este control del utilitario evita que, por error, se corrompa un dataset activo usándolo como archivo de
salida.
Si no se codifica SYSUT1, se usa el dataset definido en SYSRACF durante todo el proceso. Si es un
dataset activo, esto no es aconsejable pues se mantendría la reserva hasta la finalización del job,
pudiendo causar problemas operativos.
La DD SYSUT2 define dónde el utilitario grabará ciertos mensajes de salida. Puede tratarse de un
archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de salida.

119
La DD SYSPRINT define dónde el utilitario grabará la información de diagnóstico generada. Puede

tratarse de un archivo secuencial (en disco o en cartucho), o bien puede especificarse un dispositivo de
salida.
La DD SYSIN es obligatoria e indica el dataset de control del utilitario. La información puede estar en
el mismo jobstream (lo más frecuente, usando DD *), o bien residir en un archivo. Las sentencias de
control admitidas son:
INDEX [FORMAT]
MAP [ALL]
END
INDEX especifica que se lleve a cabo la función de escaneo de índice. El parámetro FORMAT, en caso
de codificarse, debe estar separado de INDEX por un único espacio en blanco, e indica que se muestre
en la salida un listado formateado de todos los bloques de índice.
MAP establece que se lleve a cabo una verificación a nivel de BAM (Block Availability Mask). El
parámetro ALL, en caso de codificarse, debe estar separado de MAP por un único espacio en blanco, e
indica que se muestre en la salida un mapa de todos los bloques BAM de la base.
END indica el final del proceso.
Para interpretar en su totalidad la información de diagnóstico suministrada por el IRRUT200 es
necesario conocer profundamente la organización interna de una base de RACF, tema complejo que
escapa completamente a los objetivos de la presente guía. De todos modos, es recomendable correr esta
herramienta de diagnóstico con cierta regularidad (semanalmente, o mensualmente, por ejemplo), con el
propósito de verificar que el utilitario no encuentre inconsistencias lógicas en la organización interna de
la base. Si el IRRUT200 detectara algún tipo de problema, será necesario corregirlo, para lo cual deberá
consultarse la documentación correspondiente que brinda IBM. Mencionemos asimismo que no todos
los posibles problemas internos de una base de RACF son detectados por el IRRUT200. De todos
modos, RACF es un producto sumamente estable y probado, y con un manejo adecuado, es realmente
poco probable que aparezcan errores lógicos.
Si se ejecuta el IRRUT200 con la opción MAP, en la salida SYSPRINT aparece una serie de
estadísticas interesantes, entre las que se incluyen la cantidad de perfiles existentes en cada clase y el
porcentaje de ocupación de la base. Para evitar problemas repentinos por falta de espacio, es
conveniente controlar que este valor no supere, digamos, el 75%. Si se estuviera por encima, sería
conveniente programar una ampliación y reorganización de la base (ver el utilitario IRRUT400).
Mostramos a continuación un ejemplo de la SYSPRINT:
**** BAM BLOCK VERIFICATION ****

**** MAP FUNCTION STATISTICS ****
NUMBER OF BAM BLOCKS DEFINED 004
LAST BAM THAT DEFINES USED SPACE - RBA 00000000D000
RACF DATA SET IS 41 PERCENT FULL.
TOTAL NUMBER OF INDEX BLOCKS IN RACF DATA SET 00000198
TOTAL NUMBER OF LEVEL 01 BLOCKS IN RACF DATA SET 00000190
NUMBER OF GROUP ENTRIES - 0000173
NUMBER OF USER ENTRIES - 0004305
NUMBER OF DATASET ENTRIES - 0000428
NUMBER OF RACFVARS ENTRIES - 0000001
NUMBER OF SECLABEL ENTRIES - 0000003
NUMBER OF DASDVOL ENTRIES - 0000004
NUMBER OF TERMINAL ENTRIES – 0000086
NUMBER OF APPL ENTRIES – 00000021
NUMBER OF TCICSTRN ENTRIES - 0000002
NUMBER OF GCICSTRN ENTRIES - 000092
NUMBER OF GLOBAL ENTRIES - 0000003

120
NUMBER OF DSNR ENTRIES - 0000009

NUMBER OF FACILITY ENTRIES - 0000043
NUMBER OF PROGRAM ENTRIES - 0000018
NUMBER OF TSOPROC ENTRIES - 0000020
NUMBER OF ACCTNUM ENTRIES - 0000020
NUMBER OF TSOAUTH ENTRIES – 0000004
NUMBER OF MGMTCLAS ENTRIES – 0000008
NUMBER OF STORTCLAS ENTRIES – 0000031
NUMBER OF FIELD ENTRIES - 00000014
NUMBER OF CCICSCMD ENTRIES - 0000001
NUMBER OF VCICSCMD ENTRIES – 00000012
NUMBER OF VTAMAPPL ENTRIES – 00000008
NUMBER OF OPERCMDS ENTRIES – 0000035
NUMBER OF JESSPOOL ENTRIES – 0000028
NUMBER OF CONSOLE ENTRIES - 0000008
NUMBER OF SURROGAT ENTRIES - 00000012
NUMBER OF SDSF ENTRIES - 00000018
NUMBER OF STARTED ENTRIES - 0000157
NUMBER OF DIGTCERT ENTRIES - 0000011
Observemos, como dato importante, que se informa que el dataset está ocupado en un 41%. Esta es la
única forma de determinar el porcentaje de ocupación efectivo de una base de RACF. Los datasets de
RACF están formateados íntegramente. Por lo tanto, si se listaran sus características de alocación (por
ejemplo, con el comando S en la opción 3.4 Dslist del ISPF), se vería un uso del 100%, que de ninguna
manera refleja su ocupación real.
En la salida SYSUT2 se tendrían, por ejemplo, los siguientes mensajes:

DATA SET UTILITY - GENERATE
PROCESSING ENDED AT EOD
IRR62065I - IEBGENER copied SYSRACF to the work dataset SYSUT1, IEBGENER RC=0000
Ejemplo de IRRUT200 para hacer una copia de backup:

//BACK200 JOB cuenta,programmer,
//**********************************************************************
//SYSUT1 DD DSN=RACF.COPIA,DISP=OLD
//SYSIN DD DUMMY
//
En este ejemplo el programa utilitario IRRUT200 se emplea para realizar una copia exacta, bloque a
bloque, del dataset de RACF especificado en la DD SYSRACF. La copia se generará en el dataset
RACF.COPIA especificado en SYSUT1, que suponemos prealocado y con idénticas características y
tamaño que la entrada SYS1.BASERACF.
La DD SYSIN definida como DUMMY en este ejemplo establece que no se lleve a cabo ninguna
función de diagnóstico.
En su uso como herramienta de backup, el IRRUT200 solo sirve para realizar una copia de la base a una
que resida en un disco de igual geometría que la original y tenga igual tamaño. El dataset especificado
en SYSUT1 no debe ser nunca una base de RACF activa (en este u otro sistema), ya que el utilitario

121
podría corromperlo durante la copia. Si se pretende copiar una base a otra de distinto tamaño, debe
usarse el utilitario IRRUT400, que veremos más adelante.
Ejemplo de IRRUT200 para sincronizar las bases:

//**********************************************************************
//PASO1 EXEC PGM=IRRUT200,PARM=’ACTIVATE’
//SYSRACF DD DSN=SYS1.RACF.PRIM,DISP=SHR
//SYSUT1 DD DSN=SYS1.RACF.BACK,DISP=OLD
//
El parámetro PARM=ACTIVATE indica que se quiere copiar la base primaria sobre la de backup (o a
nivel de un dataset específico, si la base estuviera distribuida en más de uno). RACF verificará que
SYSRACF especifique efectivamente la base primaria de RACF y SYSUT1 la de backup. Se
comprobará asimismo que el backup se encuentre inactivo (recordemos que nunca el destino de una
copia debe ser un dataset de RACF activo). Finalizada la copia de SYSRACF (base primaria activa)
sobre SYSUT1 (base de backup inactiva), se activará la base de backup antes de liberarse la base
primaria. Solo de este modo queda garantizado que la base de backup resulte idéntica a la primaria. En
efecto, si en lugar de activar el backup el mismo IRRUT200 lo hiciera un administrador con el comando
RVARY, las eventuales modificaciones sobre la base primaria ocurridas entre la finalización del job y
la ejecución del comando de activación no se verían replicadas el backup.
Con PARM=ACTIVATE, las DD SYSPRINT y SYSIN, si estuvieran presentes, son ignoradas.
Autoridad requerida
Para ejecutar el utilitario IRRUT200, basta con tener autoridad READ sobre el dataset especificado en
SYSRACF y UPDATE sobre el dado por SYSUT1 (o ALTER, si es alocado dinámicamente por el job
como archivo permanente). Naturalmente, si los programas IRRUT200 o IEBGENER estuviesen
protegidos en la clase PROGRAM, se necesita asimismo autoridad para ejecutarlos.
9.4 - IRRUT400
Este utilitario tiene varias funciones:
Permite copiar la base de RACF a otra de tamaño distinto, que puede incluso residir en un disco
de distinta geometría.
Permite distribuir un dataset de la base de RACF en varios datasets. Asimismo, también puede
utilizarse para consolidar varios datasets de la base en una menor cantidad. Recordemos que
RACF admite un máximo de 90 datasets para su base primaria, e idéntica cantidad para la base
de backup.
Identifica cierto tipo de inconsistencias en los datasets de la base, como ser la presencia de
perfiles duplicados.
Reorganiza físicamente la base, juntando los eventuales segmentos de un mismo perfil.
En cualquiera de sus usos, es recomendable ejecutar este utilitario fuera de los horarios pico de
actividad, de modo de no afectar negativamente la performance del sistema.
En la presente guía no analizaremos la funcionalidad del IRRUT400 respecto a la posibilidad de
distribuir (split) o consolidar (merge) los datasets que conforman la base. Nos ocuparemos
exclusivamente del uso del utilitario como herramienta de copia y reorganización. Tampoco

122
describiremos todos los parámetros que admite el programa, sino el único cuya especificación es
obligatoria.
Si se quiere obtener una copia idéntica, es preferible emplear el utilitario IRRUT200 pues se encarga de
serializar adecuadamente el uso de la base de origen, garantizando una copia completamente fiel de la
original. En cambio, si la copia desea hacerse a una base de distinto tamaño, o residente en un disco de
distinta geometría (de 3380 a 3390, por ejemplo), entonces debe necesariamente utilizarse el
IRRUT400.
El IRRUT400, a diferencia del IRRUT200, no solo copia sino que reorganiza la base. Para comprender
exactamente el alcance del proceso de reorganización, es necesario tener un conocimiento acabado de la
estructura interna de la base de RACF, lo cual excede los objetivos de esta guía. Mencionemos
simplemente que se trata, esencialmente, de una especie de desfragmentación, consistente en reubicar
físicamente contiguos aquellos segmentos correspondientes a un mismo perfil. Si la base se encuentra
muy fragmentada (lo cual puede diagnosticarse a través del IRRUT200), esta reorganización puede
mejorar la performance de RACF, al disminuir la cantidad de lecturas de bloques que RACF debe
realizar para obtener la información completa de un determinado perfil.
Del mismo modo que para el IRRUT200, la base de destino no debe nunca estar activa en ningún
sistema. Más aún, si estuviera activa en el mismo sistema dónde se ejecuta el job, el utilitario falla. En
cambio, la base de origen (esto es, la que se pretende copiar) puede o no estar activa. Si se encuentra
activa, el IRRUT400 permite manejar el bit de lockeo de la base, que establece si la misma se encuentra
lockeada o no-lockeada.
Base lockeada
En este estado, no se permite ninguna actualización sobre la base, con excepción de cierta información
estadística. En consecuencia, no pueden definirse, modificarse o deletearse perfiles, así como tampoco
modificarse opciones de la SETROPTS. Más aún, algunos usuarios no podrán loguearse. Esto sucederá,
por ejemplo, si se trata de su primer logon del día, si intentan cambiar su password, o si han ingresado
su password correcta luego de algún intento inválido.
Estando la base lockeada, el chequeo de autoridad de usuarios sobre recursos se lleva a cabo
normalmente. Por lo tanto, los usuarios que se encuentran logueados a alguna aplicación no deberían
notar ninguna diferencia, excepto naturalmente que intenten modificar información de la base de RACF.
En cualquier caso, solo se justifica tener la base lockeada durante alguna tarea de mantenimiento
específica y por un período muy breve.
Base no-lockeada
Se trata del estado natural de la base, en el cual todas las actualizaciones están permitidas. Las bases de
RACF, tanto la primaria como la backup, deben estar no-lockeadas, salvo que exista una situación que
requiera explícitamente lo contrario, lo cual es poco frecuente y por un período corto de tiempo.
El IRRUT400 permite manejar el bit de lockeo de la base a través de un parámetro obligatorio que debe
tomar alguno de los valores siguientes: LOCKINPUT/NOLOCKINPUT/UNLOCKINPUT. No existe
ningún valor por defecto, por lo cual debe necesariamente codificarse alguna de las 3 opciones, cuyo
significado analizamos a continuación.
LOCKINPUT lockea la base de origen antes de iniciar el proceso de copia. De este modo, se garantiza
que la copia tenga idéntica información que la original, al no permitirse actualizaciones durante el
proceso. Se trata de la opción más recomendable, aunque tiene la desventaja de mantener lockeada la
base de origen durante el tiempo que insume el utilitario, lo cual puede, si se trata de una base activa,
acarrear ciertas dificultades operativas. Si se especificó LOCKINPUT, la base de origen quedará
lockeada aún luego de terminado el proceso de copiado. Si se trata de una base activa que se seguirá
utilizando, es imprescindible deslockearla. Para ello basta con agregar al job un paso adicional, que
invoque nuevamente el programa IRRUT400 pero con el parámetro UNLOCKINPUT.

123
NOLOCKINPUT no modifica el estado de lockeo de la base de origen. Esto significa que, si estaba
lockeada, permanecerá de este modo, y si no lo estaba (como es de esperar si se trata de una base
activa) permanecerá no-lockeada durante el proceso de copia. En este caso, si se produjeran
modificaciones en la base de origen durante la copia, es posible que la base de destino difiera de la
original, e incluso que resulte corrupta. No se trata, por lo tanto, de una opción aconsejable cuando la
base de origen está activa, excepto que se tenga la seguridad de que la actividad de actualización es
nula. Si la base de origen no está activa en ningún sistema, entonces no es pasible de ser modificada,
por lo cual la opción NOLOCKINPUT sería perfectamente apropiada.
UNLOCKINPUT deslockea la base de origen. Como ya mencionamos, si se ejecutó el IRRUT400 con
el parámetro LOCKINPUT y se pretende seguir usando como base activa a la base de origen, debe
necesariamente deslockearse invocando nuevamente el mismo utilitario con el parámetro
UNLOCKINPUT, tal cual mostramos en el ejemplo siguiente.
Ejemplo de IRRUT400 para copiar una base

//**********************************************************************
//COPIA EXEC PGM=IRRUT400,PARM=’LOCKINPUT’
//INDD1 DD DSN=SYS1.BASERACF,DISP=OLD
//OUTDD1 DD DSN=RACF.COPIA,DISP=OLD
//UNLOCK EXEC PGM=IRRUT400,PARM=’UNLOCKINPUT’
//INDD1 DD DSN=SYS1.BASERACF,DISP=OLD
//

La DD INDD1 especifica el dataset de la base de RACF a copiar. Si se quiere copiar una base de RACF
particionada en varios datasets, se deben usar subsiguientes DD de nombre INDDn (n=2, 3, etc.). Como
el utilitario tiene la posibilidad de modificar el bit de lockeo de la base de origen, es necesario
especificar DISP=OLD.
La DD OUTDD1 especifica el dataset de salida dónde se copiará el dataset definido en INDD1. Si se
requiere más de 1 dataset de salida, deben usarse subsiguientes DD de nombre OUTDDn (n=2, 3, etc.).
En nuestro caso, se supone que el dataset RACF.COPIA se encuentra prealocado. Recordemos que la
base de destino, de nombre RACF.COPIA en nuestro ejemplo, puede tener distinto tamaño que la de
origen.
La DD SYSPRINT establece dónde el utilitario grabará los mensajes de salida. Puede tratarse de un
El segundo paso del job dado como ejemplo deslockea la base SYS1.BASERACF, que había quedado
lockeada en el paso anterior (por haberse especificado el parámetro LOCKINPUT). Observemos que
cuando se usa el IRRUT400 para deslockear una base, como el utilitario no realiza ninguna copia, solo
es necesario especificar la base de origen (INDD1).
Autoridad requerida
Para ejecutar el utilitario IRRUT400 se debe tener autoridad UPDATE sobre el dataset especificado en
INDD1 y UPDATE sobre el definido por OUTDD1 (o ALTER, si es alocado dinámicamente por el
job). Se requiere nivel de autoridad UPDATE sobre la base de origen pues el utilitario permite
eventualmente alterar el bit de lockeo, lo cual es efectivamente una modificación. Aún si se especificó

124
NOLOCKINPUT, se requiere UPDATE pues RACF chequea por este nivel de autoridad
independientemente del valor puntual del parámetro.
9.5 - IRRDBU00
La base de RACF tiene un formato propio, bastante complejo, que solo interpreta RACF. Si se intenta
mirar directamente la base, se observarán datos distribuidos de manera aparentemente caótica, no
interpretables. Se presenta entonces la necesidad de contar con un programa utilitario que convierta la
información de la base a un formato plano, factible de ser fácilmente interpretado y explotado
programáticamente.
El utilitario IRRDBU00 (DBU viene de Data Base Unload.) permite justamente esto. Transfiere, a un
archivo secuencial, la información de todos los perfiles de la base. El archivo plano generado puede
usarse con diversos fines:
Se puede leer directamente, ya que el diseño de sus registros se encuentra plenamente
documentado en la bibliografía de IBM, más precisamente en el libro “Security Server RACF
Macros and Interfaces”.
Se puede formatear con algún programa propio, para extraer y organizar la información de una
forma conveniente.
Se puede usar para cargar tablas de DB2, para luego poder usar este motor de base de datos para
extraer información.
Se puede transferir a PC y formatearlo con algún programa de este entorno.
Sirve como archivo de entrada a otro utilitario importante que veremos más adelante, llamado
IRRRID00.
El IRRDBU00 puede ejecutarse sobre una base de RACF activa (primaria o backup) o inactiva. Cuando
lee un perfil de la base, el IRRDBU00 serializa el acceso al perfil y recién lo libera al finalizar la
transferencia al archivo secuencial. Naturalmente, debe hacer esto para todos los perfiles de la base. Por
este motivo, resulta aconsejable ejecutarlo tomando como entrada una copia de la base activa, de modo
a no afectar la performance de RACF. Una buena idea sería obtener una copia actual de la base usando
IRRUT200 y a continuación ejecutar el IRRDBU00 sobre la copia recién obtenida. La gran ventaja de
este método en 2 pasos radica en el hecho de que la reserva del IRRUT200 sobre la base activa es
mucho más breve y de menor impacto que la que demanda el IRRDBU00.
Los campos encriptados de la base de RACF, como las passwords, no son transferidos por el
IRRDBU00. Tampoco se copia al archivo secuencial generado la información de la SETROPTS, ni
ningún otro dato de la base que no exista directamente en los perfiles.
Ejemplo de IRRDBU00
//BAJARACF JOB cuenta,programmer,
//**********************************************************************
//BAJADA EXEC PGM=IRRDBU00,PARM=’NOLOCKINPUT’
//INDD1 DD DSN=SYS1.BASERACF.COPIA,DISP=SHR
//OUTDD DD DSN=RACF.PLANO,DISP=OLD
//
El programa invocado debe ser IRRDBU00.

125
La DD INDD1 define el dataset de la base de RACF que se quiere bajar a un archivo secuencial. Si se
quiere volcar toda la información de una base particionada en varios datasets, se deben usar
subsiguientes DD de nombre INDDn (n=2, 3, etc).
La DD OUTDD especifica el dataset secuencial de salida dónde se transferirá la información de los
perfiles de los archivos definidos en las INDDn. Debe tener las siguientes características:
RECFM=VB (registros de longitud variable y bloqueados)
LRECL=4096 (longitud de registro sugerida)
Con respecto al tamaño, una estimación inicial consiste en calcular el doble del espacio efectivamente
utilizado en la base de entrada. Por ejemplo, si la base de entrada tiene un tamaño de 50 cilindros y se
encuentra ocupada en un 40% (este porcentaje se puede obtener con el utilitario IRRUT200), esto
significa que hay efectivamente usados 20 cilindros. Por lo tanto, el archivo de salida del IRRDBU00
debería ocupar aproximadamente el doble, es decir 40 cilindros.
En nuestro caso, se supone que el dataset RACF.PLANO se encuentra prealocado.
La DD SYSPRINT establece dónde el utilitario grabará los mensajes de salida. Puede tratarse de un
El IRRDBU00 requiere obligatoriamente, al igual que el IRRUT400, la codificación del parámetro que
indica cómo se pretende que el utilitario maneje el bit de lockeo de la base. El significado de las
opciones LOCKINPUT, NOLOCKINPUT y UNLOCKINPUT es análogo al visto en el caso del
IRRUT400, con la siguiente importante diferencia: si se especifica LOCKINPUT y la base de entrada
no se encontraba lockeada, el IRRDBU00 la deslockeará automáticamente al finalizar (contrariamente a
lo que hace el IRRUT400, que la mantiene lockeada).
UNLOCKINPUT tiene por único objeto deslockear el dataset especificado en INDD1. No se hace en
este caso ninguna bajada de información. Cumple, en este punto, una función idéntica al IRRUT400 con
UNLOCKINPUT.
Sugerimos siempre ejecutar el IRRDBU00 sobre una base que no se encuentre activa. En tal caso, el
parámetro de lockeo resulta irrelevante.
Autoridad requerida
Para ejecutar el utilitario IRRDBU00 se necesita autoridad UPDATE sobre el dataset especificado en
INDD1, y UPDATE sobre el definido por OUTDD (o ALTER, si es alocado dinámicamente por el job).
Se requiere nivel de autoridad UPDATE sobre la base de origen debido a que el utilitario permite
eventualmente alterar el bit de lockeo.
9.6 - IRRRID00
Como ya vimos en el capítulo correspondiente, los comandos DELUSER o DELGROUP no eliminan
de la base las referencias que pudieran existir en otros perfiles respecto al usuario o grupo que se borra.
Por ejemplo, un usuario que se pretende eliminar podría existir en listas de acceso, en campos NOTIFY
o ser el OWNER de perfiles. El utilitario IRRRID00 es un buscador de referencias residuales, que no
solo localiza las referencias en la base de un usuario o grupo dado, sino que se encarga de generar los
comandos de RACF necesarios para su eliminación. Se trata de una herramienta fundamental para el
administrador de RACF, ya que posibilita la baja de usuarios y grupos en forma prolija.
Es importante señalar que el IRRRID00 no ejecuta ningún comando. Simplemente genera, en un
archivo de salida, los comandos necesarios para la eliminación de las referencias residuales. Es tarea del
administrador de RACF examinar cuidadosamente (y eventualmente editar) los comandos respectivos,
para luego decidir cuáles de ellos se ejecutaran.

126
El IRRRID00 utiliza como entrada la bajada plana de la base de RACF generada por el IRRDBU00. Es
pues necesario ejecutar el utilitario IRRDBU00 como paso previo a la utilización del IRRRID00, salvo
que ya se disponga de una bajada plana de la base suficientemente actualizada.
Ejemplo de IRRRID00
//IRRRID JOB cuenta,programmer,
//**********************************************************************
//PASO EXEC PGM=IRRRID00,REGION=25M
//SYSOUT DD SYSOUT=clase
//SORTOUT DD UNIT=SYSDA,SPACE=(CYL,(10,2))
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,2))
//INDD DD DSN=RACF.PLANO,DISP=SHR
//OUTDD DD DSN=RACF.IRRRID.SALIDA,DISP=OLD
//SYSIN DD *
jef2514
/*
//
El programa invocado debe ser IRRRID00.

La DD SYSPRINT determina dónde el utilitario grabará los mensajes de salida. Puede tratarse de un
La DD SYSOUT define dónde el DFSORT (o programa equivalente) invocado internamente por el
utilitario grabará los mensajes de salida. Puede tratarse de un archivo secuencial (en disco o en
cartucho), o bien puede especificarse un dispositivo de salida.
La DD SORTOUT define un archivo de trabajo, cuyo tamaño debe ser similar al especificado en INDD.
Lo más adecuado es dejar que el sistema lo aloque como un dataset temporario, que será en
consecuencia automáticamente eliminado al finalizar el job.
La DD SYSUT1 define otro archivo de trabajo, cuyo tamaño debe ser también similar al especificado
en INDD. Lo más adecuado es dejar que el sistema lo defina como un dataset temporario.
La DD INDD define el dataset de entrada del utilitario, que debe obligatoriamente ser una bajada plana
generada por el IRRDBU00.
La DD OUTDD especifica el dataset de salida del IRRRID00 dónde se generarán los comandos
necesarios para eliminar las referencias residuales correspondientes. Debe tener las siguientes
características:
RECFM=VB (registros de longitud variable y bloqueados)
LRECL=259 (como mínimo)
En nuestro ejemplo, se supone que el dataset RACF.IRRRID.SALIDA está prealocado.
La DD SYSIN define el listado de usuarios y/o grupos sobre los que se quiere buscar las referencias
residuales. La información puede estar embebida en el mismo jobstream (usando DD *), o bien residir
en un dataset (secuencial o particionado). Cada usuario o grupo debe estar en un registro separado, y si
se especifica un “ID de reemplazo”, debe estar a continuación, separado exactamente por un espacio en
blanco.
El “ID de reemplazo” funciona del siguiente modo:

127
Si el usuario o grupo del cual se buscan referencias figura en un campo del cual no puede eliminarse,
como es el caso si es el owner de un perfil, entonces el utilitario generará en la salida el comando
necesario para cambiar esta ocurrencia por el ID de reemplazo especificado. En caso de no codificarse
un “ID de reemplazo”, en el comando de salida figurará en tal caso el usuario/grupo precedido de un ?,
de modo que pueda editarse con un valor apropiado.
Si no se define SYSIN, o bien se aloca como DUMMY o vacía de contenido, el utilitario busca todas las
referencias en la base de usuarios y grupos que ya no existen. Es saludable ejecutar regularmente el
IRRRID00 de esta manera, de modo a detectar y borrar información residual que pueda haber quedado
al no borrarse adecuadamente un usuario o grupo de la base.
En nuestro ejemplo, la SYSIN está inserta dentro del jobstream y establece que se busque toda
referencia en la base respecto al usuario JEF2514.
La salida podría tener el siguiente aspecto:
/****************************************************************************************/
/* */
/* The RACF Remove ID Utility (IRRRID00) was executed on */
/* 2011-09-10 at 14:05:03. */
/* */
/* This file contains RACF commands that can be used to */
/* identify references to user IDs and group IDs. Residual */
/* references on an access list are deleted with the PERMIT */
/* command. For all other references, commands are created to */
/* change the reference to another value. The default value */
/* is ?id. This allows all references to a particular ID to */
/* be easily changed to another value using a text editor. */
/* */
/* Commands to alter ROLE definitions will be created within */
/* comments for informational purposes, though the actual */
/* updates should be made from TME. The ROLE will not be */
/* updated with a replacement value for a group name. */
/* */
/****************************************************************************************/
CONNECT CONJF01 GROUP(CONTA) OWNER(?JEF2514 )
PERMIT 'CONTA.**' GENERIC ID(JEF2514) DELETE
PERMIT 'FINAN.**' GENERIC ID(JEF2514) DELETE
PERMIT FTPDNS CLASS(PROGRAM) ID(JEF2514) DELETE
RALTER PROGRAM FTPDNS NONOTIFY
RALTER PROGRAM FTPDNS OWNER(?JEF2514 )
*****************************************************************************************/
* The following commands delete profiles. You must review */
* these commands, editing them if necessary, and then remove */
* the EXIT statement to allow the execution of the commands. */
*****************************************************************************************/
EXIT
DELDSD 'JEF2514.** '
DELUSER JEF2514
*****************************************************************************************/
* IRRRID00 has successfully completed */
*****************************************************************************************/
Observaciones:
De acuerdo a la información generada, el usuario JEF2514 figura como owner de 1 perfil y de la
conexión de un usuario a un grupo. Por lo tanto, el IRRRID00 genera los correspondientes comandos de
cambio de owner, debiéndose reemplazar ?JEF2514 por el nuevo owner elegido. Si se hubiese
codificado en la SYSIN in “ID de reemplazo” para JEF2514, este ID aparecería en la salida en lugar de
?JEF2514.

128
Si el usuario figura en el campo NOTIFY de un perfil, como es el caso en nuestro ejemplo, el utilitario
genera directamente el comando de eliminación. No se ofrece reemplazo en este caso, pues se trata de
un campo opcional.
Los comandos que borran perfiles están agrupados al final del archivo de salida, a continuación de una
sentencia EXIT que corta el procesamiento en caso de ejecutarse la Clist generada. Esto es intencional,
ya que al tratarse de comandos más críticos, se evita de esta manera que la ejecución inmediata del
archivo de salida los ejecute. Una vez revisado y editado adecuadamente el archivo de salida, basta con
borrar la sentencia EXIT para que también sean ejecutados estos comandos.
Como uso marginal, puede ejecutarse el IRRRID00 solo con el objeto de hallar todas las referencias en
la base de un determinado usuario/grupo, sin tener la intención de borrarlo. En este caso, el archivo de
salida se usa únicamente como fuente de consulta, y no se ejecuta ninguno de los comandos generados.
La información recabada es similar a la que brinda el IRRUT100. Tampoco se tiene, al igual que sucede
con el IRRUT100, el nivel de autoridad del usuario/grupo sobre los perfiles en cuyas listas de acceso
figura. Aunque esto es perfectamente entendible en el caso del IRRRID00, pues se trata de un uso del
utilitario para el que no fue específicamente desarrollado. No perdamos de vista, sin embargo, que
existe una diferencia importante: mientras que el IRRUT100 lee la base de RACF activa, el IRRRID00
extrae la información de una bajada plana (que puede estar desactualizada respecto de la base real).
Ambos métodos presentan pues ventajas y desventajas, debiendo decidir el administrador cual es el más
apropiado para cada situación.
Autoridad requerida
Para ejecutar el utilitario IRRRID00, basta con tener autoridad READ sobre el dataset especificado en
INDD y UPDATE sobre el definido por OUTDD (o ALTER, si es alocado dinámicamente por el job).
Naturalmente, para poder ejecutar los comandos generados se requiere la autoridad administrativa
correspondiente. De todos modos, el IRRRID00 es básicamente una herramienta para los
administradores de RACF, que deberían tener la autoridad suficiente para ejecutar exitosamente estos
comandos.
9.7 - IRRMIN00
Este utilitario tiene los siguientes posibles usos:
Inicializar un dataset en disco para ser usado como base de RACF
Actualizar los templates de una base de RACF
Reemplazar los templates residentes en memoria por los de la base
Toda base de RACF tiene grabado un cierto tipo de información -de uso interno por parte de RACF-
denominada templates. Se trata, básicamente, de una descripción de los distintos campos de cada tipo de
perfil. La información de los templates, indispensable para el funcionamiento de RACF, es cargada en
memoria en tiempo de IPL. Por lo tanto, aún si se actualizan los templates de la base, solo entrarán en
vigencia luego del próximo IPL o si explícitamente se los activa mediante la opción
PARM=ACTIVATE del IRRMIN00.
Con cada release del z/OS se distribuye una nueva versión del programa utilitario IRRMIN00, residente
en SYS1.LINKLIB. Como una CSECT del programa figuran los templates. En consecuencia, si se
actualizan los templates de una base usando –por ejemplo- el IRRMIN00 del z/OS 1.11, entonces se
grabarán en la base los templates correspondientes a este release del sistema operativo.
A tiempo de IPL, cuando se cargan los templates en memoria, el sistema determina el nivel de los
templates de la base primaria. Si se trata de templates anteriores a los propios del release del sistema
operativo, entonces no se cargan en memoria los de la base sino los que efectivamente corresponden. En
tal caso, en el SYSLOG se graba el mensaje ICH579E, informando que los templates de la base están

129
downlevel (desactualizados). No se trata de un error serio pues RACF va a funcionar sin problemas.
Conviene, sin embargo, seguir la sugerencia dada en el mensaje y actualizar los templates de la base.
Si una base de RACF es compartida por varias LPAR con distintas versiones del z/OS, se le deben
instalar los templates que correspondan a la versión más actualizada. Por ejemplo, si una base es
compartida por 3 LPAR, 2 de las cuales tienen z/OS 1.9 y la restante z/OS 1.11, la base debe tener los
templates del release 1.11 (las particiones que tienen 1.9 funcionarán sin problemas, ya que RACF
mantiene compatibilidad hacia atrás).
Inicialización de una nueva base de RACF

Para poder utilizar un dataset como base de RACF, no solo es necesario alocarlo con las características
apropiadas (detalladas en un capítulo anterior), sino que debe ser inicializado ejecutando el IRRMIN00
con PARM=NEW. Esto no solo debe hacerse para la base primaria, sino también para la base de
backup. Más aún, si las bases estuvieran particionadas en más de un dataset, debe ejecutarse el utilitario
para cada uno de ellos. Un dataset inicializado de este modo queda preparado para ser usado como base
de RACF. Sin embargo, al estar esencialmente vacía, difícilmente pueda utilizarse directamente en
forma satisfactoria. Lo usual es alocar una base con el IRRMIN00 y a continuación copiarle el
contenido de otra existente, que ya tenga cierta información mínima que la torne efectivamente usable.
Debe tenerse sumo cuidado, ya que el IRRMIN00 con PARM=NEW efectivamente destruye toda la
información existente en la base. Por lo tanto, no debe jamás ejecutarse el utilitario con PARM=NEW
para actualizar los templates de una base, pues se perderá toda la información.
Ejemplo de IRRMIN00 para alocar e inicializar una nueva base de RACF:

//IRRMIN JOB cuenta,programmer,
//**********************************************************************
//ALOCINI EXEC PGM=IRRMIN00,PARM=NEW
//SYSRACF DD DSN=SYS1.BASERACF.NUEVA,DISP=(NEW,CATLG),
SPACE=(CYL,(50),,CONTIG),DSORG=PSU,UNIT=SYSDA,VOL=SER=MVSRES
//
El programa invocado debe ser IRRMIN00, con PARM=NEW en este caso.

La DD SYSPRINT define dónde el utilitario grabará los mensajes de salida. Puede tratarse de un
La DD SYSRACF indica el dataset a inicializar como base de RACF. En nuestro caso, el archivo es
alocado dinámicamente por el mismo job con el nombre SYS1.BASERACF.NUEVA, con las
características adecuadas para una base de RACF. Observemos dos detalles de suma importancia: el
espacio debe ser alocado contiguo y el archivo debe ser PSU (Physical Secuencial Unamovable). Las
restantes características del dataset, como por ejemplo el tipo y longitud de registro, no es necesario
especificarlas pues el mismo utilitario setea los valores correctos. Naturalmente, el nombre de la base,
su tamaño y el disco dónde se aloca que hemos especificado son meros ejemplos, y deben ser
determinados por la organización.
Actualización de los templates de una base existente

Cuando se migra el sistema operativo, por ejemplo de z/OS 1.9 a z/OS 1.11, como el nuevo release trae
nuevos templates, es necesario actualizarlos. Para ello debe ejecutarse el IRRMIN00 con
PARM=UPDATE (obviamente se pretende mantener intacta toda la información existente en la base).
No solo deben actualizarse los templates de la base primaria sino también los de la base de backup. Más
aún, si las bases estuvieran particionadas en más de un dataset, debe ejecutarse el utilitario para cada

130
uno de ellos. La base puede estar activa en el sistema cuando se usa PARM=UPDATE, en cuyo caso
RACF obtiene una “reserva exclusiva” sobre ella durante el tiempo que insume la ejecución (mínimo).
Ejemplo de IRRMIN00 para actualizar los templates:

//**********************************************************************
//TEMPUPD EXEC PGM=IRRMIN00,PARM=UPDATE
//
El significado de las DD es análogo al visto en el ejemplo anterior.

El IRRMIN00 con PARM=UPDATE solo actualiza los templates de la base especificada en SYSRACF,
manteniendo intacta la información de los perfiles y de la SETROPTS.
Activación de los templates de la base

Ya comentamos que, si los templates de la base fueran de nivel inferior a los del release del sistema
operativo, se cargan en memoria estos últimos. Ahora bien, existe la posibilidad de que la aplicación de
mantenimiento del sistema (PTFs –Program Temporary Fix) eleve la versión de los templates. En tal
caso, si la base de RACF ya tiene aplicados los nuevos templates, es posible cargarlos en memoria sin
necesidad de recurrir a un IPL. Esto se logra ejecutando el IRRMIN00 con PARM=ACTIVATE, tal
cual se muestra a continuación:
Ejemplo de IRRMIN00 para activar los templates de la base:

//**********************************************************************
//TEMPACT EXEC PGM=IRRMIN00,PARM=ACTIVATE
//
El significado de las DD es análogo al visto en los ejemplos anteriores de IRRMIN00.

Si los templates en uso fueran de un nivel superior a los de la base especificada en SYSRACF, el job
falla y la activación no se produce. Esto evita que accidentalmente se carguen en memoria templates
inadecuados.
Autoridad requerida
Para ejecutar el utilitario IRRMIN00 se debe tener autoridad UPDATE sobre el dataset especificado en
SYSRACF (o ALTER, si se lo está alocando dinámicamente, como en nuestro primer ejemplo). Si el
programa IRRMIN00 se encontrara protegido en la clase PROGRAM, el usuario necesitaría asimismo
estar autorizado para su ejecución.
9.8 - Otros Utilitarios

Describimos brevemente a continuación otros programas utilitarios que no vamos a exponer en detalle
en esta guía, pero que resultan sin duda de interés para el administrador de RACF:

131
Nombre Función
BLKUPD Su nombre proviene de Block Update. Se trata de un comando que permite
manipular directamente la base de RACF, con el objeto de resolver problemas
internos. Sólo debe emplearse en situaciones dónde no sea posible reparar los errores
mediante comandos de RACF. Antes de ejecutarlo, es necesario tener un acabado
conocimiento de la estructura interna de la base, ya que un mal uso puede dañarla
irreparablemente. En el libro “Security Server RACF Diagnosis Guide” se puede
encontrar toda la información necesaria sobre el BLKUPD.
IRRADU00 Este utilitario formatea amigablemente los registros de SMF relevantes para la tarea
de auditoría de RACF (tipos 30, 80, 81 y 83). Reemplaza al ya obsoleto, aunque aún
soportado, RACFRW (RACF Report Writer). Técnicamente, este programa funciona
como una exit del IFASMFDP, utilitario estándar de IBM para el resguardo de los
registros de SMF. En el libro “Security Server RACF Auditor’s Guide” se puede
encontrar información detallada sobre este utilitario.
DSMON Su nombre proviene de Data Security Monitor. Se trata de una herramienta

sumamente útil, en particular para los auditores, ya que brinda gran cantidad de
información relativa a la seguridad global del sistema. Por ejemplo:
Exits de RACF activas
Usuarios con atributos SPECIAL, OPERATIONS o AUDITOR
Perfiles en la clase STARTED y entradas en la ICHRIN03
Estado de las clases de RACF
Entradas en la Global Access Table
Bibliotecas APF autorizadas y en LINKLIST
Árbol de grupos.
En el libro “Security Server RACF Auditor’s Guide” se puede encontrar información
detallada sobre este utilitario.

132
10 - COMANDO RVARY

El comando RVARY permite llevar a cabo las siguientes acciones, sin necesidad de un IPL:
Listar la configuración actual de las bases de RACF vigentes en el sistema.
Hacer un switch de las bases, operación que intercambia el uso de la base primaria y la de
backup. Esto puede hacerse incluso a nivel de dataset, en el caso en que la base se encuentre
distribuida en más de uno.
Activar o inactivar una base de RACF, incluso a nivel de dataset, en el caso en que se encuentre
distribuida en más de uno.
Cambiar entre los modos data sharing y non data sharing, suponiendo que RACF esté
habilitado para sysplex communication.
Los nombres de los datasets de las bases de RACF (primaria y backup) se definen en el módulo de
nombre ICHRDSNT (Data Set Name Table). El orden en que están definidos determina su número de
secuencia. Si las bases estuvieran divididas en varios datasets, será necesario indicar de qué manera se
quiere distribuir la información entre los distintos archivos. Para ello es necesario configurar una tabla
de rangos, que reside en el módulo de nombre ICHRRNG (Range Table). Ambas tablas deben
compilarse y linkeditarse a partir de un módulo fuente en lenguaje assembler. No describiremos en esta
guía su configuración. Solo destacamos que, al no tener instrucciones sino simplemente definiciones de
constantes, no es necesario recompilarlos al migrar el sistema operativo. Son compatibles hacia arriba, y
se pueden simplemente copiar. En cualquier caso, toda la información necesaria sobre ambas tablas está
en el libro “Security Server RACF System Programmer’s Guide”.
Para simplificar, supondremos en este capítulo lo siguiente:

- La base de RACF no está compartida entre varios sistemas. No trataremos, en consecuencia,
ningún aspecto relativo a sysplex communication o data sharing mode.
- El sistema tiene una base de backup activa y sincronizada con la primaria.
- El “subsistema RACF” se encuentra activo (lo cual es altamente recomendable, por cierto). Esto
posibilita, entre otras cosas, ejecutar el comando RVARY desde una consola como comando de
operador. No debe confundirse el “subsistema RACF” con el producto RACF propiamente dicho,
que puede funcionar aún cuándo no se encontrara activo el subsistema. Toda la información
necesaria sobre el “subsistema RACF”·se encuentra disponible en el libro “Security Server RACF
System Programmer’s Guide”.
No daremos la sintaxis completa del comando RVARY, sino que analizaremos por separado los
comandos necesarios para cada una de las funciones que describiremos en esta guía. Estos pueden
ejecutarse interactivamente desde una sesión de TSO, en forma batch, o bien por consola como
comandos de operador.
Observación:
Aún cuando la organización haya definido passwords para ambas funciones del RVARY, el sistema
seguirá aceptando la password por defecto YES para los operandos ACTIVE, SWITCH y
DATASHARE|NODATASHARE, siempre y cuando se ejecute el comando desde una consola con
autoridad MASTER (notemos que el operando INACTIVE está expresamente excluido de esta
posibilidad). En tal caso, la respuesta YES puede ingresarse desde cualquier consola (lo fundamental es
que tenga autoridad MASTER aquella dónde se ejecuta el comando RVARY). Esta flexibilización tiene
por objeto permitir una recuperación de emergencia, aún si no se dispone de las passwords del RVARY.

133
De todos modos, un usuario con atributo SPECIAL tiene siempre la posibilidad de cambiar ambas
passwords, aún sin conocer sus valores actuales.
Resulta por lo tanto de suma importancia controlar adecuadamente todas las consolas del sistema con
autoridad MASTER, de modo que solo usuarios debidamente autorizados estén en condiciones de
ejecutar comandos en ellas. Sobre este punto, conviene recalcar que los usuarios con acceso a TSO
pueden habitualmente, desde el SDSF, acceder a una consola con autoridad MASTER a través del
comando ULOG. Resulta pues fundamental limitar la posibilidad de ejecutar comandos de operador
desde SDSF, controlando el uso de la “/” mediante un perfil apropiado en la clase SDSF (o GSDSF, su
correspondiente clase agrupadora).
10.2 - Listado de la configuración de las bases

Sintaxis:
RVARY LIST
Autoridad requerida: ninguna
Este comando es meramente informativo y no efectúa modificación alguna. Lista la siguiente
información sobre todos los datasets que conforman las bases de RACF vigentes en el sistema:
Nombre del dataset
Número de secuencia
Disco dónde reside
Estado (activo o inactivo)
Uso (primario o backup)
Una salida de este comando tendría el siguiente aspecto:
ICH15013I RACF DATABASE STATUS:

ACTIVE USE NUMBER VOLUME DATASET
YES PRIM 1 MVSRES SYS1.BASERACF.PRIM1
YES BACK 1 MVSPR1 SYS1.BASERACF.BACK1
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
En este ejemplo, observamos que:

Ambas bases de RACF, primaria y backup, se encuentran distribuidas en 2 datasets. Los nombres de
estos datasets, definidos en la ICHRDSNT, son de libre elección por parte de la organización, no
teniendo necesidad alguna de tener a SYS1 como HLQ.
Los 4 datasets de encuentran activos.
La base primaria reside en un disco distinto que la de backup. Esto es altamente recomendable, pues
evita que ambas queden inutilizables en caso de fallo de un único disco. Sin embargo, dada la
tecnología actual de dispositivos de almacenamiento, es probable que distintos discos lógicos
correspondan en realidad al mismo disco físico, con lo cual esta precaución puede no resultar del todo
efectiva.
Es aconsejable que la base primaria resida en el “disco residente”.
10.3 - Switch de las bases

Sintaxis:
RVARY SWITCH [DATASET(nombre…|*)]

134
Autoridad requerida: requiere ingreso por consola de la password para la función SWITCH
Este comando intercambia el uso de los datasets de la base primaria especificados en el operando
DATASET con sus correspondientes archivos de bakup. En efecto, los datasets pertinentes de la base de
backup pasan a tener uso primario, mientras que los originalmente primarios pasan a ser de uso backup,
siendo también inactivados y desalocados.
Si se codifica DATASET(*), o se omite el operando DATASET, el switch actúa para todos los datasets
que conforman la base primaria.
Observaciones:
Para poder switchear, el dataset de backup, que pasará a tener uso primario, debe necesariamente estar
activo. En caso contrario, RACF ignora el comando y emite un mensaje de error.
Como la función de SWITCH intercambia y deja inactivo el nuevo backup, si se pretende volver a la
configuración original mediante la ejecución de un nuevo SWITCH, es necesario previamente reactivar
el backup.
El comando RVARY SWITCH actúa siempre sobre datasets de uso primario. Si se codifica en el
operando DATASET un archivo cuyo uso es de backup, RACF ignora el comando y emite un mensaje
de error.
Ejemplo:
Supongamos que, en el sistema con la configuración dada en el ejemplo anterior, el dataset de nombre
SYS1.BASERACF.PRIM2 se encuentra dañado, por lo cual es necesario trasladar el procesamiento a su
correspondiente dataset de backup. Para ello, debe ejecutarse el siguiente comando:
RVARY SWITCH DATASET(sys1.baseracf.prim2)
Completada la ejecución exitosa del comando, el listado de la nueva configuración arrojaría el siguiente
resultado:
ICH15013I RACF DATABASE STATUS:
ACTIVE USE NUMBER VOLUME DATASET
NO BACK 2 *DEALLOC SYS1.BASERACF.PRIM2
YES PRIM 2 MVSPR1 SYS1.BASERACF.BACK2
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
En esta situación, debería repararse lo antes posible el dataset dañado (al estar desalocado, es posible
manipularlo), activarlo, switchear nuevamente y finalmente activar el backup para retornar a la
configuración normal.
10.4 - Activación/inactivación de las bases

Sintaxis:
RVARY ACTIVE|INACTIVE[NOCLASSACT(clase…|*) (NOTAPE)]
[DATASET(nombre…|*)]
Autoridad requerida: requiere ingreso por consola de la password para la función STATUS
Este comando permite activar o inactivar tanto la base primaria como la de backup, incluso a nivel de
dataset, si se encontraran particionadas. En una situación normal, todos los datasets de las bases deben
estar activos.
Si un dataset de la base primaria está inactivo, RACF no puede procesar requerimientos para los que
precise información que reside en él (excepto que la tenga disponible en memoria). Por lo tanto, en esta

135
situación, es de esperar que se produzcan errores (abends). El correspondiente dataset de backup, aún
cuando se encontrara activo, no reemplaza automáticamente al primario. Para ello, debe ejecutarse el
comando de switch adecuado. Solamente ocurre un switch automático a la base de backup si un error de
I/O sobre la base primaria pone offline el disco dónde reside.
Cuando todos los datasets de la base primaria se encuentran inactivos, se produce una situación,
bastante molesta por cierto, conocida como failsoft processing. En estas condiciones, el sistema resulta
prácticamente inoperable, ya que el operador debe aprobar por consola todo intento de acceso a
datasets. Para otro tipo de recursos, el otorgamiento o el rechazo de un requerimiento de acceso queda
en manos de la aplicación o subsistema que lo requiera. Son de esperar, de todos modos, innumerables
inconvenientes. Si el sistema se encuentra en failsoft processing, situación por cierto de emergencia,
debe disminuirse la actividad al mínimo indispensable y tomarse inmediatamente las acciones
necesarias para volver a la normalidad.
Si un dataset de la base de backup está inactivo, RACF continúa procesando de manera normal, solo
que eventualmente no podrá replicar en la base de backup las modificaciones que involucren al
correspondiente dataset primario. Si bien esto no origina ninguna situación crítica, en tanto no impacta
directamente en la seguridad del sistema, tener desactualizada la base de backup no es en absoluto
aconsejable. Si fuera el caso, se debe proceder cuanto antes a resincronizarla con la base primaria,
usando el IRRUT200.
El operando ACTIVE indica que se quiere reactivar los datasets especificados en DATASET. Si se
codifica ACTIVE y se omite DATASET, RACF activará todos los datasets de la base primaria.
El operando INACTIVE indica que se quiere inactivar (y desalocar) los datasets especificados en
DATASET. Si se codifica INACTIVE y se omite DATASET, RACF inactivará todos los datasets de la
base primaria, provocando la entrada del sistema en failsoft processing.
La opción NOCLASSACT del operando INACTIVE permite establecer una lista de clases de la CDT (o
todas, si se codifica *) para las cuales la protección de RACF no estará en efecto mientras se encuentre
la base inactiva.
La opción NOTAPE del operando INACTIVE indica que la protección para cartuchos establecida en la
clase TAPEVOL no estará en efecto mientras se encuentre la base inactiva.
En cualquier caso, la protección vuelve a tomar efecto inmediatamente al reactivar la base. No debe
confundirse esta “inactivación de clases” al momento de inactivar la base con la inactivación habitual de
clases que se establece a nivel de la SETROPTS.
10.5 - Procedimientos de recuperación de bases de RACF

Si bien es muy poco frecuente, es posible que algún dataset de las bases de RACF se dañe y sea
necesario repararlo o reemplazarlo. Como paso previo a cualquier intento de manipulación, es necesario
inactivarlo y desalocarlo, para lo cual debe ejecutarse el comando RVARY con el operando
INACTIVE. Vamos a analizar 3 posibles escenarios de fallos, describiendo para cada uno un posible
proceso de recuperación. Supondremos que la base no se encuentra particionada. En caso de estarlo,
solo deberá aplicarse el procedimiento para los datasets que experimenten problemas.
La base primaria funciona correctamente pero falla la base de backup
1. Inactivar la base de backup ejecutando el comando:

RVARY INACTIVE DATASET(nombre-base-backup)
2. Analizar qué tipo de problema presenta la base de backup. Si fuese necesario, deletearla,
realocarla con el mismo nombre en un disco adecuado y copiarle la base primaria utilizando el
utilitario IRRUT200 con PARM=ACTIVATE.

136
La base primaria falla y la base de backup funciona correctamente
1. Switchear las bases ejecutando el comando:

RVARY SWITCH
2. Analizar qué tipo de problema presenta la base de backup actual (primaria original, que estaba
fallando). Si fuese necesario, deletearla, realocarla con el mismo nombre en un disco adecuado y
copiarle la base primaria actual (backup original) utilizando el utilitario IRRUT200 con
PARM=ACTIVATE.
3. Switchear las bases nuevamente ejecutando el comando:
RVARY SWITCH
4. Activar la base de backup actual (backup original) ejecutando el comando:
RVARY ACTIVE DATASET(nombre-base-backup)
Ambas bases -primaria y backup- están fallando
1. Inactivar la base primaria ejecutando el comando:

RVARY INACTIVE DATASET(nombre-base-primaria)
El sistema entra pues momentáneamente en failsoft processing.
2. Analizar qué tipo de problema presenta la base de primaria. Si fuese necesario, deletearla,
realocarla con el mismo nombre en un disco adecuado y copiarle un backup de la base de RACF
lo más actualizado posible y que se encuentre en buenas condiciones. Si se dispone de uno en
disco, utilizar el utilitario IRRUT200 (si el backup es de igual tamaño y reside en un disco de
igual geometría) o el IRRUT400. Si el único backup utilizable está en cartucho, copiarlo usando
el programa utilitario IEBGENER.
3. Activar la base primaria ejecutando el comando:
RVARY ACTIVE DATASET(nombre-base-primaria)
El sistema deja pues de estar en failsoft processing.
3. Inactivar la base de backup ejecutando el comando:
RVARY INACTIVE DATASET(nombre-base-backup)
4. Copiar la base primaria sobre la de backup utilizando el utilitario IRRUT200 con
PARM=ACTIVATE.
En este escenario, las modificaciones hechas en la base de RACF desde el momento en que se tomó el
backup utilizado para la recuperación y el de la falla de ambas bases activas se habrán perdido. De todos
modos, este período debería ser breve (si existe una correcta frecuencia de backups), y un análisis de los
registros 80 del SMF correspondientes a este lapso permitiría reconstruir los cambios.

Apuntes de RACF PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apuntes de RACF PDF

Cargado por

Copyright:

Formatos disponibles

Apuntes de RACF

Juan Guillermo Mautalen

Apuntes de RACF Juan Mautalen

2 - LA BASE DE RACF .......................................................................................................................8

3 - USUARIOS Y GRUPOS .............................................................................................................. 12

4 - PROTECCIÓN DE DATASETS ................................................................................................. 39

5 - OPCIONES GLOBALES DE RACF ........................................................................................... 56

Apuntes de RACF Juan Mautalen

5.5 - Control de programas ............................................................................................................... 60

6 - PROTECCIÓN DE RECURSOS GENERALES ........................................................................ 88

Apuntes de RACF Juan Mautalen

7 - CLASES PARTICULARES ....................................................................................................... 101

8 – PROCESO DE CHEQUEO DE AUTORIDAD ........................................................................ 113

9 - PROGRAMAS UTILITARIOS ................................................................................................. 116

10 - COMANDO RVARY................................................................................................................ 132

Apuntes de RACF Juan Mautalen

1.1 - Consideraciones generales

1.2 - Identificación y autenticación de usuarios

1.3 - Control de acceso a recursos

1.4 - Herramientas de auditoría

Apuntes de RACF Juan Mautalen

o Ejecución exitosa de comandos de RACF

1.5 - Seguridad externa para aplicaciones

Apuntes de RACF Juan Mautalen

2.1 - Consideraciones generales

BASE PRIMARIA BASE BACKUP

El diagrama muestra una configuración de una base de RACF particionada en 2 datasets

Organization PSU Archivo secuencial Unamovable (inamovible)

Apuntes de RACF Juan Mautalen

Clases de Recursos Generales (solo se enumeran muy pocas, a modo de ejemplo)

2.4 - Actualización de la base

Apuntes de RACF Juan Mautalen

Se listan a continuación los comandos de RACF que consideramos más relevantes:

Comando Abreviación Descripción

ADDGROUP AG Define un nuevo grupo de usuarios

ADDSD AD Define un nuevo “perfil de dataset”

RDEFINE RDEF Define un nuevo perfil de recursos generales

PERMIT PE Modifica las listas de acceso de un perfil

Apuntes de RACF Juan Mautalen

AU rh3472 NAME(‘juan’) DFLTGRP(rrhh) PASSWORD(abc123)

AU Comando básico, abreviación de ADDUSER.

Apuntes de RACF Juan Mautalen

3.1 - Consideraciones generales

3.2 - Administración de grupos de RACF

Con respecto al nombre, ya señalamos las condiciones que debe cumplir.

Apuntes de RACF Juan Mautalen

El concepto de owner es particularmente importante, y se aplica a cualquier tipo de perfil en la base de

3.3 - Alta de un grupo

Apuntes de RACF Juan Mautalen

3.4 - Modificación de un grupo

Apuntes de RACF Juan Mautalen

Tener autoridad a través de perfiles apropiados en la clase FIELDS.

3.5 - Eliminación de un grupo

3.6 - Listado de un grupo

Apuntes de RACF Juan Mautalen

SUBGROUP(S)= PAGOS SUELDOS

3.7 - Administración de usuarios de RACF

Apuntes de RACF Juan Mautalen

Apuntes de RACF Juan Mautalen

3.8 - Alta de un usuario

Apuntes de RACF Juan Mautalen

3.9 - Modificación de un usuario

Apuntes de RACF Juan Mautalen