The cursor is the small blinking marker that shows where typing will go. On a 3270 terminal it is the operator's starting point every time a screen appears, so where you place it has a real effect on speed and accuracy. Put the cursor on the first field an operator should fill and they can start typing instantly. Put it on the field that just failed validation and they can correct the mistake without searching. Leave it unmanaged and the operator may waste keystrokes tabbing to the right place. This page explains what cursor positioning is, how the SCREEN runtime decides where the cursor lands, how to set it in BEFORE-SCREEN, the important pattern of moving the cursor to the field in error, default behavior when you say nothing, and the small habits that make data entry feel smooth. Cursor handling is a detail, but it is the kind of detail operators notice every single day.
On a full-screen 3270 display the cursor is where the next character the operator types will appear. It also determines where certain terminal actions begin. Because the whole screen is sent at once and the operator then works locally until they press a key, the cursor's starting position is fixed by what the program requested when it painted the map. If you request the account number field, the operator opens the screen already positioned to type an account number. That immediacy is the entire point of thoughtful cursor positioning.
Easytrieve lets you indicate the target field to the screen runtime before the display. The exact mechanism depends on the release: some use a CURSOR attribute or clause on a field, some expose a cursor field you set to the name or index of the target, and some let you mark a field as the default cursor location in the SCREEN definition. Whatever the spelling, the idea is the same—you name the field that should receive focus, and the runtime paints the cursor there when it transmits the screen.
| Method | How it works | When useful |
|---|---|---|
| Default field in SCREEN | Mark one field as the standard cursor home | |
| Cursor indicator set in code | Set a value naming the target field before display | |
| First unprotected field default | Runtime picks the first input field automatically |
Because the precise keyword and field name are release-specific, verify them in your SCREEN statement reference before coding. The patterns below use a placeholder such as CURSOR-FIELD to represent whatever your release provides; the reasoning transfers regardless of syntax.
BEFORE-SCREEN runs immediately before the screen is painted, which is exactly when the cursor target must be known. On a fresh inquiry screen you set the cursor to the primary input field so the operator can begin. On a data entry screen with several fields you place it on the first one in tab order. The assignment is simple: name the field, and let the runtime handle the rest.
123456BEFORE-SCREEN. PROC PERFORM LOAD-DISPLAY * Position cursor on the primary input field CURSOR-FIELD = 'ACCT-NO' SCR-MSG = SPACES END-PROC
The most valuable use of cursor positioning is error handling. When AFTER-SCREEN detects an invalid field it records both a message and which field failed. On the next display, BEFORE-SCREEN reads that record and positions the cursor on the failing field. The operator sees the error message and finds the cursor already sitting on the field they must fix. This single behavior makes correction feel effortless and is a hallmark of well-built screens.
123456789101112131415161718192021AFTER-SCREEN. PROC IF ACCT-NO EQ SPACES SCR-MSG = 'ACCOUNT NUMBER REQUIRED' ERROR-FIELD = 'ACCT-NO' ELSE IF NOT NUMERIC(ACCT-NO) SCR-MSG = 'ACCOUNT MUST BE NUMERIC' ERROR-FIELD = 'ACCT-NO' ELSE ERROR-FIELD = SPACES PERFORM LOOKUP-ACCOUNT END-IF END-PROC BEFORE-SCREEN. PROC PERFORM LOAD-DISPLAY IF ERROR-FIELD NE SPACES CURSOR-FIELD = ERROR-FIELD ELSE CURSOR-FIELD = 'ACCT-NO' END-IF END-PROC
The two procedures cooperate: AFTER-SCREEN diagnoses and records the problem field, BEFORE-SCREEN acts on that record when repainting. Keeping the error field name in a dedicated working field (here ERROR-FIELD) keeps the logic clear and lets you extend it to multiple fields later.
If you never set the cursor, Easytrieve applies a default—commonly the first unprotected field on the screen in row-column order. For a screen with a single input area that default is often fine. The trouble appears on richer screens: the first unprotected field may not be the one the operator should fill first, and after an error the default ignores which field failed. Relying on the default is acceptable for prototypes, but production screens benefit from explicit positioning that you control on every cycle.
Output fields are protected so the operator cannot type into them. Placing the cursor on a protected field is confusing—the operator sees the cursor but cannot type, and the terminal may move focus unpredictably. Always target an unprotected input field. If a screen is display-only with no input fields at all, let the default apply or position on a field associated with the primary action, and rely on PF keys for navigation.
On list screens that page with PF7 and PF8, decide where the cursor belongs after a page change. A common choice is the first data row or the command field, so the operator can immediately act on the newly displayed page. Set this in BEFORE-SCREEN based on the navigation the operator just performed. Consistency matters: if paging always lands the cursor in the same logical spot, operators build muscle memory.
The cursor is like the tip of your pencil on a worksheet. When the teacher hands you the sheet, it is nicest if the pencil is already resting on the first blank you need to fill in, so you can start right away. If you write a wrong answer and the teacher hands it back, the best teachers put your pencil right on the mistake so you know exactly what to fix. We should not rest the pencil on a spot that is glued shut—those are the read-only areas you cannot write on.
1. Cursor positioning on a screen controls:
2. After a validation error, good practice is to place the cursor on:
3. Where do you normally set cursor position for the next display?
4. If you never set the cursor, the runtime usually:
5. The cursor should be placed on a protected field: