Easytrieve WRITE Statement

WRITE Format 1 — ADD and UPDATE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
FILE PERSNL INDEXED UPDATE
  EMP-NO    1  5 N
  TELEPHONE 6 10 N
JOB INPUT NULL NAME UPDATE-DEMO
  READ PERSNL KEY '05807' STATUS
  IF PERSNL:FILE-STATUS NE 0
    DISPLAY 'READ FAILED STATUS=' PERSNL:FILE-STATUS
  ELSE
    MOVE '3125559599' TO TELEPHONE
    WRITE PERSNL UPDATE STATUS
    IF PERSNL:FILE-STATUS NE 0
      DISPLAY 'UPDATE FAILED STATUS=' PERSNL:FILE-STATUS
    END-IF
  END-IF

Broadcom's canonical example READs by key, checks FILE-STATUS, moves a new telephone value into the record buffer, then WRITE PERSNL UPDATE. UPDATE is default when neither ADD nor DELETE is specified—explicit UPDATE documents intent for maintainers. STATUS sets the file status field after the operation for numeric comparison against zero success.

WRITE Format 2 — DELETE

1
WRITE output-file-name DELETE [STATUS]

DELETE removes the current active record—the one last successfully read into the file buffer. Attempting DELETE without a preceding successful READ on that file yields error status. DELETE does not accept FROM or ADD subparameters. Transaction files sometimes carry a delete flag column; JOB logic READs the master by key and issues WRITE DELETE when the flag is set.

ADD — Inserting New Records

1
2
3
4
5
6
7
8
9
10
11
FILE PERSNL INDEXED UPDATE
  EMP-NO    1  5 N
  TELEPHONE 6 10 N
JOB INPUT INKEYS NAME LOAD-ONE
  MOVE WHO TO EMP-NO
  MOVE PHONE TO TELEPHONE
  WRITE PERSNL ADD STATUS
  IF PERSNL:FILE-STATUS NE 0
    DISPLAY 'BAD KEY=' WHO ' STATUS=' PERSNL:FILE-STATUS
    GOTO JOB
  END-IF

ADD inserts when the key is new. Duplicate key attempts return non-zero FILE-STATUS—handle with DISPLAY and branch. CREATE on FILE instead of UPDATE applies when loading an empty KSDS with PUT for mass insert; UPDATE applies when any record might be added, changed, or deleted during the activity. Easytrieve scans I/O statements to infer processing mode at compile time.

FROM Clause

WRITE file UPDATE FROM input-file-name copies the record image from another file before writing. Useful when transaction layout matches master layout and you want to avoid field-by-field MOVE. FROM input-record-name variant references a specific record buffer name. Ensure key fields align so UPDATE targets the intended VSAM key.

FILE UPDATE and CREATE Prerequisites

Sequential files use PUT and GET for stream processing—not WRITE UPDATE for in-place rewrite. INDEXED maps to VSAM KSDS in z/OS environments; RELATIVE supports relative-record organization. FILE-STATUS on the file definition holds return codes when STATUS is coded on READ or WRITE.

READ Before UPDATE or DELETE

Activity Section documentation states you must read a record before WRITE UPDATE or DELETE. The read establishes the current active record in the file buffer. Random READ by KEY is typical for maintenance from transaction keys. After UPDATE, the rewritten record remains current for additional field changes and second WRITE if needed. Skipping READ and jumping straight to UPDATE after MOVE fields produces unpredictable status or wrong record replacement.

Transaction-Driven Maintenance Pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
FILE 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-MAINT
  IF TRANS-CODE = 'U'
    READ PAYVS KEY TRANS-KEY STATUS
    IF PAYVS:FILE-STATUS EQ 0
      MOVE TRANS-AMT TO PAY-AMT
      WRITE PAYVS UPDATE STATUS
      PERFORM CHECK-STATUS
    END-IF
  END-IF
  IF TRANS-CODE = 'D'
    READ PAYVS KEY TRANS-KEY STATUS
    IF PAYVS:FILE-STATUS EQ 0
      WRITE PAYVS DELETE STATUS
      PERFORM CHECK-STATUS
    END-IF
  END-IF

Single transaction file drives updates and deletes. Each path READs first, checks status, then WRITEs. PERFORM CHECK-STATUS centralizes error DISPLAY logic. GOTO JOB on fatal errors prevents partial application when later transactions should not run.

WRITE Versus PUT

Processing Modes

Easytrieve infers sequential versus direct access from FILE type and verbs coded. Direct access allows READ, WRITE ADD, WRITE UPDATE, WRITE DELETE. Sequential access on indexed files may allow GET, PUT, WRITE UPDATE, WRITE DELETE depending on statements present. Invalid combinations fail at compile time—code FILE Processing Modes documentation when mixing verbs in one activity confuses the compiler.

STATUS and Error Handling

Always code STATUS on production WRITE and READ when FILE-STATUS is defined. Test NE 0 for failure. Log key values and operation type—ADD versus UPDATE versus DELETE—for operations recovery. DISPLAY to SYSPRINT is minimum; some shops WRITE audit records to a sequential error file. STOP terminates the entire program; GOTO JOB skips to next transaction input record in driver patterns.

Common WRITE Mistakes

• Missing UPDATE on FILE for indexed maintenance.
• WRITE UPDATE without successful prior READ.
• Ignoring non-zero FILE-STATUS after WRITE.
• Using WRITE on sequential output instead of PUT.
• ADD with duplicate key treated as success.
• DELETE without confirming correct current record after READ.

Explain It Like I'm Five

WRITE is how you change a card in a labeled filing box. First you find the right card with READ—that is you pull the card out and look at it. UPDATE means you erase a phone number and write a new one on the same card, then put it back. ADD means you create a brand-new card and stick it in the box. DELETE means you throw away the card you just pulled out. The librarian gives you a thumbs up or thumbs down number—FILE-STATUS—and you should always check it before assuming the card is saved.

Exercises

1. Write READ KEY plus WRITE UPDATE with STATUS checks for telephone change.
2. Add a transaction path that WRITE DELETE after successful READ.
3. Explain when PUT is preferred over WRITE ADD for initial KSDS load.
4. List FILE parameters required for indexed WRITE maintenance.
5. Design PERFORM CHECK-STATUS displaying key and verb on failure.