Easytrieve Screen Input Handling

One Input Cycle Diagram

Field Input Versus PF Keys

Field input maps to DEFINE variables on ROW declarations. Operator tabs between fields, types values, presses Enter to submit panel. PF keys are separate KEY definitions—F1 Help, F3 Exit, F8 Forward—each with NAME label operator sees and action when pressed. Enter submits field content for AFTER-SCREEN processing unless IMMEDIATE key bypasses wait.

1
2
3
4
KEY F1  NAME 'Help'  IMMEDIATE
KEY F3  NAME 'Exit'  EXIT
KEY F8  NAME 'Next'  IMMEDIATE
KEY F12 NAME 'Cancel' EXIT IMMEDIATE

Enter Key Processing

Standard data entry: operator completes fields, presses Enter. Terminal sends field buffer to Easytrieve. Declarative VALUE and MUSTENTER validate at field level. AFTER-SCREEN receives control with updated SCR- fields. Branch on content: inquiry READ, maintenance UPDATE, menu EXECUTE another SCREEN. Enter on empty required field triggers attribute error before AFTER-SCREEN or within declarative validation depending on release behavior—test both paths.

IMMEDIATE Key Processing

IMMEDIATE on KEY means operator need not press Enter on other fields—PF key action fires immediately. Use for Exit, Cancel, Help that should not submit half-filled maintenance forms. EXIT IMMEDIATE ends activity without waiting. Help IMMEDIATE may PERFORM HELP. PROC and redisplay. Document which keys are IMMEDIATE in operator run book—unexpected IMMEDIATE Cancel loses typed data operators expected to confirm with Enter.

Reading Input in AFTER-SCREEN

1
2
3
4
5
6
7
8
9
10
11
12
13
AFTER-SCREEN. PROC
  EVALUATE SCR-MENU-OPT
    WHEN 'V'
       PERFORM VIEW-EMPLOYEE
    WHEN 'E'
       PERFORM EDIT-EMPLOYEE
    WHEN 'X'
       EXIT
    WHEN OTHER
       SCR-MSG = 'Invalid option'
       GOTO SCREEN
  END-EVALUATE
END-PROC

SCR-MENU-OPT holds operator menu choice after Enter. EVALUATE or IF branches to procedures. Invalid option sets message and GOTO SCREEN redisplays menu. Valid paths may EXECUTE another SCREEN or PERFORM file logic. PF key EXIT may bypass AFTER-SCREEN menu logic when KEY EXIT fires—understand precedence when both KEY and field input active.

UPPERCASE and Input Normalization

SCREEN UPPERCASE translates received data before AFTER-SCREEN. Menu VALUE ('V' 'E' 'X') expects uppercase letters—enable UPPERCASE so operators typing lowercase v still match. Without UPPERCASE, extend VALUE list or compare using uppercase functions in AFTER-SCREEN. Consistent choice across all screens in application reduces operator confusion.

RESET and Input Persistence

Input DEFINE with RESET clears before BEFORE-SCREEN each cycle—fresh form each display. Maintenance screens that should retain typed data across failed validation may omit RESET on specific fields or MOVE prior values back in BEFORE-SCREEN after failed AFTER-SCREEN—design explicitly. Output ASKIP fields repopulate from files in BEFORE-SCREEN; input fields without RESET may show stale characters from failed submit—often desirable so operator fixes one field not retype all.

Inquiry Input Pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
AFTER-SCREEN. PROC
  IF SCR-ACCT EQ ZEROS
     SCR-MSG = 'Enter account number'
     GOTO SCREEN
  END-IF
  READ CUSTMAST KEY SCR-ACCT
  IF NOT CUSTMAST
     SCR-MSG = 'Account not found'
     GOTO SCREEN
  END-IF
  MOVE CUST-NAME TO SCR-NAME
  MOVE CUST-BAL  TO SCR-BAL
END-PROC

Single key field drives READ. Success fills protected output fields; operator reviews without editing balance. F8 Forward KEY IMMEDIATE might increment internal index and PERFORM another READ in AFTER-SCREEN for browse-next pattern.

Maintenance Input Pattern

Maintenance collects multiple editable fields—some protected keys, some open amounts or codes. AFTER-SCREEN validates all, confirms with second screen or CONFIRM field Y/N, then UPDATE. Never UPDATE on first keystroke without validation. Consider double-entry for high-risk amounts— operator types amount twice, AFTER-SCREEN compares fields.

PF Key Standard Layout

Shops often standardize: F1 Help, F3 Exit, F12 Cancel, F8 Next, F7 Previous. Match KEY NAME text to run book. Inconsistent PF labels across screens in same application frustrate operators. EXIT keys should always work—even mid-validation—unless business requires confirm dialog PERFORM before EXIT.

Pseudo-Conversational Input on CICS

COMMIT TERMINAL default commits around terminal I/O. Task may suspend between screens; next input resumes transaction. AFTER-SCREEN must leave files and context ready for resume—OPEN in INITIATION not each cycle unless documented. Fields without RESET may need COMMAREA-style persistence equivalent per runtime—verify with platform guide when porting TSO design to CICS.

Input Handling and File I/O

AFTER-SCREEN READ/UPDATE/WRITE uses same FILE verbs as batch. GET in BEFORE-SCREEN for browse screens; READ keyed in AFTER-SCREEN for inquiry submit. Hold record locks and COMMIT timing affect whether second operator sees stale data—coordinate with DBA on online update isolation.

Common Input Handling Mistakes

• Processing input in BEFORE-SCREEN.
• GOTO SCREEN in BEFORE-SCREEN.
• IMMEDIATE Exit on maintenance screen without save warning.
• Ignoring PF key EXIT paths in AFTER-SCREEN menu logic.
• UPPERCASE mismatch with VALUE lists.
• RESET clearing fields operator should fix after validation error.

Explain It Like I'm Five

Input handling is what happens when you hand your worksheet to the teacher. BEFORE-SCREEN was the teacher putting the blank worksheet on your desk. You write answers and raise your hand (Enter) or press a special button (PF key). AFTER-SCREEN is the teacher reading what you wrote and saying good job next page, or fix question three and try again.

Exercises

1. Diagram one cycle with RESET BEFORE-SCREEN input AFTER-SCREEN branches.
2. Define four KEY lines with two IMMEDIATE and two requiring Enter context.
3. Write AFTER-SCREEN menu EVALUATE with GOTO SCREEN on invalid.
4. Explain when to use RESET on input fields after validation failure.
5. Design inquiry versus maintenance input flow differences.