Files & native file operations

CHAIN retrieves a matching record using a key or relative record number. SETLL positions the access path at a lower limit without transferring a record into program fields. READ retrieves the next record in the current access-path sequence.

Choose based on intent: one known customer suggests CHAIN; a range scan suggests positioning followed by sequential reads. Check the result immediately because a failed input operation leaves the previous field values in place.

Example

chain customerId Customers;
if %found(Customers);
  // Use the retrieved customer
endif;

Interview pitfall: SETLL is not a read, and a failed CHAIN does not clear the record buffer.

Position with SETLL, then use READE to retrieve records whose key matches the search argument. Continue until the equal-key group ends, checking %EOF for that file. Use a correctly typed composite or partial key when appropriate.

Do not use a plain READ loop without also checking the group boundary; it can continue into the next customer or order. Include a no-match test, a one-record test, and a multi-record group test.

Example

setll customerId Orders;
reade customerId Orders;
dow not %eof(Orders);
  // Process current order
  reade customerId Orders;
enddo;

Reading an update-capable disk file normally obtains a record lock for update. The N extender requests a nonlocking read for the supported input operations. An input-only file does not provide the same update path.

Choose the lock deliberately. Reading without a lock and then writing back a computed value can lose another job’s change unless you re-read under protection or use an optimistic predicate. Commitment control can retain transaction locks beyond the simple native-I/O lifecycle.

Example

chain(n) customerId Customers; // inquiry intent

Interview pitfall: No-lock inquiry is not a complete concurrent-update algorithm.

WRITE creates a record, UPDATE changes an existing record under the relevant file and lock rules, and DELETE removes a record. Externally described file operations may refer to a record format rather than the file name, depending on the opcode.

Validate found status and handle duplicate-key, constraint, and lock errors. For multi-step business work, plan a transaction rather than assuming successful individual operations guarantee a consistent result. Confirm whether triggers or constraints add further behavior.

An open data path holds runtime access state for an open file, including access method and positioning. Sharing can reduce repeated opens but can also share state between users of that path inside the applicable scope.

If one routine positions or reads a shared path, another routine may observe a changed position. When debugging surprising reads, inspect open options, sharing, overrides, and activation scope. Prefer explicit ownership of iteration instead of relying on an invisible shared cursor.

USROPN prevents the normal automatic open for the applicable RPG file definition, making the program responsible for OPEN before use and CLOSE at the intended point. It is useful when configuration or overrides must be established before opening.

Check open errors and ensure cleanup on both normal and error paths. In a reused program, do not blindly OPEN an already open file. %OPEN can help express the intended lifecycle, but the code must still own the resource consistently.

Example

dcl-f Orders usage(*input) keyed usropn;
if not %open(Orders);
  open Orders;
endif;
// Read and handle status
close Orders;

OVRDBF can redirect a file reference to another file or member and alter supported open attributes. The effective override must be in scope when the file opens; an already open path may continue to use its existing target.

Inspect overrides in the actual failing job, not a separate terminal session. Clean up temporary overrides at the intended scope. Record-format compatibility still matters, so redirecting a file does not safely erase layout differences.

Example

OVRDBF FILE(ORDERS) TOFILE(TEST/ORDERS) MBR(TESTDATA)
/* Open and run the intended test, then remove the override. */

Interview pitfall: An override is not automatically visible in a different submitted job.