Display files, subfiles & printing

A display file defines record formats used to exchange data with a display device, commonly in a 5250 application. DDS can define fields, attributes, function keys, and indicators. RPG uses operations such as WRITE and EXFMT to interact with it.

Keep presentation logic distinct from business updates. A screen format should collect and display values, while a business procedure validates and applies changes with a defined transaction. This separation makes later API or web reuse easier.

The subfile record format defines one displayed row of a list. The control format governs the subfile display and related controls. Relative record numbers identify rows in the subfile’s runtime contents.

Explain loading, displaying, reading changed records, and clearing/reloading as separate steps. Indicators and DDS keywords determine when the subfile and control are displayed. Incorrect state can show old rows, produce empty displays, or cause device-file errors.

A load-all approach populates the intended list into the subfile before interaction, while page-at-a-time logic loads a bounded page and manages navigation explicitly. The choice depends on row volume, response time, and device/application limits.

For large data, use stable keyed pagination and preserve selection behavior across page changes. Test first/last pages, no records, deletions between pages, and repeated navigation. Do not read an entire large table simply because the initial test dataset was small.

Use changed-record processing, commonly READC, and inspect the option or edited values for each returned row. Validate every requested action against current business state rather than trusting the screen’s earlier data.

After an error, manage changed indicators and redisplay deliberately so rows needing correction remain processable. Record the underlying business key separately from the subfile relative record number. The display row position is not a durable database identity.

A printer file describes output records and printing attributes. Programs write output that can be spooled into an output queue, where a writer or other consumer processes it. Creation of spool output and physical printing are separate stages.

Use appropriate overflow/page-heading logic for formatted reports. When a user says printing failed, inspect both the application run and the spooled file state. A correct business transaction should not need to be reposted merely because a printer is unavailable.

SFLSIZ describes the subfile size allocation characteristics, while SFLPAG describes the number of records in a displayed page. They are different from the total number of rows in the underlying database query. The DDS configuration and application loading approach work together.

Choose values that fit the display layout and paging model. Test a partial last page and a list larger than one page. Do not infer that declaring a larger subfile automatically loads more database records; RPG still owns the loading logic.

SFLDSP controls display of subfile records, SFLDSPCTL controls the control format, and SFLCLR clears subfile records when used according to the DDS rules. An empty result should not attempt to display nonexistent subfile rows.

Clear/reset the load state, show the control/header and a useful no-records message, and enable row display only when records exist. Test switching from a populated list to an empty search so old rows do not remain visible.

Document selection, paging, validation, authority, and error paths first. Extract business operations behind explicit contracts while keeping the existing screen as a caller. Then implement a new interface using the same behavior.

Test concurrent edits, no-result cases, large lists, and retry behavior. Preserve stable business identifiers rather than exposing screen row numbers as API IDs. A visually similar web table is not proof that the workflow and transaction semantics were preserved.

SFLNXTCHG can mark a subfile record so it is treated as changed for subsequent changed-record processing. It is useful when a row failed validation and must remain available for another pass even without an additional user edit.

Set and reset the relevant indicator intentionally when updating the subfile record. Otherwise a row may disappear from the retry processing or be returned repeatedly after success. Test multiple selections containing both valid and invalid actions.