Easytrieve Screen Section

SCREEN as an Activity Type

Broadcom classifies SCREEN alongside PROGRAM, JOB, and SORT as an activity type within the Activity section. SCREEN is not optional syntax sprinkled into JOB—it is its own labeled block with executable statements and screen PROCs at the end. A program may contain both SCREEN and JOB activities: online menus that call batch reports are a classic pattern. PROGRAM activities can EXECUTE SCREEN or vice versa depending on flow design.

What SCREEN Activities Do

SCREEN activities define screen-oriented transactions. They display data to the terminal, accept operator input, validate entries against Library fields, read and update files, and branch based on function keys or input values. Unlike JOB INPUT loops that process every record in a file, SCREEN logic is event-driven by user interaction—each screen display and input cycle runs procedural statements tied to that panel flow.

Conceptual SCREEN Flow

1
2
3
4
5
6
7
8
9
10
SCREEN NAME INQUIRY
  DISPLAY PANEL1
  ACCEPT EMPNO
  IF EMPNO NE SPACES
     READ PERSNL
     DISPLAY PANEL2
  END-IF
  IF PF3 EQ ON
     STOP
  END-IF

INQUIRY labels the SCREEN activity. DISPLAY shows a defined panel layout. ACCEPT reads operator input into EMPNO. Conditional READ fetches personnel data when an ID was entered. A second DISPLAY shows detail. PF3 handling exits—exact key names and syntax follow your release documentation and shop standards. The point for beginners is sequential interactive logic rather than record-by-record batch iteration.

Library and Files in Online Programs

SCREEN programs still rely on Library FILE and DEFINE statements. The employee file PERSNL must be defined with correct layouts before READ or UPDATE in screen logic. Online updates demand extra care: concurrent batch jobs may update the same files, requiring coordination through record locking, transaction boundaries, or operational schedules documented at your site. SCREEN does not remove data definition discipline—it intensifies it because errors appear immediately to end users.

EXECUTE From SCREEN

Broadcom documents that SCREEN can EXECUTE JOB or SORT activities for processes like printing a report after the operator approves data. The batch JOB retains REPORT definitions and FILE layouts already in the program; SCREEN supplies the human trigger. Separate JCL may still be required for spool routing when batch EXECUTE runs inside an online session. Test both paths: pure batch JOB and SCREEN-triggered EXECUTE.

Screen Procedures

Screen PROCs modularize validation, repeated DISPLAY sequences, and error message handling. They appear after executable SCREEN statements, similar to job PROC placement. Shared PROCs reduce duplication when multiple panels validate employee numbers or date fields the same way. Keep PROC names distinct from job PROCs and REPORT PROCs to avoid cross-reference confusion in large programs.

Environment and Runtime Considerations

Online Easytrieve runs under the environment your installation configures—terminal access, security, and runtime libraries must be available to the online executor, not only batch STEPLIB in overnight JCL. PARM options affecting debugging may differ between test terminals and production sessions. ABEND analysis still applies: DEBUG STATE and FLOW help diagnose interactive failures when enabled for test users.

Design Guidelines

• Keep panel flows short with clear error messages tied to Library field definitions.
• Validate input before READ or UPDATE to avoid partial file changes.
• Document which SCREEN labels operators invoke from menus or transaction codes.
• Separate display-only inquiry from update transactions when security roles differ.
• When EXECUTE batch, confirm report DD routing works in the online execution context.

SCREEN vs Other Online Technologies

Mainframe shops also use CICS, IMS DC, or web front ends. Easytrieve SCREEN targets environments supported in Broadcom documentation for your release. Teams choosing SCREEN often already standardize on Easytrieve for batch and want one language for inquiry. Teams deep in CICS may call batch Easytrieve modules instead of SCREEN. Neither choice removes the need to understand Activity structure—only which activity type owns the UX.

Testing SCREEN Logic

1. Walk through happy path input with valid keys and expected file records.
2. Test invalid input, empty input, and boundary field lengths.
3. Verify PF key exits and error paths do not leave files half-updated.
4. Exercise EXECUTE batch paths and confirm reports route correctly.
5. Review security: who may DISPLAY sensitive fields defined in Library layouts.

Common SCREEN Mistakes

• Coding batch JOB INPUT loops inside SCREEN expecting file-driven iteration.
• Undefined panel or field names not declared in screen definitions.
• Updating files without validating operator authority at application level.
• Placing screen PROCs before executable SCREEN statements.
• Assuming batch JCL DD allocations apply unchanged to online execution.

Explain It Like I'm Five

A JOB activity is a factory machine that reads every box on a conveyor belt. A SCREEN activity is a help desk window. A person walks up, types a question, and you show an answer on the glass. Sometimes you still press a button that starts the factory machine to print a report— that is EXECUTE. The Library section still lists what is in the boxes even when you talk through the window instead of the conveyor.

Exercises

1. Sketch a two-panel SCREEN flow: search by ID, then show detail.
2. Explain when you would EXECUTE a JOB from SCREEN instead of coding report logic inline.
3. Compare where job PROCs and screen PROCs belong in program structure.
4. List three test cases for invalid operator input on a SCREEN transaction.
5. Describe one reason Library definitions matter equally for batch and SCREEN programs.