Easytrieve SCREEN Statement — Activity Definition Guide

Full SCREEN Header Syntax

1
2
3
4
5
6
SCREEN [NAME screen-name] [COMMIT (...)] +
  [UPPERCASE] [ROWCOUNT rows] [LINESIZE columns] +
  [ROW screen-start-row] [COL screen-start-column] +
  [BACKGROUND ATTR attribute-name] +
  [BORDER {SINGLE|DOUBLE|WIDE|'literal'} [ATTR ...]] +
  [SHADOW]

Plus signs continue the SCREEN header across source lines per Easytrieve continuation rules. NAME labels the activity for EXECUTE references and documentation—use meaningful names like EMP-INQUIRY not SCREEN1. COMMIT clauses control transaction boundaries. Layout parameters override Site Options Table defaults for this activity only.

NAME Parameter Rules

Screen-name may be up to 128 characters. It may begin with A–Z, 0–9, or national characters (#, @, $), must not be all numeric, and may contain non-delimiter characters. PROGRAM EXECUTE SCREEN NAME and SCREEN EXECUTE SCREEN NAME jump between activities. Meaningful names appear in compile listings and audit documents operators trust during incident response.

Layout Parameters Explained

Pop-Up Window Behavior

When LINESIZE and ROWCOUNT are smaller than the physical terminal, Easytrieve displays the screen as a pop-up window over prior content. Fields visible from previous screens that remain underneath receive ASKIP—operators cannot type into stale panels. In TSO and CMS with dual presentation sizes, Easytrieve selects presentation size from screen dimensions. Design modal dialogs—confirm delete, error detail—with explicit smaller ROWCOUNT; design full-screen menus with dimensions matching default terminal to avoid accidental ASKIP on underlying data entry rows.

Declaration Section Structure

After the SCREEN header, declarations describe panel content. DEFAULT must appear first—it sets baseline attributes for fields unless ROW or KEY overrides. TITLE supplies screen title text. ROW places literals and fields at coordinates. KEY defines PF keys with NAME text and actions EXIT, IMMEDIATE, or procedure targets. KEY, TITLE, and ROW may follow DEFAULT in any order per Broadcom, though teams often group TITLE then ROWs then KEYs for readability.

1
2
3
4
5
6
7
8
9
10
11
12
13
SCREEN NAME MAIN-MENU UPPERCASE ROWCOUNT 24 LINESIZE 80
  BORDER DOUBLE
 
  DEFAULT ATTR (GREEN NEUTRAL)
  TITLE 'Employee Maintenance Menu'
  ROW  6 COL 10 'Enter option:'
  ROW  8 COL 12 WS-MENU-OPT VALUE ('V' 'E' 'X') +
         ERROR 'Valid options: V E X'
  ROW 10 COL 14 'V — View'
  ROW 11 COL 14 'E — Edit'
  KEY F1  NAME 'Help' IMMEDIATE
  KEY F3  NAME 'Exit' EXIT
  KEY F12 NAME 'Cancel' EXIT IMMEDIATE

Activity Start and End

How SCREEN activities start

EXECUTE from PROGRAM or another SCREEN starts a named activity. If the program has no PROGRAM activity, the first SCREEN in source order executes automatically when the run begins. INITIATION procedure runs once at activity start before the first display cycle.

How SCREEN activities end

Processing continues until EXIT, STOP, or TRANSFER. Broadcom compiles an error if none appear— infinite screen loops strand operators. EXIT ends the SCREEN activity normally. STOP may end broader execution depending on context. TRANSFER passes control per online runtime. Distinguish EXIT from STOP EXECUTE which halts all Easytrieve execution abnormally.

COMMIT Options

Explicit COMMIT and ROLLBACK inside procedures provide finer control when shop standards require multiple units of work within one SCREEN activity. Coordinate with DBA on Db2 cursor and hold behavior when mixing COMMIT TERMINAL with file UPDATE.

Screen Procedures After Declarations

Special-name procedures bracket runtime: INITIATION, BEFORE-SCREEN, AFTER-SCREEN, TERMINATION. User-defined PROC names modularize shared validation. Procedures may appear in any order after declarations though maintenance teams group special names predictably. Broadcom restricts certain statements in specific procedures—study BEFORE-SCREEN and AFTER-SCREEN pages before placing GOTO SCREEN or file GET in wrong hooks.

SCREEN Versus JOB in One Program

JOB loops on file records with automatic INPUT. SCREEN responds to operator events. Both share Library. Pattern: SCREEN updates approval flag on master, EXECUTE JOB PRINT-APPROVAL-RPT reuses batch REPORT definitions. SCREEN statement names the online half; JOB names the batch half—do not merge them into one activity type.

Testing SCREEN Definitions

1. Compile with Easytrieve Online; confirm no missing EXIT error.
2. Verify DEFAULT appears before other declarations.
3. Test pop-up dimensions on minimum terminal size.
4. Confirm F3 EXIT works from every panel state.
5. Validate COMMIT behavior with test Db2 updates on CICS if applicable.

Common SCREEN Statement Mistakes

• DEFAULT after ROW declarations—ordering violation.
• No EXIT STOP or TRANSFER path.
• NAME all numeric or missing when EXECUTE requires it.
• ROWCOUNT too small truncating ROW definitions off screen.
• Expecting SCREEN header alone without declarations and procedures.

Explain It Like I'm Five

The SCREEN statement is the title page of a workbook for one computer form. It says the form name, how big the paper is, and whether letters you type become capitals. Inside the workbook you draw the lines and boxes (declarations), write what happens when someone fills it out (procedures), and say how to close the workbook when done (EXIT).

Exercises

1. Write SCREEN header with NAME BORDER UPPERCASE for a 24×80 menu.
2. Add DEFAULT TITLE three ROW lines and two KEY definitions.
3. Explain pop-up behavior when ROWCOUNT 10 on 24-row terminal.
4. Document COMMIT TERMINAL impact for pseudo-conversational design.
5. List three ways a SCREEN activity can start.