Easytrieve Screen Field Validation

Validation Architecture

Think of validation as a funnel. Terminal attributes and VALUE lists filter keystrokes and required presence at field level. AFTER-SCREEN applies business rules on complete panel input after Enter or IMMEDIATE key. Only when all layers pass should READ/UPDATE/WRITE modify production files. Splitting responsibilities prevents duplicating the same IF in three PROCs and prevents UPDATE before format checks complete.

Declarative VALUE and ERROR

1
2
3
ROW 8 COL 10 SCR-OPT VALUE ('V' 'E' 'D' 'X') +
       ERROR 'Valid options: V View E Edit D Delete X Exit'
       MUSTENTER

VALUE enumerates allowed values—typically single-character menus or short codes. Operator typing outside list triggers ERROR message on redisplay. MUSTENTER blocks empty submission. Combine with UPPERCASE on SCREEN header so lowercase v matches V in VALUE list when product translates input.

Attribute-Based Validation

NUMERIC restricts keys to numeric characters—use on account numbers and amounts when DEFINE is numeric. MUSTFILL requires every position in field length filled—useful for fixed-length codes. MUSTENTER requires some input. INVISIBLE fields still validate when used for password entry. ALARM draws attention on error highlight per terminal support. Attributes apply on ROW; DEFAULT can set baseline MUSTENTER for all input fields in simple forms.

AFTER-SCREEN Validation Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
AFTER-SCREEN. PROC
  IF SCR-ACCT EQ 0
     SCR-MSG = 'Account number required'
     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
  SCR-MSG = SPACES
END-PROC

AFTER-SCREEN runs after operator input. Zero account fails business rule VALUE cannot express. READ validates existence on master. Success MOVEs output fields; failure sets SCR-MSG and GOTO SCREEN redisplays inquiry panel. Broadcom permits GOTO SCREEN in AFTER-SCREEN—not in BEFORE-SCREEN.

Cross-Field Validation

1
2
3
4
5
6
7
8
9
10
AFTER-SCREEN. PROC
  IF SCR-END-DATE LT SCR-START-DATE
     SCR-MSG = 'End date must be on or after start date'
     GOTO SCREEN
  END-IF
  IF SCR-AMOUNT GT SCR-LIMIT
     SCR-MSG = 'Amount exceeds approval limit'
     GOTO SCREEN
  END-IF
END-PROC

Compare multiple screen fields after complete panel entry. Amount versus limit may READ approver profile first. Document cross-field rules in screen design spec so testers know invalid combinations to exercise.

Table SEARCH Validation

Department or status codes validate via SEARCH on TABLE files—same pattern as batch LOOKUP. AFTER-SCREEN SEARCH DEPTTAB WITH SCR-DEPT GIVING SCR-DEPTNAME; IF NOT DEPTTAB set message and GOTO SCREEN. Combines reference data integrity with online input without SQL for small code tables.

Modular VALIDATE Procedures

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
AFTER-SCREEN. PROC
  PERFORM VALIDATE-ACCT
  IF ERR-FLAG EQ 'Y'
     GOTO SCREEN
  END-IF
  PERFORM VALIDATE-AMOUNTS
  IF ERR-FLAG EQ 'Y'
     GOTO SCREEN
  END-IF
  PERFORM UPDATE-MASTER
END-PROC
 
VALIDATE-ACCT. PROC
  ...
END-PROC

Shared VALIDATE. PROC modules keep AFTER-SCREEN readable when rules grow. ERR-FLAG or SCR-MSG convention signals failure. PERFORM order matters—cheap format checks before expensive READ of large files.

Error Message Field Design

• Dedicate SCR-MSG or SCR-ERR row at bottom of panel—ASKIP protected.
• Clear SCR-MSG on successful validation before next action.
• Use ATTR color RED or YELLOW on message row for visibility.
• Keep messages short—terminal width limits; avoid technical SQL codes for operators.
• Log technical detail to audit file in PROC while showing friendly text on screen.

Validation Versus BEFORE-SCREEN

BEFORE-SCREEN prepares display—GET next record, MOVE defaults, clear prior input areas. Do not validate operator typing there; it has not arrived yet. Do not GOTO SCREEN in BEFORE-SCREEN. INITIATION opens files once—not per-validation. TERMINATION cleanup runs at activity end—not per failed field.

IMMEDIATE KEY Validation

KEY F1 IMMEDIATE processes help without full Enter on other fields. KEY definitions may PERFORM help PROC before redisplay. Validation for IMMEDIATE keys runs in key handler path—ensure help keys do not accidentally trigger UPDATE paths meant for Enter confirmation.

Safe Update Ordering

1. Declarative attributes and VALUE checks (automatic on input).
2. AFTER-SCREEN format and presence checks.
3. AFTER-SCREEN file and table existence checks.
4. AFTER-SCREEN cross-field and authority checks.
5. UPDATE or WRITE only after all pass.
6. COMMIT per SCREEN COMMIT rules after successful update.

Common Validation Mistakes

• UPDATE in BEFORE-SCREEN before input validated.
• GOTO SCREEN in BEFORE-SCREEN.
• No message when validation fails—operators see blank screen.
• VALUE list not matching UPPERCASE SCREEN behavior.
• Duplicate validation in ROW and PROC with conflicting rules.
• READ without IF NOT file handler—wrong data displayed as valid.

Explain It Like I'm Five

Validation is the teacher checking your homework before it goes in the grade book. VALUE is the list of answers allowed for question one. AFTER-SCREEN is the teacher reading the whole page— dates must make sense, account must exist. If something is wrong, you get the paper back with a note at the bottom (ERROR message) and fix it before turning it in again.

Exercises

1. Add VALUE ERROR MUSTENTER to four-option menu ROW.
2. Write AFTER-SCREEN READ with not-found message and GOTO SCREEN.
3. Implement cross-field date validation PROC.
4. Design ERR-FLAG pattern with two PERFORM validation modules.
5. List validation steps in order before UPDATE master file.