Easytrieve Screen Output Handling

Output Fields Versus Input Fields

An output field is one the operator reads but does not change. A customer name pulled from a master file, a running balance you calculated, or an error message all belong on output fields. An input field, by contrast, is where the operator types—an account number to look up or an amount to post. The difference is enforced by the field attribute in the screen definition: output fields are protected, input fields are unprotected. Marking a field protected keeps the cursor from landing on it and stops accidental overtyping, which is essential when the value is something your program owns rather than something the operator supplies.

Attribute names and exact spellings vary by Easytrieve release and by whether the field is painted through the SCREEN statement or a screen field definition. Treat the table above as the concept map; confirm the precise keyword your site uses in the SCREEN statement reference before coding, because an unsupported attribute keyword causes a compile error rather than a silent fallback.

Loading Values in BEFORE-SCREEN

Output fields do not fill themselves. The BEFORE-SCREEN procedure runs once per display cycle, immediately before the runtime builds and transmits the map, which makes it the natural place to move data into every output field. A typical inquiry screen reads a record and moves its columns into the matching display fields so the operator sees fresh data each time the screen appears.

1
2
3
4
5
6
7
8
9
10
11
12
13
BEFORE-SCREEN. PROC
   GET CUSTOMER-FILE
   IF EOF CUSTOMER-FILE
      SCR-NAME    = SPACES
      SCR-BALANCE = 0
      SCR-MSG     = 'NO MORE CUSTOMERS'
      EXIT
   END-IF
   SCR-NAME    = CUST-NAME
   SCR-CITY    = CUST-CITY
   SCR-BALANCE = CUST-BALANCE
   SCR-MSG     = SPACES
END-PROC

Notice that both the success path and the end-of-file path set every output field. On the EOF branch the code blanks the name, zeroes the balance, and sets a message, so the operator never sees leftover values from the previous customer. This discipline of always assigning output fields is the single most important habit in screen output handling.

Refreshing State Between Cycles

The runtime does not clear output fields for you between cycles. Whatever you moved into SCR-BALANCE last time is still there next time unless you overwrite it. That behavior is helpful when a value should persist, but harmful when it should not. Two rules keep screens honest: reload any field whose source could have changed, and explicitly clear any field that has no value in the current context. Working-storage fields defined with a RESET attribute may reinitialize at activity boundaries, but do not rely on RESET to scrub per-cycle output—assign values yourself in BEFORE-SCREEN.

• Reload file-driven fields after every GET so the display matches the current record.
• Clear message fields to spaces when there is no error or confirmation to show.
• Zero numeric accumulators before recomputing subtotals shown on the screen.
• Blank optional fields (for example a second address line) when the record leaves them empty.

Formatting Numeric Output with MASK

Raw numeric fields display as unbroken digit strings, so a balance of 1234567 with two implied decimals looks like 1234567 rather than 12,345.67. A MASK (edit pattern) inserts the punctuation humans expect. The mask defines where commas, the decimal point, a currency symbol, and sign handling appear. Applying a mask affects only how the value is shown; the underlying numeric field keeps its true value for any arithmetic you perform.

Exact mask characters depend on the Easytrieve release and whether you use a named MASK defined in the Library or an inline edit pattern. The key beginner takeaway is that display formatting is separate from the value itself, and you should format money and counts on screen the same way you would on a printed report.

Highlighting Important Output

Not all output deserves equal weight. A grand total, an overdue warning, or an error message should stand out. High-intensity and, on capable terminals, color attributes let you signal importance without changing the data. A common convention is high intensity for totals and headings, red for errors, and green for success confirmations. Keep the scheme consistent across screens so operators learn it. Avoid over-highlighting: if everything is bright, nothing stands out.

1
2
3
4
5
6
7
8
9
BEFORE-SCREEN. PROC
   PERFORM LOAD-ACCOUNT
   IF SCR-BALANCE LT 0
      SCR-MSG = 'ACCOUNT OVERDRAWN'
      * paint SCR-MSG with a high-intensity / red attribute
   ELSE
      SCR-MSG = SPACES
   END-IF
END-PROC

Output and the Data Behind It

Screen output fields are display copies, not the master data. When you move CUST-BALANCE into SCR-BALANCE, you create a snapshot for that cycle. If another transaction changes the master record, the screen shows the value only as fresh as your last GET. For inquiry screens this is usually fine. For screens that also update, re-read the record in AFTER-SCREEN before applying changes so you are working against current data, and reload output fields in BEFORE-SCREEN so the operator sees the result. Keeping display fields and master fields clearly named—SCR- prefixes for screen copies—prevents accidental edits to the wrong one.

Testing Screen Output

1. Display a record with known values and confirm every output field matches the file.
2. Page forward to a second record and verify no field retains the first record's value.
3. Trigger the end-of-file path and confirm fields blank and a message appears.
4. Check that negative balances format with the intended sign and highlight.
5. Verify protected fields reject typing and the cursor skips them.

Common Output Handling Mistakes

• Leaving output fields unprotected so operators can overtype computed values.
• Populating fields in AFTER-SCREEN instead of BEFORE-SCREEN, so the first display is blank.
• Forgetting to clear a message field, so an old error lingers after it is resolved.
• Displaying raw numerics without a mask, producing unreadable money values.
• Showing stale data after paging because fields were not reloaded each cycle.
• Highlighting too many fields until the important ones no longer stand out.

Explain It Like I'm Five

Think of the screen as a whiteboard the teacher shows the class. Output handling is the teacher writing today's answers on the board before turning it around. Some spots on the board are covered with tape so kids cannot scribble on them—those are the protected output areas. Before each new question the teacher wipes the board and writes the new answers, so nobody sees yesterday's. Important answers get underlined so everyone notices. The real answer key stays in the teacher's folder; the board is just a copy for looking at.

Exercises

1. Write a BEFORE-SCREEN that loads three output fields and clears a message field.
2. Add an EOF branch that blanks all output fields and sets an end message.
3. Apply a mask to a balance field and predict the display for value 1000000 with two decimals.
4. Add high-intensity highlighting to a total only when it exceeds a limit.
5. Explain why an output field showed the previous record and fix it.