RACF Security Audit Checklist: LISTUSER, RLIST, SETROPTS, and SMF

Check access before changing RACF audit settings.

Last updated: August 31, 2026

A RACF audit normally starts with a simple question: which IDs, groups, datasets, resources, and audit options can explain the access seen in production? The answer is usually spread across user profiles, group connections, dataset profiles, general resource classes, SETROPTS options, and SMF records. This guide gives a practical review path for a security administrator, auditor, or mainframe developer supporting a production issue.

The examples use common RACF TSO commands such as LISTUSER, LISTDSD, RLIST, SEARCH, and SETROPTS LIST. Run commands only with the authority approved at your site, and raise a change record before altering audit settings in production.

What A RACF Security Audit Should Check

A useful RACF security audit checks the path from identity to evidence. Start with the user ID, then confirm group authority, direct dataset or resource access, global RACF settings, and the SMF records that prove what happened. That order keeps the review tied to an actual access path instead of a loose list of profiles.

Audit area	RACF command or source	What to review
User profile	LISTUSER userid ALL	Special attributes, owner, default group, revoke date, password settings, and user audit flags.
Group membership	LISTGRP group-name ALL	Connected users, group authorities, owners, and nested group control.
Dataset profile	LISTDSD DATASET('HLQ.**') ALL	Universal access, access list entries, audit options, and owner.
General resource	RLIST class profile ALL	Access to FACILITY, OPERCMDS, JESJOBS, APPL, STARTED, and other active classes.
Audit controls	SETROPTS LIST	Active classes, logging controls, generic profile options, and global audit settings.
Event proof	SMF type 80 records	Permit, violation, profile change, and other security events recorded by RACF.

Start With The User ID

For an access review, begin with the user profile. A single user ID can inherit authority from a default group, connected groups, OPERATIONS, SPECIAL, group-SPECIAL, AUDITOR, or group-AUDITOR. That is why a clean audit note should show both the user profile and the group path that grants access.

LISTUSER JDOE ALL
LISTGRP PAYROLL ALL

Check for high-risk attributes first. SPECIAL can administer RACF widely, OPERATIONS can affect dataset access, and AUDITOR can list many profiles and set some audit controls. IBM documents separate behavior for AUDITOR and group-AUDITOR attributes, so do not treat group-level auditor authority as the same thing as system-wide auditor authority.

Review Dataset And Resource Access

Most application access checks involve either datasets or general resources. Dataset profiles protect names such as PAYROLL.PROD.MASTER, while general resources protect class/profile pairs such as FACILITY BPX.SUPERUSER or an application profile in APPL.

LISTDSD DATASET('PAYROLL.**') ALL
RLIST FACILITY BPX.SUPERUSER ALL
RLIST OPERCMDS MVS.MCSOPER.* ALL

Look at UACC, access list entries, conditional access, warning mode, and audit options. A profile with UACC(READ) may be acceptable for a public reference library, but it is a red flag for payroll, cardholder, health, or privileged operational data. If a profile uses warning mode, access might be allowed while RACF logs a warning event, so include it in the risk note.

Use SEARCH Carefully

SEARCH is useful when you know part of a profile name but not the exact entry. It can also create command output for a follow-up review. Keep the scope tight; broad searches can return a large amount of output and slow down the audit.

SEARCH CLASS(DATASET) MASK(PAYROLL) CLIST
SEARCH CLASS(FACILITY) MASK(BPX) CLIST

IBM notes in its RACF listing guidance that command output can become very large and that the displayed output is not a supported programming interface. For automated reporting, use the RACF database unload utility IRRDBU00 rather than scraping terminal output.

Check SETROPTS Audit Controls

SETROPTS LIST shows active classes and many RACF-wide options. During a review, use it to confirm whether relevant classes are active, whether generics are enabled, and which audit controls are active for the classes under review.

SETROPTS LIST
SETROPTS AUDIT(USER GROUP DATASET FACILITY)

The second command changes audit controls and should only be used by an authorized security administrator under site procedure. For review-only work, list the current settings and attach the evidence to the ticket. IBM’s RACF documentation covers setting and listing audit controls and listing specific audit controls.

When To Use UAUDIT

UAUDIT records selected RACF activity for a user. It is useful for a short investigation window, for example when an ID is used by a batch process and the team needs to prove which protected resources it touches. Do not leave user-level auditing active forever without a reason, because it can add noise to the security event stream.

ALTUSER JDOE UAUDIT
LISTUSER JDOE ALL

After the review window ends, remove the setting if your approved procedure requires it. Keep the before-and-after listing with the incident or change ticket so another reviewer can see exactly when user auditing was enabled.

Read The Evidence In SMF Records

RACF security decisions and profile changes are recorded in SMF, especially type 80 records. Depending on your site and security products, type 81 and type 83 records can also matter. The audit report should identify which SMF extract was reviewed, the time range, and the event types found.

For RACF, an SMF extract can answer questions that profile listings alone cannot answer: did the access happen, was it allowed or denied, which profile matched, and which user or started task made the request? IBM provides reference material for SMF records and reformatted RACF SMF records.

Sample RACF Audit Checklist

Use this checklist when a production owner asks, “Can this ID access this resource?” It keeps the review small enough to finish, but it still captures the evidence a second reviewer needs.

1. Record the user ID, group, dataset or resource name, system, LPAR, and time window.
2. Run LISTUSER userid ALL and note special attributes, revoke status, owner, and default group.
3. Run LISTGRP group ALL for the default group and any connected group that may grant access.
4. Run LISTDSD or RLIST for the exact profile and any covering generic profile.
5. Run SETROPTS LIST to confirm class activation, generic profile handling, and audit settings.
6. Pull SMF type 80 records for the review window and compare events with the profile listings.
7. Write the finding as allowed, denied, allowed by warning, or unresolved because the matching profile or SMF extract is missing.

Common RACF Audit Findings

Access Comes From A Group, Not The User ID

A user may not appear directly on a profile access list but still gain access through a connected group. Always capture the group connection, group authority, and profile access entry in the finding.

The Generic Profile Is The Real Match

A dataset such as PAYROLL.PROD.MASTER may be protected by PAYROLL.** rather than an exact profile. Review both exact and generic coverage before deciding that access is missing.

Warning Mode Hides A Future Failure

Warning mode can allow access while recording that access would fail if warning mode were removed. Treat that as a migration or cleanup issue, not as proof that the rule is permanently acceptable.

Internal Reading

For related Mainframe Forum topics, review mainframe security trends, the z/OS operating system, Db2 command reference patterns, and Db2 application environment controls. The Db2 articles are not RACF references, but they show the same production habit: list the running environment, prove the access path, and record the exact command output used for review.

FAQ

Which RACF command lists a user profile?

Use LISTUSER userid ALL. Review the default group, connected groups, special attributes, revoke status, owner, and any user audit setting.

Which RACF command lists dataset access?

Use LISTDSD DATASET('dataset-name') ALL for a dataset profile. For broad review work, confirm whether a generic profile such as PAYROLL.** protects the target dataset.

Where does RACF write security audit events?

RACF writes security events to SMF records, especially type 80. Your site may also review other SMF record types depending on the security setup and reporting tools.

Should I parse LISTUSER or RLIST output in a program?

For repeatable reporting, use RACF database unload data such as IRRDBU00. Terminal command listings are useful for human review, but they are not the best source for a production reporting program.

A good RACF audit note is short, repeatable, and evidence-based: user profile, group path, protected profile, SETROPTS context, and SMF event proof.

What Is z/OS? The Operating System Running the World's Banks and ATMs

z/OS explained.

Right now, as you read this, someone somewhere is withdrawing cash from an ATM. A traveler is checking a flight status. A hospital is pulling up patient history. Various banks are processing millions of transactions at the same time in the background. All of that is handled by an operating system most people have never heard of: z/OS.

z/OS does not run on your laptop and it does not run in the cloud. It runs on a machine called a mainframe, and it quietly powers the most critical infrastructure on the planet. 95% of the world's ATM transactions, 87% of all credit card transactions, and over 30 billion transactions processed every single day are handled or supported by z/OS.

In this guide, we answer one question: what exactly is z/OS, and why does the world still depend on it in 2026?

What is an operating system?

In plain terms, an operating system is software that sits between the hardware and everything else. It manages memory, runs programs, controls storage, and makes sure everything works together. Windows, Linux, and macOS are all operating systems, and they're broadly designed for the same kind of workload: one user, or a handful of users, doing general-purpose computing on commodity hardware.

How is z/OS different from Windows or Linux?

z/OS was designed for IBM Z series mainframe computers, and it was not built for general-purpose computing. It was built for one very specific use case: running a high volume of transactions simultaneously, reliably, with zero downtime.

To put that in perspective: a single commodity Linux server might handle a few thousand transactions per second, or tens of thousands if it's well tuned. A well configured cloud cluster can push further. A single IBM Z mainframe running z/OS can process over 1 million transactions per second, on its own, while simultaneously running batch jobs in the background, managing terabytes of data, enforcing security policies, and producing audit logs for everything that happens.

That number matters when people say mainframes are outdated: 1 million transactions per second from a single machine, with 99.999% availability, meaning less than 5 minutes of downtime per year. The world's biggest banks haven't moved their core banking applications off this platform because of nostalgia. It's because nothing else does what z/OS does at that scale.

The history of z/OS

Understanding z/OS means understanding its history, and it's a genuinely remarkable story.

• 1964: IBM announces System/360, a family of computers designed to cover everything from small business to scientific research on a single compatible architecture. Before this, every computer was essentially on its own, software built for one machine did not run on another.
• OS/360 is built to run System/360, introducing concepts still in use today: jobs (units of work submitted to the system), batch processing (work that runs overnight and produces results by morning), and JCL, or Job Control Language.
• 1974: MVS (Multiple Virtual Storage) arrives, introducing virtual memory and making z/OS-style multitasking possible.
• 1980s: Further expansion massively increases how much memory the system can work with.
• 1990: IBM adds native Unix compatibility, a full Unix environment built directly into the platform.
• 1995: OS/390 arrives as a major refresh.
• 2001: IBM releases z/OS, named after the IBM Z hardware it runs on, bringing 64-bit addressing, improved scalability, and a tighter connection between software and hardware.

Today, z/OS continues to receive updates: container support, cloud integration, and AI workload capabilities. Every major bank running z/OS today has been building on this platform since the 1970s or 80s. Their core business logic, how accounts work, how transactions are checked, how risk is managed, is embedded in systems that have been running and improving for over 40 years. That's not legacy debt. That's decades of battle-tested engineering.

How z/OS actually works

z/OS is built around two types of work: batch processing and online transaction processing.

Batch processing happens in the background, usually overnight. Think about what a bank needs to do every night: calculate interest on millions of accounts, generate statements, reconcile transactions, run fraud detection across the day's activity. None of that needs to happen in real time, so it gets bundled into jobs, defined using JCL, submitted to the system, queued, executed, and reported on. The component that manages this is JES, the Job Entry Subsystem, the traffic controller for batch work.

Online transaction processing is completely different. When you tap your card at a shop, a transaction fires in milliseconds, hits the bank's system, and z/OS handles it through CICS, the Customer Information Control System. CICS manages thousands of concurrent requests in real time, looks up the account in DB2 (IBM's relational database), validates the transaction, updates the record, and returns a response, all in under a second.

Here's what makes z/OS extraordinary: both of these happen at the same time, on the same machine, on the same operating system, without either workload slowing the other down. That's possible because of the Workload Manager (WLM), which watches CPU, memory, and storage usage and allocates resources based on defined priorities, rebalancing thousands of times per second.

Underneath all of this is z/OS's memory model. Every program runs in its own isolated address space and cannot access another program's memory. If one application has a bug, even a serious one, it cannot bring down the rest of the system. This containment is a major reason z/OS achieves 99.999% availability, not because nothing ever goes wrong, but because when something does, the system contains it, recovers, and keeps working.

The hardware matters too. The IBM Z processor is a custom chip with dedicated circuits for cryptography, data compression, and transaction processing. The hardware and operating system are co-designed as a single system, which is part of why z/OS's performance can't simply be replicated on different hardware.

Key components of z/OS

• JES (Job Entry Subsystem): Makes batch processing possible. Receives submitted JCL jobs, assigns a job number, queues and schedules them, and captures the output (called SYSOUT) once complete.
• RACF (Resource Access Control Facility): Handles security. Every login, every read or write, every program execution, every command goes through RACF, which checks it against a database of users, groups, and permissions, and logs everything.
• DFSMS (Data Facility Storage Management Subsystem): Automatically manages data across hot, warm, and cold storage tiers, handling backup and recovery without requiring an army of storage administrators.
• CICS (Customer Information Control System): The middleware that makes online transaction processing possible, receiving requests, routing them to the right program, managing access to shared data, and returning a response.
• DB2 for z/OS: IBM's relational database, deeply integrated with CICS and RACF, scaled to transaction volumes that would be impossible on standard database systems.

z/OS vs Linux vs Windows

Factor	Windows	Linux (enterprise)	z/OS
Reliability	~99.9% (about 8 hours downtime/year)	~99.99% (about 50 minutes downtime/year)	99.999% (under 5 minutes downtime/year)
Scalability	Horizontal (add more servers)	Horizontal (add more servers)	Vertical (add processors/memory to one machine, no network latency between components)
Security	Strong	Strong	Centralized, auditable, fine-grained access control (RACF), decades of regulated-industry trust
Cost	Lower hardware/license cost	Lower hardware/license cost	Higher upfront cost, often lower total cost at scale once staffing, downtime, and risk are factored in

z/OS isn't trying to compete with Linux for web applications or developer tooling, and Linux isn't trying to process 1 million banking transactions per second on a single machine. They're different tools built for different jobs, and the world needs both.

Is z/OS still used in 2026? What about the cloud?

Yes, and increasingly the question isn't "cloud or mainframe," it's "mainframe and cloud." IBM has invested heavily in making z/OS a cloud-connected platform. Modern z/OS environments run Linux containers alongside mainframe workloads on the same hardware, expose mainframe data and services through REST APIs, and integrate with hybrid cloud platforms like IBM Cloud and Red Hat OpenShift.

The pattern in large enterprises: keep core transaction processing on z/OS, where it has always run, and use the cloud for everything around it, analytics, customer-facing applications, AI workloads, and development environments. The mainframe becomes the reliable core of a hybrid architecture, not a legacy system waiting to be replaced.

Are z/OS careers worth pursuing?

The mainframe skill shortage is real, and it's getting worse. The generation of engineers who built and maintain these systems is retiring, and the number of graduates entering the field is small, while demand for z/OS expertise isn't going anywhere, because the systems themselves aren't going anywhere.

Roles like z/OS system programmer, CICS developer, DB2 DBA, JCL developer, and mainframe security analyst consistently command higher salaries than equivalent roles in mainstream technologies, with significantly less competition for those roles. For developers looking for a differentiator in a market flooded with JavaScript and Python engineers, z/OS is one of the smartest skills to learn.

Summary: what is z/OS?

z/OS is an operating system that quietly runs the world. It processes more transactions every day than any other system on the planet. It achieves a level of reliability no other platform has matched, it has evolved continuously for over 50 years, and it isn't going anywhere. If you work in enterprise technology, or want to, understanding z/OS isn't optional. It's foundational.

Watch the full breakdown here: What is z/OS? The Operating System Running The World

JCL Data Set Protection: RETPD, EXPDT, DISP, and RACF Basics

Check protection before the job runs.

Last updated: August 31, 2026

A batch job can delete, keep, catalog, or overwrite a data set based on one DD statement. That is why JCL data set protection is not only a security topic. It is also a job-control topic. A small mistake in DISP, RETPD, or EXPDT can keep a file longer than expected, remove it too early, or let the wrong job try to update it.

This guide explains the basic checks in plain English. You will see what JCL controls, what RACF controls, and what to review before a production job touches business data.

What Data Set Protection Means In JCL

In JCL, a data set is a named file used by a batch job. It might be a customer extract, a payroll file, a report, a temporary work file, or a GDG generation. Protection means three practical things:

• Only approved users and jobs should read or change the data set.
• The job should use the right disposition, such as keep, catalog, delete, or pass.
• The data set should not expire or be deleted before the business is finished with it.

JCL helps describe how the job should handle the data set. RACF or another security product decides whether the user or job has access. Storage rules decide how long the data set remains on disk or tape.

The Three JCL Fields To Check First

Field	Simple meaning	Common check
DSN	The data set name.	Confirm the job points to the right file, high-level qualifier, and GDG generation.
DISP	What the job wants to do with the file.	Check whether the job needs old, new, shared, or temporary access.
RETPD or EXPDT	How long the file should be retained.	Confirm the retention period or expiry date matches the business rule.

DISP: How The Job Handles The Data Set

DISP tells z/OS the starting status of a data set and what to do with it when the step ends. It is one of the first fields to review when a job creates or updates a file.

//INFILE   DD DSN=PAYROLL.INPUT.FILE,DISP=SHR
//OUTFILE  DD DSN=PAYROLL.REPORT.FILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),UNIT=SYSDA

In the first line, DISP=SHR means the job is sharing an existing input file. In the second example, the job creates a new output file. If the step ends normally, z/OS catalogs it. If the step fails, z/OS deletes it.

Common DISP Values

• OLD means the job needs exclusive access to an existing data set.
• SHR means the job can share an existing data set.
• NEW means the job creates a new data set.
• MOD means the job appends to an existing data set or creates it if it does not exist.

Use OLD only when the job really needs to update the data set without another job using it at the same time. Use SHR for normal read-only input where sharing is acceptable.

RETPD And EXPDT: Retention Checks

RETPD gives a retention period in days. EXPDT gives an expiry date. Both are used to protect a data set from being removed too early. They are common on output files, archive files, and files written to tape or managed storage.

//ARCHIVE  DD DSN=PAYROLL.MONTHEND.ARCHIVE,
//            DISP=(NEW,CATLG,DELETE),
//            UNIT=TAPE,
//            RETPD=90

This example asks the system to retain the archive for 90 days. A site may prefer a storage class, management class, or another local rule instead of coding retention directly in every job. Follow your site standard.

When To Use RETPD

Use RETPD when the rule is easy to express as a number of days, such as 7 days for a daily extract or 90 days for a monthly archive.

When To Use EXPDT

Use EXPDT when the business rule is tied to a date, such as a legal hold date or a fixed archive expiry date. Avoid hard-coded old dates copied from another job.

RACF: Who Can Read Or Change The Data Set

JCL does not grant security access by itself. RACF protects many kinds of z/OS data sets by using data set profiles. Those profiles can cover VSAM, non-VSAM DASD, tape data sets with standard labels, SMS-managed data sets, and GDG data sets.

A security administrator can protect a data set with a discrete profile for one data set, or a generic profile for a group of names. For example, a generic profile such as PAYROLL.** can protect many payroll data sets under the same high-level qualifier.

LISTDSD DATASET('PAYROLL.**') ALL
PERMIT 'PAYROLL.**' ID(PAYBATCH) ACCESS(READ)

The first command lists a RACF data set profile. The second command is an example of granting access. Do not run security changes unless your role and change ticket allow it.

JCL Protection Checklist Before Production

1. Check the DSN value. Make sure the job points to the intended data set.
2. Check DISP. Confirm whether the job should read, create, update, append, pass, catalog, or delete the data set.
3. Check RETPD or EXPDT. Make sure the retention rule is not copied from an unrelated job.
4. Check RACF access. Confirm the job user ID can read or update the data set profile.
5. Check GDG use. Make sure the job uses the right generation, such as (0), (+1), or (-1).
6. Check restart behavior. A restart can fail if the first run already cataloged a data set that the next run tries to create again.

Common Mistakes

Using DISP=OLD For Read-Only Input

DISP=OLD can block another job from using the same data set. If the program only reads the file, DISP=SHR may be the better choice.

Creating A File Twice After Restart

A failed job may leave a cataloged output data set behind. If the restart step tries DISP=(NEW,CATLG,DELETE) again, the job can fail because the data set already exists.

Copying RETPD From Another Job

A retention value copied from an old job may not match the current file. A 7-day report and a 7-year audit archive should not use the same retention rule.

Internal Reading

For related JCL topics, read JCL Tutorial: JOB, EXEC and DD Statements, JCL DD Statement, Generation Data Group in JCL, and RACF Security Audit Checklist.

FAQ

Does JCL protect a data set from unauthorized users?

No. JCL describes how a job wants to use the data set. RACF or another security product decides whether the job user ID has permission.

What is the difference between RETPD and EXPDT?

RETPD keeps a data set for a number of days. EXPDT uses a specific expiry date.

What does DISP=(NEW,CATLG,DELETE) mean?

It means the job creates a new data set, catalogs it if the step ends normally, and deletes it if the step fails.

Why does a restart fail when the job creates a data set?

The earlier run may have already cataloged the output data set. The restart then tries to create the same name again. Check the catalog and restart step before rerunning.

Before changing JCL in production, check the data set name, disposition, retention rule, RACF profile, and restart path together.