Easytrieve Screen Programming Overview

Why Screen Programming Exists

Not every business question waits for a morning report. Branch managers need account inquiry now. Data stewards need to correct a bad code before the nightly extract. Auditors need to approve an adjustment with a terminal receipt. Easytrieve screen programming answers those needs without rewriting decades of FILE and DEFINE investment in COBOL or another language. The same data dictionary powers batch and online; SCREEN activities add the terminal presentation layer.

Program Structure With SCREEN

Easytrieve programs still begin with Library—FILE, DEFINE, DECLARE attributes. Activity section holds SCREEN, JOB, PROGRAM, and SORT blocks. SCREEN is not a sprinkle of DISPLAY inside JOB; it is its own labeled activity with declaration statements, executable logic, and screen procedures at the end. A single source member may contain MAIN-MENU SCREEN, INQUIRY SCREEN, and PAYROLL-JOB for batch printing after online approval.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
* Library — shared files and fields
FILE CUSTMAST ...
DEFINE SCR-ACCT  W 10 N
DEFINE SCR-NAME  W 30 A
 
* Activity — online inquiry
SCREEN NAME ACCT-INQ
  TITLE 'Account Inquiry'
  ROW 5 COL 10 'Account:' SCR-ACCT
  ...
  EXIT
 
* Activity — batch report (EXECUTE from screen or scheduler)
JOB INPUT CUSTMAST NAME ACCTRPT
  PRINT ACCTRPT

Batch Versus Online Comparison

Easytrieve Online Runtime

Screen processing requires Easytrieve Online—the terminal-capable runtime Broadcom documents for supported platforms including z/OS TSO and CICS-style deployments per release notes. Pure batch JCL without online runtime cannot meaningfully execute SCREEN activities. Installation Site Options Table supplies default terminal dimensions, attribute keywords, and commit behavior SCREEN headers may override. Operations provisions transaction codes, terminal definitions, and security profiles separate from batch job scheduling.

Parts of a SCREEN Activity

1. SCREEN header — NAME, layout, COMMIT, BORDER, UPPERCASE options.
2. Declaration section — DEFAULT first, then TITLE, ROW, KEY in any order.
3. Executable statements — IF, MOVE, READ, GET between declarations and procedures.
4. Screen procedures — INITIATION, BEFORE-SCREEN, AFTER-SCREEN, TERMINATION, user PROCs.
5. Termination — EXIT, STOP, or TRANSFER required to end activity.

Screen Procedure Lifecycle

INITIATION runs once when SCREEN activity starts—open files, load tables. Each display cycle: RESET fields reinitialize, BEFORE-SCREEN prepares data and GETs records, product builds and sends screen, operator responds, AFTER-SCREEN validates and branches. TERMINATION cleans up at activity end. GOTO SCREEN, REFRESH, and RESHOW belong in AFTER-SCREEN flow points—not BEFORE-SCREEN per Broadcom restrictions documented on those procedure pages.

Combining Online and Batch

1
2
3
4
5
6
7
AFTER-SCREEN. PROC
  IF APPROVED-FLAG = 'Y'
     UPDATE MASTER
     EXECUTE JOB PRINT-APPROVAL-RPT
     EXIT
  END-IF
END-PROC

Operator approval on screen updates master file online, then EXECUTE runs named JOB activity that PRINTs formatted report using existing REPORT definitions batch developers already maintain. This hybrid uses batch formatting strengths without rebuilding report logic in screen declarations.

Screen Programming Topic Map

Design Principles for Beginners

• Reuse Library fields—prefix screen working storage SCR- to avoid batch collisions.
• Keep validation in AFTER-SCREEN; preparation in BEFORE-SCREEN.
• Define KEY F3 EXIT early so operators always have escape path.
• Document PF key layout matching shop terminal standards.
• Test pop-up ROWCOUNT/LINESIZE on smallest terminal model deployed.
• Plan COMMIT TERMINAL for CICS pseudo-conversational recoverability.

Common Beginner Mistakes

• Coding SCREEN logic inside JOB INPUT loop.
• Missing EXIT STOP or TRANSFER—compile error.
• GOTO SCREEN in BEFORE-SCREEN.
• Ignoring RESET field behavior between screen cycles.
• Expecting batch JCL alone to run SCREEN activities.
• Duplicating FILE definitions instead of sharing Library with batch.

Explain It Like I'm Five

Screen programming is making a form on the computer screen people fill out while they work. Batch programming is the computer printing a big pile of papers overnight by itself. Easytrieve lets you build the form and still use the same filing cabinet of customer information both ways. When someone presses Enter on the form, the computer checks their typing and shows the next page.

Exercises

1. Sketch SCREEN activity parts for a simple account lookup.
2. List five differences between JOB INPUT and SCREEN event flow.
3. Describe EXECUTE JOB pattern after online approval.
4. Name four special-name screen procedures and when each runs.
5. Identify which topics to read next for validation versus field layout.