READPW and UPDATEPW are optional DEFINE CLUSTER keywords that attach passwords to a VSAM cluster for read and update classes of access. They predate ubiquitous external security managers, but they still appear in certification exams, in decades-old production JCL, and in textbooks that teach the complete IDCAMS grammar. A beginner should understand three things: what these keywords mean in the catalog, how they relate to OPEN in application programs, and how modern RACF profiles may make them irrelevant in practice while legacy systems still honor them. This page explains the semantics, contrasts read versus update protection, shows representative JCL, and closes with guidance about secrets management so you do not accidentally teach unsafe habits while learning historical syntax.
When DEFINE completes with READPW and UPDATEPW specified, the catalog entry for the cluster records those attributes. LISTCAT and similar reports can show that passwords are defined without printing the cleartext secret, depending on report options and authority. At OPEN time, the access method checks whether the requester presented the correct password for the requested access mode. If your program opens for INPUT only, the read password path is relevant. If it opens for OUTPUT, I-O, or EXTEND, the update path is relevant. Exact enforcement can be influenced by installation exits and security products that override or supplement native VSAM password checking, which is why testing on your own LPAR is essential before assuming textbook behavior.
| Aspect | READPW | UPDATEPW |
|---|---|---|
| Typical intent | Restrict who can browse or copy data | Restrict who can change records or load data |
| OPEN mode sketch | Relevant for INPUT, read-only browse | Relevant for I-O, EXTEND, OUTPUT that writes |
| Operational risk | Password in JCL or source code exposure | Same risk, higher blast radius if leaked |
The following example is illustrative. Do not reuse these password strings in any real environment; treat them like contaminated sample data.
12345678910111213DEFINE CLUSTER ( - NAME(USERID.LEGACY.KSDS) - INDEXED - RECORDSIZE(80 80) - KEYS(5 0) - READPW(RDSECRET) - UPDATEPW(UPSECRET)) - DATA (NAME(USERID.LEGACY.KSDS.DATA) - CYLINDERS(2 1) - VOLUMES(SYSDA)) - INDEX (NAME(USERID.LEGACY.KSDS.INDEX) - CYLINDERS(1 1) - VOLUMES(SYSDA))
If passwords are enforced, every batch step that opens the file must supply them through a supported interface. That often meant embedding secrets in JCL, which is weak auditing and weak confidentiality. External security moved those decisions into profiles attached to datasets and users, with logging when access is denied. When you migrate a legacy cluster to RACF-only protection, you might ALTER away passwords or redefine the cluster without them after validating that profiles cover all access paths including utilities such as IDCAMS REPRO and vendor file tools. Always coordinate with security administration; removing passwords without profiles can accidentally expose data.
Rotating VSAM passwords historically required an ALTER step and coordinated application redeployments. RACF-centric designs instead rotate access through group membership and profile changes. If you still maintain VSAM passwords, treat rotation as a full-stack change: catalog, CICS FCT entries, batch JCL, scheduler vaults, and disaster recovery clones must all match or jobs will fail in the middle of the night with opaque OPEN errors that surface only as file status codes in COBOL or abends in utilities.
File control tables in CICS and analogous definitions in other subsystems must align with whatever password model you keep. If a CICS file definition references a VSAM KSDS that still has UPDATEPW, transactions that rewrite records must run under a user ID or attach a password path that satisfies both external security and native VSAM checks, depending on installation options. Batch utilities such as IDCAMS REPRO run under the job user and will fail if passwords are required but not supplied in the utility control cards where supported. Copying JCL from one environment to another without copying the matching security context is a frequent source of false starts during migrations. Document every consumer of a passworded cluster in the same ticket as the DEFINE so that decommissioning does not strand a forgotten CICS region still pointing at obsolete credentials.
When OPEN fails because of password mismatch, messages may be generic at the application layer while SYSLOG or SYSOUT from the access method holds more detail. COBOL programs often surface the situation through file status codes that mean authorization or environment problems rather than spelling out "wrong UPDATEPW." That ambiguity is another reason modern shops prefer RACF messages that explicitly cite profile names. If you maintain legacy passworded clusters, build a small playbook listing the SMF record types or log IDs your site uses to correlate failed opens with dataset names and job names so that weekend support can resolve incidents without paging the original developer from twenty years ago.
READPW is like a sticker on a book that says, "You need the secret word to look inside." UPDATEPW is a second sticker that says, "You need a different secret word to write in the book." Many libraries today use a card scanner instead of secret words—that is closer to RACF.
1. Which password is conceptually tied to changing data in the cluster?
2. Why might a modern shop avoid VSAM passwords in new designs?
3. READPW and UPDATEPW are stored where?