A customer closes an account, a duplicate keyed row must be removed, or a relative-file slot is no longer valid. In each case, the COBOL DELETE statement can remove one logical record—but only when the file organization, open mode, access mode, and key handling agree.
What the COBOL DELETE statement does
DELETE logically removes the record identified by the program from an indexed or relative file. It does not delete the data set, empty the whole file, or remove a Db2 row. The associated file must be open with I-O.
After a successful DELETE, the record is no longer available through ordinary keyed access. For an indexed file, the deleted prime-key value can be used for a later record. For a relative file, the vacated record position can be reused. The contents of the COBOL record area remain unchanged, so do not mistake old working storage for a record that still exists in the file.
DELETE statement syntax
DELETE file-name RECORD
[INVALID KEY imperative-statement-1]
[NOT INVALID KEY imperative-statement-2]
[END-DELETE]
file-name is the FD name, not a DD name, data set name, record name, or SQL table. The word RECORD is part of the statement. END-DELETE is the explicit scope terminator and is a sound choice whenever the statement has conditional phrases or is nested inside another operation.
Files that COBOL DELETE can process
| Organization | Can DELETE a record? | How the record is identified |
|---|---|---|
| Indexed | Yes | Prime RECORD KEY for random or dynamic access; prior READ for sequential access |
| Relative | Yes | RELATIVE KEY for random or dynamic access; prior READ for sequential access |
| Sequential | No | Build a replacement file that omits the unwanted record |
| Line sequential | No | Build a replacement file under the rules of the runtime and platform |
The COBOL file organizations guide compares the layouts. For VSAM, indexed organization usually maps to KSDS and relative organization to RRDS. An ESDS is sequential from the COBOL program's point of view and does not support record deletion through COBOL DELETE.
Required OPEN mode
Code OPEN I-O before deleting. INPUT permits reads but no changes, OUTPUT creates or replaces a file, and EXTEND adds records at the end of organizations that support it. None of those modes permits DELETE.
OPEN I-O CUSTOMER-FILE
IF CUSTOMER-STATUS NOT = "00"
DISPLAY "OPEN FAILED, STATUS=" CUSTOMER-STATUS
STOP RUN
END-IF
Check the status from OPEN before attempting any record operation. The COBOL OPEN statement guide explains the available modes and file-state errors.
Sequential access: READ before DELETE
With sequential access, the last I/O statement executed for that file before DELETE must be a successful READ. DELETE removes the record that was read. Do not code INVALID KEY or NOT INVALID KEY on this sequential form; handle READ completion and inspect FILE STATUS instead.
READ CUSTOMER-FILE NEXT RECORD
AT END
SET END-OF-FILE TO TRUE
NOT AT END
IF CUST-STATUS = "CLOSED"
DELETE CUSTOMER-FILE RECORD
IF CUSTOMER-STATUS NOT = "00"
DISPLAY "DELETE FAILED, STATUS=" CUSTOMER-STATUS
END-IF
END-IF
END-READ
A START does not replace the required READ. START positions the file; the following READ obtains a record; DELETE can then remove that record. See the COBOL START statement guide and the COBOL READ statement guide for positioning and end-of-file handling.
Random access: delete by key
Random access does not normally require a READ before DELETE. Move the target value to the prime RECORD KEY for an indexed file, then issue DELETE. If no matching record exists, the invalid-key condition occurs.
MOVE 105742 TO CUST-ID
DELETE CUSTOMER-FILE RECORD
INVALID KEY
DISPLAY "CUSTOMER NOT DELETED, STATUS=" CUSTOMER-STATUS
NOT INVALID KEY
DISPLAY "CUSTOMER DELETED: " CUST-ID
END-DELETE
The prime key must match the FD description in the SELECT clause. An alternate-key value does not replace the prime RECORD KEY on the DELETE statement. Review the COBOL indexed-file guide for RECORD KEY and alternate-key definitions.
Dynamic access: sequential and keyed work in one open
Dynamic access permits both sequential and random operations while the file remains open. A program can use START and READ NEXT to scan a range, or set the prime key and use DELETE as a random operation. Apply the rule for the operation being performed: a sequential DELETE needs the successful READ; a keyed random DELETE uses the record key.
This makes dynamic access useful for maintenance programs that browse records and occasionally process a requested key. Keep each path clear in the code so a future change does not accidentally depend on a stale record area.
Complete indexed-file DELETE example
FILE-CONTROL and record definitions
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT CUSTOMER-FILE
ASSIGN TO CUSTFILE
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS CUST-ID
FILE STATUS IS CUSTOMER-STATUS.
DATA DIVISION.
FILE SECTION.
FD CUSTOMER-FILE.
01 CUSTOMER-RECORD.
05 CUST-ID PIC 9(6).
05 CUST-NAME PIC X(30).
05 CUST-STATUS PIC X(8).
WORKING-STORAGE SECTION.
01 CUSTOMER-STATUS PIC XX.
Procedure Division logic
PROCEDURE DIVISION.
OPEN I-O CUSTOMER-FILE
IF CUSTOMER-STATUS = "00"
MOVE 105742 TO CUST-ID
DELETE CUSTOMER-FILE RECORD
INVALID KEY
DISPLAY "DELETE FAILED, STATUS=" CUSTOMER-STATUS
NOT INVALID KEY
DISPLAY "DELETE COMPLETED"
END-DELETE
CLOSE CUSTOMER-FILE
ELSE
DISPLAY "OPEN FAILED, STATUS=" CUSTOMER-STATUS
END-IF
GOBACK.
The program tests OPEN before DELETE and reports the two-character status after a keyed failure. A production program should also test CLOSE, route diagnostic data to the expected log, and return a site-approved condition code when work is incomplete.
Relative-file DELETE example
A relative file identifies each record by its relative record number. Define a RELATIVE KEY data item, put the requested number in that item, and issue DELETE while the file is open I-O.
SELECT ORDER-FILE
ASSIGN TO ORDRFILE
ORGANIZATION IS RELATIVE
ACCESS MODE IS RANDOM
RELATIVE KEY IS WS-RRN
FILE STATUS IS ORDER-STATUS.
01 WS-RRN PIC 9(6) COMP.
01 ORDER-STATUS PIC XX.
MOVE 420 TO WS-RRN
DELETE ORDER-FILE RECORD
INVALID KEY
DISPLAY "RRN 420 NOT DELETED, STATUS=" ORDER-STATUS
NOT INVALID KEY
DISPLAY "RRN 420 DELETED"
END-DELETE
The RELATIVE KEY is not part of the record description. It identifies the numbered slot used for random access. The COBOL relative-file guide covers RRDS and relative-record-number handling.
INVALID KEY and NOT INVALID KEY
INVALID KEY is valid for random and dynamic DELETE operations on indexed and relative files. It receives control when the operation encounters an invalid-key condition, such as a requested keyed record that does not exist. NOT INVALID KEY runs only when the DELETE succeeds.
If an invalid-key phrase handles the condition, an associated USE AFTER STANDARD ERROR declarative is not executed for that condition. Other failures do not necessarily run either phrase, which is why a FILE STATUS field should still be defined and checked.
FILE STATUS values worth checking
| Status | Typical meaning in this workflow | Response |
|---|---|---|
| 00 | Operation completed | Continue and record any required audit event |
| 23 | Randomly accessed record not found | Verify the prime key or relative record number |
| 35 | Required file was unavailable during OPEN | Check allocation, catalog, DD name, and optional-file rules |
| 37 | OPEN mode is incompatible with the file | Check SELECT/FD, access method, and requested mode |
| 43 or 92 | Sequence or VSAM logic error, including a missing successful READ in documented cases | Check access mode, prior operation, compiler/runtime documentation, and extended status |
| 49 | DELETE attempted when the file was not open I-O | Correct the OPEN path and file-state logic |
IBM's general file-status table identifies 43 as a sequence error, while IBM's VSAM deletion guidance documents status 92 when a sequential DELETE lacks the required successful READ. Use the status definitions for your compiler, runtime, and access method; if an extended VSAM code is available, log it with the two-character COBOL status. The COBOL file-status code reference provides a wider table.
What remains unchanged after DELETE
A successful DELETE does not clear the file's record area. Fields such as CUST-ID and CUST-NAME can therefore still display the values that were loaded before the operation. That memory is not proof that the record remains in the file.
IBM also states that DELETE does not change the file position indicator. Code later sequential processing according to the documented access-mode rules rather than assuming that deletion moves or resets the current position.
DELETE, REWRITE, and WRITE are different
| Statement | Purpose | Common requirement |
|---|---|---|
| DELETE | Remove one logical indexed or relative record | File open I-O; valid access-mode sequence or key |
| REWRITE | Replace the contents of an existing logical record | File open I-O; access-mode and key rules satisfied |
| WRITE | Add a new logical record | Permitted open mode, valid key, and no duplicate prime key |
Do not implement an update as DELETE followed by WRITE unless the application design explicitly calls for that behavior. The pair creates a period in which the record is absent and can have different recovery, key, and concurrent-access effects from REWRITE.
COBOL DELETE versus SQL DELETE and IDCAMS DELETE
COBOL DELETE is a file operation. SQL DELETE removes rows from a relational table under Db2 transaction rules. IDCAMS DELETE commonly removes a cataloged data set or cluster definition; it is not the statement used to remove one customer record from a KSDS.
If the intent is to remove an entire VSAM cluster, use the site's approved IDCAMS process and review the VSAM IDCAMS command guide. If the intent is to remove one indexed or relative record from a COBOL program, use the COBOL statement described here.
Common DELETE mistakes
- Opening the file INPUT instead of I-O.
- Trying to DELETE from a sequential or line-sequential organization.
- Skipping the required READ on a sequential-access path.
- Coding INVALID KEY on a sequential DELETE.
- Using an alternate key when DELETE expects the prime RECORD KEY.
- Leaving a stale or partially initialized key in working storage.
- Checking only INVALID KEY and ignoring FILE STATUS for other failures.
- Assuming a successful DELETE clears the record area or changes file position.
Production checklist
- Confirm that the organization is indexed or relative.
- Define a two-character FILE STATUS item and test OPEN.
- Open the file I-O.
- For sequential access, make sure the last I/O statement executed for that file is a successful READ.
- For random or dynamic keyed access, initialize the prime or relative key completely.
- Use INVALID KEY only where the access mode permits it.
- Check and log FILE STATUS after every DELETE.
- Apply the application's authorization, audit, restart, backup, and recovery rules.
- Test found, not-found, wrong-mode, end-of-file, and abnormal-access cases.
- Verify the result with a separate read or approved file utility when the change is sensitive.
Official IBM references
- IBM Enterprise COBOL: DELETE statement
- IBM Enterprise COBOL: Deleting records from a VSAM file
- IBM Enterprise COBOL: Coding INVALID KEY phrases
- IBM Enterprise COBOL: ACCESS MODE clause
- IBM Enterprise COBOL: FILE STATUS clause
- IBM Enterprise COBOL: Common processing facilities and status keys
Frequently asked questions
Can COBOL DELETE remove a record from a sequential file?
No. COBOL DELETE applies to indexed and relative files. To remove records from a sequential file, read the original and write a replacement file while omitting the unwanted records.
Must READ always come before DELETE?
No. For sequential access, the last I/O statement executed for that file before DELETE must be a successful READ; a prior READ is also required for documented spanned-record cases. A normal random or dynamic keyed DELETE can identify the target through the prime RECORD KEY or RELATIVE KEY without first reading it.
Which OPEN mode permits DELETE?
I-O. If the file is not open I-O, DELETE fails; status 49 is the standard file-status condition for a DELETE or REWRITE attempted on a file that is not open I-O.
What happens when the requested key does not exist?
For random or dynamic access, the invalid-key condition occurs. FILE STATUS commonly contains 23 for a randomly accessed record that is not found. Handle INVALID KEY and log the status so a missing record is not confused with another I/O failure.
