What is Mainframe Technology ?

Mainframe | Trenovision

Time Sharing Option

Time Sharing Option is an interactive time-sharing (Time sharing – is the sharing of a computing resource among many users by means of multiprogramming and multi-tasking) environment for IBM mainframe operating systems, including OS/360 MVT, OS/VS2 (SVS), MVS, OS/390, and z/OS. In common, the argument arise with mainframes are at their cost only.
TSO interacts with users in either a line-by-line mode or in a full screen, menu-driven mode. In the line-by-line mode, the user enters native commands by typing them in manually; At the same time, the system interprets the commands, and then displays responses on the terminal screen. In common, a large percentage of interaction is actually via ISPF, which allows for customized menu-driven interaction designed uniquely for all sectors. This combination is called TSO/ISPF. TSO can also provide a Unix-style environment on OS/390 and z/OS via the UNIX System Services command shell, with or without ISPF but at one time the maximum number of programs in CPU control at any one
Time is just one. Every task has it owns priority set by.
The primary usages are as:

•  A text editor (Text editor – is a type of program used for editing plain text files)
•  Batch job (Batch Job is the execution of a series of programs (“jobs”) on a computer without manual intervention.) support, including completion notification
• Debuggers for some programming languages used on System/360 and later IBM mainframes
• Support for other vendors’ end-user applications, for example for querying IMS and DB2 databases

Customer Information Control System (CICS)

Customer Information Control System (CICS) is invented by IBM on 1968 which provides online transaction processing services and management for critical business applications. CICS runs on many platforms (from the desktop to the mainframe) and is used in various types of networks that range in size from a few terminals to many thousands of terminals.
The CICS application programming interface (API) enables programmers to port applications among the hardware and software platforms on which CICS is available. Each product in the CICS family can interface with the other products in the CICS family, thus enabling inter-product communication.
CICS runs primarily on IBM mainframe systems under z/OS commonly and also in z/VSE – Virtual Storage Extended – An operating system for IBM computers which is very less common when compared to the usage of z/OS. The prefix z refers to family name commonly used by IBM and it can be also referred as zero downtime.
CICS originally intended to:

• Accept transaction input from terminals.
• Process those “transactions” by calling the appropriate application program based upon a transaction code included in the terminal input.
• Provide API services to those called programs (using EXEC CICS calls).
• Send “responses” back to the originating terminal.

CICS is a very familiar application among financial firms like banks and insurance companies and with government sectors. CICS provides services that extend or replace the functions of the operating system and are more efficient than the generalized services in the operating system and simpler for programmers to use, particularly with respect to communication with diverse terminal devices.

Resource Access Control Facility

RACF – Resource Access Control Facility is an IBM software product invented in 1976. It is a strong security product that provides access control and auditing functionality for the z/OS and z/VM operating systems.
Its main features are.

• Identification and verification of a user via user id and password check (authentication)
• Identification, classification and protection of system resources
• Maintenance of access rights to the protected resources (authorization)
• Control the means of access to protected resources
• Logging of accesses to a protected system and protected resources (auditing)

RACF, with its lists of users and lists of resources, allows management to delegate the authority to the owners of these entities in such a way as to maintain the separation of duties while maintaining a flexible, responsive access control strategy.
The delegation mechanism in RACF and the easy, nontechnical commands that change the relationship of a user to a resource mean that adopting the principle of least possible privilege need not be burdensome nor inflexible when unusual circumstances dictate that access permission should be changed. When an unforeseen circumstance requires a change in access privilege, the change can be made by a nontechnical person with access to a TSO terminal, and management can be alerted to review the fact that the change was made.
RACF establishes security policies rather than just permission records. It can set permissions for file patterns — that is, set the permissions even for files that do not yet exist. Those permissions are then used for the file (or other object) created at a later time.
Major subsystems such as CICS and DB2 can use the facilities of RACF to protect transactions and files. Much of the work to configure RACF profiles for these subsystems is done by the CICS and DB2 system programmers. So, there is a need for people in these roles to have a useful understanding of RACF and how it relates to the software they manage.

Components of CICS

Customer Information Control System (CICS) provides components such as a transaction-processing monitor and a transaction-processing manager for a mainframe computer to run online transaction processing (OLTP) applications. You can install CICS on all three mainframe operating systems: Multiple Virtual Storage (MVS), Virtual Storage Extended (VSE), and Virtual Machine (VM). Due to the popularity of MVS, CICS is commonly installed on MVS mainframe computers. CICS extends the capabilities of a batch-only environment by providing the application system components that allow the mainframe computer to run OLTP applications.
CICS can run online applications on the mainframe computer because CICS acts almost like a separate operating system: it manages its own memory address space, runs its own file management functions, and manages the concurrent execution of multiple transaction applications.
Each unique CICS “Task” or transaction is allocated its own dynamic memory at start-up and subsequent requests for additional memory were handled by a call to the “Storage Control program” (part of the CICS nucleus or “kernel”), which is analogous to an operating system.
To use Transaction Integrator (TI) successfully, you must understand the following CICS components and terminology:

CICS region

Each instance of CICS running on a mainframe computer is defined in Virtual Telecommunications Access Method (VTAM) by using a VTAM application statement. Each CICS instance defined in an application statement is called a CICS region. It is useful to define multiple CICS regions on a single mainframe computer because it allows you to logically group TPs in separate CICS regions and to use at least one CICS region for test purposes.

Transaction Program (TP)

The transaction program (TP) is the application software that executes under the supervision of CICS and contains the actual programming code necessary to process the business logic. Other terms that refer to a TP are transaction, host transaction program, application program, and program.

Transaction ID

All TPs that run under CICS are invoked by using a unique, four-character transaction identification (TRANID). This may sometimes be confusing because the transaction ID typically is different than the TP name. For example, the TP that handles CICS resource definitions is called Resource Definition Online (RDO), whereas the transaction ID that starts RDO is CEDA.

Program control table (PCT)

The program control table (PCT) is a CICS table that contains a mapping between TRANIDs and their associated TP names. After the TRANID is invoked, CICS starts the TP associated in the PCT with that TRANID.

File control table (FCT)

The file control table (FCT) is a CICS table that monitors which VSAM files are available to TPs. The FCT lists the name and type of VSAM files and valid operations that users can perform on each file. Although CICS can access other types of data stores, such as DB2, it accesses VSAM most frequently.

RDO

The RDO is a CICS TP that allows a CICS systems programmer to define the resources contained in the internal control tables.

Task

A task executes the functions of the TP; every CICS TP performs its functions by using a task. A CICS TP can use a single task or multiple tasks to perform its functions. Each time a TP is invoked, CICS starts the tasks required to perform its functions. CICS is a multitasking environment, which means that more than one task can, and often is, running at the same time.

CICS Transaction Architecture

CICS transaction is a set of operations that perform a task together. Usually, the majority of transactions are relatively simple tasks such as requesting an inventory list or entering a debit or credit to an account. A primary characteristic of a transaction is that it should be atomic. On IBM System z servers, CICS easily supports thousands of transactions per second, making it a mainstay of enterprise computing.
CICS applications comprise transactions, which can be written in numerous programming languages, including COBOL, PL/I, C, C++, IBM Basic assembly language, REXX, and Java.
Each CICS program is initiated using a transaction identifier. CICS screens are usually sent as a construct called a map, a module created with Basic Mapping Support (BMS) assembler macros or third-party tools. CICS screens may contain text that is highlighted, has different colors, and/or blinks depending on the terminal type used. An example of how a map can be sent through COBOL is given below. The end user inputs data, which is made accessible to the program by receiving a map from CICS.

Individual User Identification to CICS and Windows Server

This is a discussion of how Resource Access Control Facility (RACF) security works in a typical IBM Mainframe MVS (z/OS) CICS system today as it is generally used in most production shops and of the comparable security for programs running under the transaction monitor services of Microsoft Windows Server 2003. The information is largely the same for other popular mainframe security products, such as ACF2 and Top Secret from Computer Associates.
The basis for individual user-based security is identification and authentication. The system must determine who the user is, or claims to be, and then authenticate that the user is who he or she claims (confirming their identity), and then “remember” the identity of that user or store a credential or token which represents that user.
For CICS on MVS, users are defined by an entry in the RACF database referred to as a user profile. Users identify themselves by specifying their RACF user identification (USERID) and the associated password, or an operator identification card (OIDCARD).

Security in a CICS environment

As an online transaction-processing system (often supporting many thousands of users), CICS requires the protection of a security system to ensure that the resources to which it manages access are protected and are secure from unauthorized access. CICS provides a number of facilities that protect your resources against unauthorized access.
To provide the required security for your CICS regions, CICS uses the MVS system authorization facility (SAF) to route authorization requests to an external security manager (ESM), such as RACF , at appropriate points within CICS transaction processing.
CICS manages application programs, the application data, and the application output. To prevent disclosure, destruction, or corruption of these assets, you must first safeguard the CICS system components themselves.
There are two distinct areas from which exposures to the CICS system can arise.
The first of these is from sources external to CICS. You can use RACF data set protection as the primary means of preventing unauthorized access, from either TSO users or batch jobs, to the assets CICS manages.
The other potential area of exposure arises from CICS users. CICS provides a variety of security and control mechanisms that can limit the activities of CICS users to only those functions that any particular individual user is authorized to use:
Transaction security ensures that users that attempt to run a transaction are entitled to do so
Resource security ensures that users who use CICS resources are entitled to do so
Command security ensures that users who use CICS system programming commands are entitled to do so
Each CICS region authenticates users and incoming communication, and authorizes access to the resources of that system. The security service that a CICS region provides consists of authorization and authentication services. You can enhance or replace authorization services by using an External Security Manager (ESM) that is called from CICS. Similarly, you can enhance or replace authentication services by using an External Authentication Manager (EAM) that is called from CICS.
To find out what CICS information RACF has about you, the syntax is LISTUSER your-userid CICS NORACF
CICS authentication depends on user definitions that are defined in:

• The CICS runtime database
• The EAM, External authentication manager which allows the user’s login and password to be authenticated from an external authentication source, such as Windows Active Directory, RACF, or LDAP

CICS authorization depends on the user definitions and attributes of other resource definitions that are defined in:

• The CICS runtime database
• The ESM – External Security manager is to authenticate CICS users and to authorize access to CICS transactions and other resources

External authentication manager

Administrators can use an External Authentication Manager (EAM) as an alternative, or as an addition to, local CICS user authentication that uses user definitions in the CICS runtime database. EAM is a user-supplied program. It allows CICS users to authenticate by using a user ID and password that are defined in an external source. That external source can be Windows Active Directory, RACF®, LDAP, or any other authentication manager. CICS provides a sample EAM module to demonstrate the interface to which you need to conform if you are going to write your own EAM.
If you change the EAM during the life of a region, you must perform a warm start to make the EAM valid for all application servers. Otherwise, the changed EAM applies only to tasks that are running under application servers that were started after the EAM was changed. Such a condition can cause inconsistencies in authentication in the region.
When user authentication is required and an EAM is available, initial authentication is performed through the EAM. If the EAM fails to authenticate the user, it can optionally return a response code that tells CICS to check the user definitions that are in CICS runtime database. Therefore, users primarily come from the EAM definitions, but some users who must be present can still be defined locally to CICS in the UD definitions.

External Security manager

Administrators can use an External Security Manager (ESM) instead of, or with, CICS internal security to authenticate CICS users and to authorize access to CICS transactions and other resources. The ESM is a user-supplied program that allows you to define your system’s own security mechanism for preventing unauthorized access to resources from application programs, and the unauthorized initiation of CICS transactions.
Note: CICS provides a sample ESM module to demonstrate the interface to which you need to conform if you choose to write your own ESM. To use an External Security Manager instead of CICS, you need to Change the Region Definitions (RD) ESM Load attribute to yes.
You must identify the ESM to the CICS region at startup; you might also need to identify the CICS region to the ESM.
CICS passes information about the user, transaction, and resource to the ESM. The ESM uses this to determine whether authorization is allowed. The CICS region must then be informed, through the interface, of the ESM’s authorization decision.
If you change the ESM during the life of a region, you must perform a warm start to make the ESM valid for all application servers. Otherwise, the changed ESM applies only to tasks that are running under application servers that were started after the ESM was changed. This condition can cause inconsistencies in security within the region.
You should design your ESM so that it stores its data separately from the program itself. You can then access security data at all times, without needing to restart CICS.

CICS-RACF interface

In CICS Transaction Server for z/OS, Version 5 Release 2, the only form of security CICS supports is that provided by an external security manager (ESM), such as RACF. CICS uses, by means of the RACROUTE macro, the MVS system authorization facility (SAF) interface to route authorization requests to RACF.
MVS router exit.
CICS issues the RACROUTE macro, which invokes the MVS router. The MVS router calls the MVS router exit (ICHRTX00) If the MVS router exit’s return code is zero, the MVS router calls the RACF router; the RACF router calls the external security manager (RACF in this example). The security manager may call its own user exits. The MVS router returns control to CICS. Remember that CICS by means of the RACROUTE and SAF interface to route authorization requests to RACF.

RACF functionality – How does it work?

RACF protects resources by granting access only to authorized users of the protected resources. RACF retains information about the users, resources, and access authorities in profiles on the RACF database and refers to the profiles when deciding which users should be permitted access to protected system resources.
To accomplish its goals, RACF gives you the ability to:

•  Identify and authenticate users
•  Authorize users to access the protected resources
•  Log and report various attempts of unauthorized access to protected resources
•  Control the means of access to resources
•  Allow applications to use the RACF macros

Before moving to the below part, administrator should know the below terms.

• User ID
  This is used to identify an individual task or person. Normally RACF IDs will auto revoke after 30 days consecutive days of non-use and will auto-delete after further 60 days – on total 90 days.
• Groups
  A group profile defines a group of users. A group profile can contain information about the
  group, such as who owns it; what subgroups it has; a list of connected users
• Datasets
  In the context of IBM mainframe computers, a data set (archaic) or dataset (preferred) is a computer file having a record organization. Use of this term began with OS/360 and is still used by its successors, including the current z/OS.
• Resources
  Virtually everything in mainframe is a resource. Resources are categorized using classes. The profiles under classes are called resources.

Identifying and Authenticating Users

For a software access control mechanism to work effectively, it must be able to:
1. Identify the person who is trying to gain access to the system
2. Authenticate the user by verifying that the user is really that person
RACF uses a user ID to identify the person who is trying to gain access to the system and a password to authenticate that identity. RACF uses the concept of only one person knowing a particular user ID and password combination to verify user identities and to ensure personal accountability.
RACF identifies and authenticates users accessing the system when the various system resource managers (such as job initiation) request it.
RACF determines:

•  If the user is defined to RACF
• If the user has supplied a valid password, Pass Ticket, or operator identification card (OIDCARD), and a valid group name
• If the user’s UID and GID are valid on OS/390 UNIX.
•  If the user ID is in REVOKE status, which prevents a RACF-defined user from entering the system at all or entering the system with certain groups
•  If the user can use the system on this day and at this time of the day (an installation can impose restrictions)
•  If the user is authorized to access the terminal (which can also include day and time restrictions for accessing that terminal)
• If the user is authorized to access the application

After it has authenticated the user’s identity, RACF specifies the scope of the user’s authorization for the current terminal session or batch job.

Checking Authorization

After identifying and authenticating the user, RACF controls interaction between the user and the system resources. RACF must authorize:
1. Which users may access resources
2. How the user may access them, such as for reading or for updating
RACF can also authorize when a user can access resources, by either time or day.
Before you can access a resource, RACF:
1. Checks the profiles to determine whether you are authorized to access the resource.
2. Checks the security classification of the user and data.

•  First, RACF compares the security levels in the user and resource profiles. If the resource
  has a higher security level than the user, RACF denies the request.
•  Next, RACF compares the list of categories in your user profile with the list of categories in
  the resource profile. If the resource profile contains a category that is not in the user’s
  profile, RACF denies the request.

3. Gives you access to the resource if you satisfy any of a number of conditions, such as:

•  The resource is a data set and the high-level qualifier is your user ID.
• Your user ID is in the access list with sufficient authority.
•  Your current connect group is in the access list with sufficient authority.
• The universal access authority (UACC) is sufficiently high.

In Addition: RACF also provides global access checking. This allows you to establish a system-wide in-storage table of default authorization levels for selected resources.

Logging and Reporting

RACF maintains statistical information, such as the date, time, and number of times that a user enters a system and the number of times a specific resource was accessed by any one user. RACF also writes security log records when it detects:

• Unauthorized attempts to enter the system
• Authorized or unauthorized attempts to access RACF-protected resources
• Authorized or unauthorized attempts to enter RACF commands

You can list the contents of these records. You can use them to help you to detect possible security exposures or threats. You can verify the security of the system. Each of the following programs can help you accomplish your goals, depending on your specific needs:
. SMF data unload utility
. RACF report writer
. Data security monitor (DSMON)

User Attributes

User attributes are extraordinary capabilities, limitations, or environments that can be assigned to a
user either all of the time or when the user is connected to a specific group or groups. When an
attribute is to apply all of the time, it is specified at the system level and is called a user attribute. When an attribute is to apply only to a specified group or groups, it is specified at the group level and is called a group-related user attribute. For example, user attributes that you specify in an ADDUSER or ALTUSER command are stored in the user’s profile and are in effect regardless of the group to which the user is connected.
The user attributes are:

• SPECIAL
• AUDITOR
• OPERATIONS
• REVOKE
• RESTRICTED

The SPECIAL Attribute

A user who has the SPECIAL attribute can issue all RACF commands. The SPECIAL attribute gives the user full control over all of the RACF profiles in the RACF database.
The SPECIAL attribute can be delegated only by a user who has the SPECIAL attribute. It should be
limited to the RACF security and group administrators. Persons having the SPECIAL attribute should be required to use operator identification cards and passwords or password phrases, and should change their passwords or password phrases often to help ensure security.

The AUDITOR Attribute

A user who has the AUDITOR attribute has the authority to specify logging options on the ALTDSD,
ALTUSER, RALTER, and SETROPTS commands. In addition, the auditor can list auditing information using the LISTDSD, RLIST, LISTUSER, LISTGRP, and SEARCH commands. The AUDITOR attribute gives the auditor control of logging to the SMF data set. Logging to SMF helps to detect changes (or attempted changes) to the RACF database and accesses (or attempted accesses) of RACF-protected resources. The user who has the AUDITOR attribute can list all of the profile information that is available to the SPECIAL user, as well as information that is available to auditors. Note, however, that this extended listing authority does not give the auditor additional access to protected data or additional authority to change information in the RACF database.

The OPERATIONS Attribute

A user who has the OPERATIONS attribute has full access authorization to all RACF-protected resources in the DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE, and VMRDR classes.

The REVOKE Attribute

You can prevent a RACF user from entering the system by assigning the REVOKE attribute on the
ALTUSER command. This attribute is useful when you want to prevent a user from entering the system but you cannot use the DELUSER command because the user still owns RACF resource profiles. You can also assign the REVOKE attribute on a group level by using the CONNECT command.
If the user has the REVOKE attribute for a group, the user cannot enter the system by connecting to that particular group, or access resources as a member of that group.

The RESTRICTED Attribute

You can prevent RACF users from gaining access to protected resources they are not specifically
authorized to access by assigning the RESTRICTED attribute on the ADDUSER or ALTUSER command.

RACF Password Rules and commands in common

The user password should be exactly 8 characters in length and it should have a numeric character. It should not match last 8 passwords which used already
User ID commands:
Add user: –
ADDUSER User_ID OWNER(ZZZ) DFTLGRP(DDD) NAME(‘USER NAME’) + Password(behappy2) DATA(‘FILE RECORD=111111’)
Purpose:
Use the ADDUSER command to define a new user to RACF and establish the user’s relationship to an existing RACF-defined group. The command adds a profile for the new user to the RACF database and creates a connect profile that connects the user to whichever default group you specify.
The user profile consists of a RACF segment and, optionally, other segments such as a TSO segment, an OMVS segment. You can use this command to define information in any segment of the user’s profile. Although user ID association information is in the user’s profile, you must use the RACLINK command to define a user ID association.
ALTUSER
ALTUSER User_ID Password(behappy2)
Purpose:
Use the ALTUSER command to change the information in a user’s profile, including the user’s systemwide attributes and authorities. The user profile consists of a RACF segment and, optionally, other segments such as a TSO segment. You can use this command to change information in any segment of the user’s profile. When you change a user’s level of authority in a group (using the AUTHORITY operand), RACF updates the appropriate group profile. When you change a user’s default universal access authority for a group (using the UACC operand), RACF changes the appropriate connect profile.for all other changes, RACF changes the user’s profile.
DELUSER
DELUSER User_ID
Purpose: Use the DELUSER command to delete a user from RACF. This command removes the user’s profile and all user-to-group connections for the user. (The connect profiles define the user’s connections to various RACF groups.)

RACF Group commands:

LISTGRP – to list details of specific RACF group profiles.
ADDGROUP – to define a new group to RACF
ALTGROUP – Multiple purpose
DELGROUP – Delete a group and its relationship to its superior group from RACF
CONNECT userid GROUP(group)
REMOVE userid GROUP(group)
LISTGRP
LISTGRP Group_ID
ADDGROUP
ADDGROUP TEST1 OWNER(ZZZ) SUPGROUP(AAA) DATA(‘TEST’)
ALTGROUP
ALTGROUP TEST1 OWNER(AAA) SUPGROUP(BBB) DATA(‘TEST’)
Use the ALTGROUP command to change:
– The superior group of a group
– The owner of a group
– The terminal indicator for a group
– A model profile name for a group
– The installation-defined data associated with a group
– The default segment information for a group (for example OMVS)
DELGROUP
DELGROUP Group_name
Connecting user ID to a group
CONNECT user GROUP(group) OWNER(group)
Purpose: To connect a user to a group, modify a user’s connection to a group, or assign the group-related user attributes. If you are creating a connection, defaults are available as stated for each operand. If you are modifying an existing connection, no defaults apply.
Remove user ID from a group
REMOVE user GROUP(group)
Purpose: To remove a user from a group, and to assign a new owner to any group data set profiles the user owns on behalf of that group.

DATASET Profiles

In the context of IBM mainframe computers, a data set (archaic) or dataset (preferred) is a computer file having a record organization. Use of this term began with OS/360 and is still used by its successors, including the current z/OS. Documentation for these systems historically preferred this term rather than file.

Access Levels

There are five access levels that an administrator can grant to a dataset in RACF.
NONE – The user can have any access to the data.
READ – The user can view the data.
UPDATE/CONTROL – The data can be updated, but the file cannot be deleted.
ALTER – The user has complete control of the data.

Dataset profile commands

Below are the commands which work on datasets
LISTDSD – List dataset profile
ADDSD – Add dataset profile
ALTDSD – Alter dataset profile
DELDSD – Delete dataset profile
PERMIT – Give access.
LISTDSD
LISTDSD DA(‘HLQ.1LQ.2LQ’)
Purpose:
Use the LISTDSD command to list information included in tape and DASD data set profiles. A data set
profile consists of a RACF segment and. The LISTDSD command provides you with the option of listing information contained in the entire data set profile (all segments), or listing the information contained only in a specific segment of the profile.
You can request the details for any number of profiles by giving the full name of each profile. You can also request the details for all profiles whose names are qualified by specific user IDs, group names, or character strings.
You can use the LISTDSD command to cause the changes to go into effect for the generic profiles after issuing the ADDSD, ALTDSD, or DELDSD commands. LISTDSD places a new copy of the profile in the user’s address space.
ADDSD
ADDSD ‘profile’ GENERIC OWNER(AAA) AUDIT() LEVEL(99) UACC(NONE)
Purpose:
Use the ADDSD command to add RACF protection to data sets with either discrete or generic profiles. Changes made to discrete profiles take effect after the ADDSD command is processed.
ALTSD
ALTSD ‘profile name.* PARAMETERS
Purpose:
– Modify an existing discrete or generic data set profile.
– Protect a single volume of either a multivolume tape data set or a multivolume, non- VSAM DASD data set. (At least one volume must already be RACF-protected.)
– Remove RACF-protection from either a single volume of a multivolume tape data set or a single volume of a multivolume, non-VSAM DASD data set. (You cannot delete the last
volume from the profile.)
PERMIT – to grant OR remove access to a user to a dataset
PERMIT ‘DATASET.*’ ID(AAA) ACCESS(ALTER)

Resources

Virtually everything in mainframe is a resource. Resources are categorized using classes. The profiles
under classes are called resources. RACF is used to protect functions as well as data.
These protect commands, output, access to terminals, access to crypto functions, programs etc…
Commands used on Resources
RLIST – List resource profile
ADDSD – Add resource profile
ALTDSD – Alter resource profile
DELDSD – Delete resource profile
PERMIT – Give access.
RLIST
RLIST CLASSNAME RESOURCENAME GEN ALL
Purpose:
 Use the RLIST command to display information on resources belonging to classes specified in the class descriptor table.
 This command lists the information in an existing profile for the resource or resource group.
 The details that are given for each profile are:
 The resource class.
 The name of the resource.
 The cross-reference class name (that is, the member class name for resource groups or the
group name for non-group resources).
 If the resource named in the command (in the resource-name operand) is a resource group,
 RACF lists member resources.
 The level of the resource.
 The owner of the resource.
 The type of access attempts (as specified by the AUDIT operand on the RDEFINE or RALTER
command) that are being logged on the SMF data set.
 The user, if any, to be notified when RACF uses this profile to deny access to the resource.
 The universal access authority for the resource.
 Your highest level of access authority to the resource.
 The installation-defined data (information specified in the DATA operand of the RALTER or
RDEFINE commands).
 The APPLDATA value, if any. If your z/OS installation is configured to be a multilevel-secure
environment, this information is not listed in your output. * SUPPRESSED * appears under the
 installation data field. Only those with SPECIAL are allowed to list the field.
 The status of the WARNING/NO WARNING indicator.

Sub parameters:

ALL
AUTHUSER
GENERIC
HISTORY
NORACF
STATISTICS
RDEFINE
RDEFINE CLASSNAME RESOURCENAME GEN UACC(NONE) PARAMETERS
Purpose:
Use the RDEFINE command to:
 Define to RACF all resources belonging to classes specified in the class descriptor table.
 Create entries in the global access checking table.
 Define security categories and security levels.
 Define classes (as profiles in the RACGLIST class) for which RACF saves RACLIST’ed results
on the RACF database.
 Define the attributes of classes in the dynamic class descriptor table.
 Define a custom field and its attributes.
The RDEFINE command adds a profile for the resource to the RACF database in order to control access to the resource. It also places your user ID on the access list and gives you ALTER authority to the resource unless SETROPTS NOADDCREATOR is in effect.
You cannot use the RDEFINE command to define users, groups, data sets, certificates, certificate key
rings, or certificate mappings.
To have changes take effect after defining a generic profile if the class is not RACLISTed by either the
SETROPTS RACLIST or RACROUTE REQUEST=LIST, GLOBAL=YES, one of the following steps is required: