Easytrieve Terminal Interaction

The Send-Receive Cycle

A 3270 terminal does not stream characters the way a modern keyboard event does. Instead it works in full-screen bursts. The program builds a complete screen image—the map—and transmits it in one go. The terminal then belongs to the operator: they tab between fields, type values, and finally press an action key such as Enter or a PF key. Only that key press sends data back. The program receives the changed fields in one burst, processes them, and builds the next screen. This send, wait, receive, process loop is the heartbeat of terminal interaction.

1
2
3
4
5
6
7
* Conceptual cycle for one screen
1. BEFORE-SCREEN  -> load output fields, position cursor
2. (runtime)      -> transmit map to terminal
3. (operator)     -> types input, presses Enter or a PF key
4. (runtime)      -> receive changed fields and the key pressed
5. AFTER-SCREEN   -> validate input, act, decide next screen
6. repeat, or leave the activity

The important beginner insight is that your code does not run while the operator is typing. It runs in short bursts before the send (BEFORE-SCREEN) and after the receive (AFTER-SCREEN). Between those bursts the program is waiting. Designing around this rhythm—rather than expecting keystroke-by-keystroke control—keeps online logic simple and correct.

The Four Screen Procedures

An Easytrieve SCREEN activity exposes four special-name procedures that the runtime calls at fixed points. You do not PERFORM them; the runtime dispatches each one when its event occurs. Placing logic in the right procedure is most of the skill in online programming.

INITIATION and TERMINATION bracket the whole activity and run a single time each. BEFORE-SCREEN and AFTER-SCREEN bracket every individual display cycle and run once per interaction. A frequent beginner error is putting one-time setup such as opening a file in BEFORE-SCREEN, which then re-runs on every cycle; that work belongs in INITIATION.

Conversational Versus Pseudo-Conversational

How the program behaves while waiting for the operator defines two execution styles. In conversational mode the task stays in memory the entire time, holding files, storage, and any locks while the operator thinks. It is simple to reason about because your variables keep their values across the wait. The cost is scalability: dozens of idle operators each pin resources. In pseudo-conversational mode the task ends after sending the screen and is restarted when the operator presses a key, so resources are freed during think time. This scales far better under CICS but requires saving state between interactions.

Which mode your Easytrieve screen uses depends on the runtime environment and site configuration, especially whether screens run native or under CICS. Confirm with your operations team; the programming pattern for BEFORE-SCREEN and AFTER-SCREEN stays similar, but state persistence assumptions change.

Navigating Between Screens

Real applications are not a single screen; they are a flow—menu, inquiry, detail, confirm. The decision about which screen comes next is made in AFTER-SCREEN, after you know what the operator typed and which key they pressed. You branch based on that information, often setting a next screen identifier or using GOTO or CASE logic to route control. A menu screen reads a selection number and routes to the matching screen; a detail screen returns to the list when the operator presses the exit key.

1
2
3
4
5
6
7
8
9
10
11
12
AFTER-SCREEN. PROC
   CASE MENU-CHOICE
      WHEN '1'
         PERFORM SHOW-CUSTOMER-INQUIRY
      WHEN '2'
         PERFORM SHOW-ORDER-ENTRY
      WHEN '9'
         PERFORM EXIT-APPLICATION
      OTHERWISE
         SCR-MSG = 'INVALID SELECTION'
   END-CASE
END-PROC

Online Flow Versus Batch Flow

If you have written batch reports, the mental shift is real. A JOB INPUT activity loops automatically: read a record, run your logic, read the next, until end of file, with no human in the loop. A SCREEN activity has no file to exhaust—it loops until the operator chooses to leave. The driver is human action and key presses, not EOF. Counters accumulate across interactions the way they accumulate across records, but the pacing is set by a person, and the program spends most of its life waiting rather than computing.

• Batch is driven by data reaching end of file; online is driven by operator key presses.
• Batch runs unattended; online is a live dialogue with a person.
• Batch logic sits in the JOB body; online logic sits in BEFORE-SCREEN and AFTER-SCREEN.
• Batch ends at EOF; online ends when the operator requests exit.

A Minimal Interaction Skeleton

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SCREEN NAME CUST-INQUIRY
  * field layout and KEY definitions here
 
INITIATION. PROC
   OPEN CUSTOMER-FILE
END-PROC
 
BEFORE-SCREEN. PROC
   PERFORM LOAD-DISPLAY
   SCR-MSG = SPACES
END-PROC
 
AFTER-SCREEN. PROC
   IF ACCT-NO EQ SPACES
      SCR-MSG = 'ENTER AN ACCOUNT NUMBER'
   ELSE
      PERFORM LOOKUP-ACCOUNT
   END-IF
END-PROC
 
TERMINATION. PROC
   CLOSE CUSTOMER-FILE
END-PROC

Testing Terminal Interaction

1. Confirm INITIATION opens files exactly once by tracing entry with an audit field.
2. Verify BEFORE-SCREEN runs each cycle and AFTER-SCREEN runs after each submit.
3. Walk a full menu-to-detail-and-back path to check screen navigation.
4. Test the exit key path and confirm TERMINATION closes files.
5. If pseudo-conversational, verify saved state survives between key presses.

Common Interaction Mistakes

• Opening files in BEFORE-SCREEN so they reopen every cycle instead of once in INITIATION.
• Expecting code to run while the operator types—logic only runs before send and after receive.
• Deciding navigation in BEFORE-SCREEN before you know what the operator did.
• Assuming variables persist in pseudo-conversational mode without saving state.
• Never providing an exit path, trapping the operator on a screen.
• Skipping TERMINATION cleanup, leaving files open at activity end.

Explain It Like I'm Five

Talking to a terminal is like passing notes with a friend. You write a whole note and slide it over—that is sending the screen. Then you wait; you cannot see your friend writing. When they slide the note back with their answer—that is pressing Enter—you read it and write a new note. The teacher hands out the first blank note (INITIATION) and collects everything at the end of class (TERMINATION). You only get to write just before sliding a note over and just after getting one back—never in between.

Exercises

1. List the four screen procedures in order and state how many times each runs.
2. Draw the send-receive cycle for one screen and label where your code executes.
3. Write AFTER-SCREEN CASE logic that routes a menu choice to three screens.
4. Explain one advantage and one cost of conversational mode.
5. Contrast what ends a batch JOB with what ends a SCREEN activity.