File functions bridge declarative FILE definitions and runtime I/O reality. Library FILE and DEFINE describe record layout; JOB READ and PUT move bytes. When READ fails on VSAM, when trailer count must match processed rows, when diagnostic SYSPRINT needs the logical file name tied to a DD—file builtins and file-related special values answer operational questions during execution. EOF drives the classic DO WHILE EOF EQ N loop for sequential processing. Status functions after keyed GET distinguish record not found from serious I/O errors requiring ABEND. Beginners treat all read failures alike and either ignore errors or stop the entire job for one missing optional row. File function patterns route expected misses to alternate logic while logging unexpected status to SYSPRINT. This index covers EOF handling, status retrieval categories, record count reconciliation, integration with error PROCs, sequential versus indexed differences, and fallbacks using DISPLAY and manual counters when specific builtins are absent on your compile level.
Compile time: FILE INFILE FB(lrecl), DEFINE fields, optional FILE attributes for VSAM organization. Runtime: JCL DD assigns dataset. OPEN prepares buffer. READ advances pointer. File functions read that runtime state—they do not replace FILE statement or correct bad JCL. Mismatch between FILE FB length and dataset LRECL surfaces as status errors detectable when program checks status instead of assuming every READ succeeds.
Sequential JOB INPUT loops until EOF indicates no more records. DO WHILE EOF EQ N with READ inside body is standard pattern. EOF is documented as special file-related value rather than parenthetical function on many releases—still grouped in file function tutorials because behavior is identical from programmer view. Inverting EOF condition causes zero iterations or infinite loop—verify EQ N versus EQ Y semantics in Language Reference for your version. Nested files each maintain separate EOF when multiple FILE definitions active—do not assume global EOF across unrelated inputs.
1234567JOB INPUT PAYROLL DO WHILE EOF EQ N READ PAYROLL IF DEPT EQ 911 PRINT DEPT-RPT END-IF END-DO
Keyed READ, GET, WRITE, and DELETE on VSAM set status codes consumed by status functions or special registers per manual. NOTFND routes optional lookup miss. DUPKEY triggers duplicate handling. I/O error may warrant DISPLAY status, increment ERROR-COUNT, and ABEND via ABEXIT PARM when threshold exceeded. Pattern: perform READ; IF STATUS-FUNC EQ NOTFND perform default logic; ELSE IF STATUS-FUNC EQ OK continue; ELSE call ERROR-PROC. Exact status literal names vary—copy from Messages and Codes for your release.
| Category | When used | Typical outcome |
|---|---|---|
| EOF indicator | Sequential READ loops | Exit loop at end of dataset |
| OK / success status | After successful I/O | Continue processing |
| Not found | Keyed READ miss | Default record or skip branch |
| Duplicate key | Invalid insert or rewrite | Exception report or ABEND |
| Record count | Trailer reconciliation | Compare to control total field |
Increment WS-COUNT each iteration manually or use count function if documented. Trailer record carries FILE-COUNT from upstream; IF WS-COUNT NE FILE-COUNT flags imbalance. Functions returning system-maintained count may differ from manual counter when READ failures skip increment—document which count is authoritative for audit. Operations teams reconcile spool counts, file counts, and control totals nightly; Easytrieve program should PRINT all three on summary report when file functions support it.
Sequential batch relies heavily on EOF. VSAM KSDS adds status after every keyed access—file status functions essential. ESDS sequential browse uses EOF; direct access uses relative or key status. FILE statement attributes determine which verbs and status codes apply. Do not copy VSAM error PROC from colleague's KSDS program into pure FB sequential job without trimming unused branches.
Centralize status handling in ERROR-PROC: DISPLAY file name placeholder, status code, record key fields, SET ABEND flag when severity high. PERFORM ERROR-PROC from multiple READ paths keeps logic consistent. File functions supply parameters ERROR-PROC formats into SYSPRINT line. PARM ABEXIT controls whether runtime aborts on unhandled status— coordinate with operations before enabling in production.
Matching master and detail files checks EOF on both—IF MASTER-EOF EQ Y AND DETAIL-EOF EQ Y exit merge loop. Premature exit when one file shorter causes orphan detail rows—status and EOF tests must pair with business rules on file synchronization. File functions tied to specific FILE name disambiguate which input exhausted when three FILE definitions read in interleaved pattern.
File functions report logical Easytrieve FILE name state; JCL DD maps logical to physical dataset. DISPLAY of DD-related function output helps debug wrong dataset mounted—when function available per manual. Wrong DD still produces records; only validation catches content mismatch. Teach operators to verify DDNAME in listing against JCL when status OK but business totals wrong.
Status check per READ is negligible. Logging every OK status to SYSPRINT floods spool—log exceptions only. Count increment is integer add—cheap. Avoid redundant status function calls—store in working field once per READ iteration.
File functions ask questions about the storybook you are reading. Are there more pages left—that is EOF? Did the library say book not found when you asked for a title—that is status? How many pages did you read—that is count? The FILE statement describes what each page looks like; file functions tell you what happened while you turn pages.
1. File functions expose:
2. EOF constant in DO WHILE EOF EQ N means:
3. After READ failure, file status function helps:
4. File functions are used primarily in:
5. Record count functions support: