DDS, physical & logical files

A physical file stores records. A logical file describes an alternative presentation or access path over physical data, such as keyed ordering, selected records, or a join. The logical file does not hold an independent copy of the business rows.

Additional access paths still consume storage and maintenance work. When an application updates data through an eligible logical file, it changes the underlying physical data. Join logical files have more restrictive capabilities than simple logical files.

Example

Customer PF → by-name LF and by-region LF

Interview pitfall: “No business rows stored” does not mean an LF has zero storage or maintenance cost.

DDS describes externally defined file layouts and related attributes. A record format names a layout of fields; key definitions establish a keyed access path. The compiler can use those external definitions so program fields agree with the file description.

Distinguish field layout from access order. Adding a key can change access behavior, while changing a field type or length can affect compiled consumers. Review downstream programs and files before promoting schema changes.

A database file can contain members that share the file description but have separate record collections. Source physical files commonly use one member per source unit. Data files may use multiple members for legacy partitioning patterns.

Native access can select a member using an override or open settings. SQL normally addresses a table’s default member; an SQL alias can name a particular member. Do not assume SELECT automatically reads every member.

Example

CREATE ALIAS TEST.ORD_JAN FOR APP.ORDERS(JAN);

Interview pitfall: Members are not interchangeable with modern SQL partitioning features.

An externally described program expects a particular record-format level identifier. If the runtime file layout does not match that expectation, level checking can reject the open. This often follows a file change without rebuilding dependent consumers, or resolution to the wrong library.

Compare the resolved object and formats, inspect dependencies, then rebuild the appropriate programs and files. Turning level checking off can conceal an incompatible layout and corrupt interpretation of data; it is not the default repair.

Example

DSPFFD FILE(APP/ORDERS)
DSPDBR FILE(APP/ORDERS)

A join LF combines fields from related physical files according to its DDS join rules. Select/omit definitions control which records are visible through a logical file. Neither should be assumed to behave identically to every SQL view or join.

For an interview scenario, explain the required row set and whether updates are needed. A join LF is read-only for native update purposes. SQL may be clearer for aggregates and flexible joins, while existing applications may rely on DDS format compatibility.

Use database constraints for invariants that must hold regardless of which application writes the data: required values, uniqueness, valid ranges, and referential integrity are common examples. RPG validation still helps produce helpful user feedback.

A screen-only check can be bypassed by batch or integration updates. Before adding a constraint to legacy data, inspect existing violations and define cleanup and rollout. Test expected failure diagnostics so every caller handles rejected writes meaningfully.

No. First distinguish the role: record-format projection, selection, joins, or keyed access for native I/O. SQL views and indexes serve different purposes; a one-for-one replacement can lose semantics or break a compiled interface.

Inventory consumers, preserve externally visible contracts where required, and compare query plans and write costs. Modernizing database definitions is a migration project with compatibility tests, not a naming conversion. Verify the resulting rows, key behavior, nullability, and dependency rebuild requirements.

Triggers execute in response to specified database events. BEFORE logic can validate or adjust eligible incoming values under the supported rules; AFTER logic acts after the triggering change and can implement related database actions. The exact capabilities depend on the trigger definition and event.

Keep effects understandable and avoid hidden network calls in a lock-holding path. Test multirow statements, recursion/cascades, errors, and transaction rollback. A single application UPDATE may invoke more database work than the caller’s source reveals.