Employee terminations, closed accounts, obsolete product codes—master files shrink as well as grow. Easytrieve physical delete uses WRITE file-name DELETE after a successful READ positioned the record in the file buffer. The FILE statement needs INDEXED or RELATIVE organization with UPDATE authority. Beginners confuse DELETE with dropping a DD from JCL; program DELETE removes one logical record from VSAM while the cluster remains. Operations teams often prefer logical delete—flip a status byte and filter on read—because audit and recovery policies require retained history. This page teaches WRITE DELETE syntax, READ-then-delete workflow, transaction-driven maintenance from driver files, STATUS and FILE-STATUS handling, contrast with UPDATE and ADD, sequential file limitations, logical-delete alternative patterns, and JCL disposition concerns when multiple jobs touch the same KSDS. Pair with the WRITE statement tutorial for statement-level detail and with indexed file processing for VSAM concepts.
1WRITE output-file-name DELETE [STATUS]
Format 2 has no ADD, UPDATE, or FROM clauses. DELETE always targets the current active record for output-file-name—the record last successfully read into that file's buffer. STATUS optionally sets the file's FILE-STATUS field after the operation for numeric comparison.
1234567891011121314FILE KSDS-FILE INDEXED UPDATE WHO 1 5 N PHONE 6 10 N JOB INPUT KEYS NAME DELETE-DEMO READ KSDS-FILE KEY WHO STATUS IF KSDS-FILE:FILE-STATUS NE 0 DISPLAY 'READ FAILED KEY=' WHO GOTO JOB END-IF WRITE KSDS-FILE DELETE STATUS IF KSDS-FILE:FILE-STATUS NE 0 DISPLAY 'DELETE FAILED KEY=' WHO STOP END-IF
Input file KEYS supplies WHO values to delete. Each iteration READs by key; failure skips delete with GOTO JOB to next driver record. Success issues WRITE DELETE; non-zero status STOPs the job for operator attention on production masters.
| Requirement | Where set | Why it matters |
|---|---|---|
| FILE UPDATE | Library FILE | Authorizes WRITE DELETE |
| INDEXED or RELATIVE | FILE organization | QSAM lacks random delete |
| Prior READ success | JOB activity | Establishes current record |
| JCL exclusive access | DD DISP | Prevent concurrent corrupting updates |
123456789101112131415FILE TRANS FB(80) TRANS-KEY 14 3 A TRANS-CODE 17 1 A FILE PAYVS INDEXED UPDATE PAY-KEY 1 3 A JOB INPUT TRANS NAME VSAM-DELETE IF TRANS-CODE = 'D' READ PAYVS KEY TRANS-KEY STATUS IF PAYVS:FILE-STATUS EQ 0 WRITE PAYVS DELETE STATUS PERFORM WRITE-STAT-CHECK ELSE DISPLAY 'KEY NOT FOUND ' TRANS-KEY END-IF END-IF
Broadcom's Activity Section example uses TRANS-CODE D to mean delete. Only matching transactions touch the master. PERFORM WRITE-STAT-CHECK centralizes post-DELETE validation. U codes might UPDATE; A codes might ADD—single driver file orchestrates mixed maintenance.
| Strategy | Mechanism | When to use |
|---|---|---|
| Physical DELETE | WRITE file DELETE | Record must vanish from VSAM; rebuild backups exist |
| Logical delete | MOVE inactive flag; READ filters IF STATUS NE inactive | Audit retention; undo window; regulatory hold |
| Archive then delete | PUT to history file then WRITE DELETE | Operations wants cold storage copy before removal |
Financial and HR systems often ban physical DELETE without archive. Easytrieve makes physical delete easy—governance decides which pattern is allowed. Document shop standards before coding WRITE DELETE on shared masters.
UPDATE rewrites the current record image in place—same key, new field values. DELETE removes the record entirely; subsequent READ by that key returns not-found status. Accidentally coding UPDATE when DELETE was intended leaves obsolete rows searchable. Accidentally coding DELETE when a status flag update was intended removes recoverable data. Code reviews should verify transaction code mapping tables.
Re-running a delete job against the same driver file may attempt DELETE on keys already removed. READ returns not-found; branch to log already deleted rather than failing the batch. Idempotent delete jobs display counts: deleted, not found, errors. FILE-STATUS codes vary by access method—maintain a shop cheat sheet for 00 success versus key not found versus authority failure.
WRITE DELETE documentation centers on indexed and relative files. ESDS entries may support delete in VSAM depending on cluster definition; confirm with storage administrators. Standard sequential output files use PUT append—never WRITE DELETE. When unsure, treat non-KSDS files as logical-delete-only in Easytrieve programs.
Deleting a record is pulling one card out of a filing box and throwing it away. You have to find the right card first with READ—that is you read the label on the card. Then WRITE DELETE means toss that exact card. If you grab the wrong card first, you might throw away the wrong person's information, so you always check the librarian's okay number afterward. Sometimes the grown-ups do not throw cards away—they just draw a red X on the card and put it back, which is logical delete.
1. The Easytrieve verb that deletes an indexed record is:
2. Before WRITE DELETE you must:
3. FILE must include UPDATE when deleting because:
4. A transaction file with code D typically triggers:
5. Non-zero FILE-STATUS after DELETE should: