Choosing the right storage and access method depends on how your application reads and updates data. VSAM is a strong fit when you need key-based or position-based access, when the same data is used by both batch and online regions, and when you do not need SQL or complex queries. This page helps you decide when to use VSAM versus sequential files or a database like Db2.
When your application must find a record by a key (e.g. customer ID, account number) and then read it, update it, or delete it, VSAM KSDS is the right choice. The index gives you direct access to the control interval containing that key, so you don’t scan the file. Sequential files don’t have an index; you would have to read record by record until you find the key, which does not scale. So any workload that is "look up by key and optionally update/delete" is a VSAM KSDS use case. Examples: customer master file, product file, order header lookup by order ID.
When you only read or write the entire file in order (e.g. produce a report, load a file from tape, write a log), a sequential dataset (QSAM) is often sufficient. You don’t need the overhead of an index or VSAM structure. Sequential files can be browsed and edited with ISPF, and they can reside on tape. Use VSAM when you need to mix sequential passes with key-based access or when the same file is shared by online and batch with key lookups; use sequential when the access pattern is strictly one-way, full-file sequential.
When the same data must be used by CICS (or another online region) and by batch jobs—e.g. online updates and batch reporting or batch key-based updates—VSAM with appropriate SHAREOPTIONS allows both to open the same cluster. You don’t maintain two copies and then merge them. So "when to use VSAM" includes "when batch and online share one logical file." For read-only sharing, SHAREOPTIONS(1 3) or (2 3) is typical; for cross-region update sharing, (2 3) or (3 3) with proper locking in the application.
When you only append records and later read sequentially or by known byte offset (RBA), VSAM ESDS is a good fit. Logs, audit trails, and event streams often follow this pattern. ESDS has no index overhead and preserves write order. If you never need to delete or insert in the middle, ESDS is simpler than KSDS. Use sequential (QSAM) if you also need the file on tape or want ISPF browse; use ESDS when you want RBA-based direct read or when the dataset is part of a VSAM-based design (e.g. IMS, Db2 use of ESDS-style organization).
Use VSAM when your access is programmatic and record-oriented: open file, read/update/delete by key or RBA, close. Use Db2 (or another relational database) when you need SQL, ad hoc queries, joins across tables, declarative integrity, or a relational model. VSAM has no query language and no join capability; the program must know the record layout and issue explicit READ/WRITE/REWRITE/DELETE. Db2 can use VSAM underneath (e.g. LDS for tablespaces), but the application sees tables and SQL. So: simple key or position access to one or a few files → VSAM; complex queries, many tables, SQL → Db2.
| What you need | Use |
|---|---|
| Look up by key, update/delete by key | VSAM KSDS |
| Append-only log, read by RBA or sequential | VSAM ESDS |
| Access by slot number (e.g. 1, 2, 3) | VSAM RRDS |
| Read whole file in order only, no key | Sequential (QSAM) |
| SQL, joins, multi-table transactions | Db2 (or other RDBMS) |
If you need to "find the card for customer 12345 and change their address," you want a filing system that can jump to that card by number—that's VSAM. If you only need to "read the whole list from top to bottom once," a simple list (sequential file) is enough. And if you need to "ask complicated questions across many lists and combine answers," you want a database (Db2). So: look up and change by key or position → VSAM; read or write the whole thing in order → sequential; complex questions and relations → database.
1. You need to look up a record by customer ID and update it. Best choice?
2. You need SQL, joins, and ad hoc queries. Best choice?