REXX RACF 是什么?在 z/OS REXX 中如何调用 RACF 做安全控制
REXX RACF 不是某个单独的产品，而是指在 z/OS 的 REXX 脚本中访问或调用 RACF（Resource Access Control Facility）安全功能的一类做法：用 REXX 发起权限检查、读取用户/组信息，或让脚本按调用者的权限决定是否继续。它适合需要在自动化脚本里做“这个人/这个作业能不能碰这份资源”判断的场景。前提是所在 z/OS 系统已启用 RACF（或兼容的安全产品），且脚本运行环境允许发起安全调用。REXXTOOLS/MVS 这类第三方扩展属于另一层：它扩展 REXX 的接口能力，但本身不是 RACF。
RACF 在 z/OS 上管什么
RACF 是 z/OS 的安全服务器，核心是围绕“主体—资源—权限”做授权：
- 用户与组：每个用户有 userid，归属一个或多个 group，组是批量授权的基本单位。
- 数据集：对数据集（如
USER1.DATA.PDS）按 READ、UPDATE、ALTER 等访问级别授权。 - 通用资源：对非数据集资源（如某子系统、某命令、某服务）用资源类（如 FACILITY、OPERCMDS）加 profile 控制。
- 权限判定：访问时 RACF 按用户、组、profile 的规则决定允许还是拒绝。
REXX 脚本要做的“安全控制”，本质就是让脚本在动作前先问 RACF：当前用户对目标资源有没有足够权限。
REXX 调用 RACF 的常见方式
| 方式 | 说明 | 适用场景 |
|---|---|---|
| 外部命令 | 通过 TSO/E 命令或批处理命令间接触发 RACF 相关功能 | 脚本里做简单查询或管理动作 |
| RACROUTE 宏 | RACF 的底层编程接口，通常由汇编或高级语言调用 | 需要精确控制安全调用时 |
| 语言/环境接口 | 借助 REXX 可用的系统服务或扩展接口发起安全请求 | 在 REXX 内直接做权限判断 |
| 第三方扩展 | 如 REXXTOOLS/MVS 提供的接口与设施，扩展 REXX 可实现的应用程序范围 | 需要更丰富访问方法接口时 |
需要区分：通用“REXX RACF”讲的是在 REXX 里用 RACF 做安全判断；REXXTOOLS/MVS 是 Open Software Technologies 的 REXX 扩展产品，定位是“扩展 REXX 可实现的应用范围”，提供访问方法接口和生产力扩展，不是 RACF 本身，也不替代 RACF。
一个检查数据集 READ 权限的示例思路
目标：脚本在读取某数据集前，先确认当前用户有 READ 权限。
- 确定输入：目标数据集名（如
PROD.CONFIG.DATA）、当前用户 userid。 - 发起权限检查：通过 RACF 提供的调用方式，请求对该数据集做 READ 级别的访问判定。
- 读取返回码：RACF 返回允许或拒绝。REXX 侧根据返回码分支。
- 按结果动作：允许则继续读取；拒绝则记录并退出，不尝试绕过。
伪代码结构（示意，具体调用语法取决于所用接口）：
/* 示意：检查当前用户对目标数据集是否有 READ 权限 */
dataset = 'PROD.CONFIG.DATA'
call CheckAccess dataset, 'READ'
if rc = 0 then
say '有 READ 权限，继续处理'
else
say '权限不足，终止'
exit 8
验证方法：用一个确实有权限的 userid 和一个明确无权限的 userid 分别跑，确认脚本在两种情况下走不同分支。这样能证明检查逻辑真的生效，而不是恒返回允许。
常见失败原因
- 权限不足：调用者本身没有对目标资源的权限，检查自然返回拒绝。
- RACF 未启用或未激活：系统未运行 RACF 或安全环境未就绪，安全调用无法按预期工作。
- 地址空间或环境限制：脚本运行所在的环境（如某些受限地址空间）不允许发起安全调用。
- 资源类未激活：对通用资源的检查，如果对应资源类没激活，判定结果可能不符合预期。
- 接口用错：把第三方扩展的接口当成 RACF 原生接口，或反之，导致调用失败。
怎么选：原生方式还是第三方扩展
- 只需要做基本的权限判断、用户/组查询：优先用系统原生的 RACF 调用方式，依赖少、可控。
- 需要更丰富的访问方法接口、想把 REXX 用在对接口能力要求更高的应用里：可以评估 REXXTOOLS/MVS 这类扩展，但要清楚它扩展的是 REXX 能力，安全判定仍由 RACF 负责。
- 无论哪种，先确认系统已启用 RACF、脚本环境允许安全调用，再决定具体实现路径。