07 · Screens
Green screens are fast. Respect that.
An experienced operator on a terminal can outrun most web forms. Don't copy the layout, and don't lose the speed either. Specify the task, then measure against what people can already do.
CICS and 3270 · at Tidewater
One screen hid a whole process.
Marcus Bell moves misapplied payments with transaction TWPY. The Standard specifies Payment Correction as a process, so this screen becomes a request, a human review and an automated apply.
TWPY ANCHOR CORE 11/05/26
PAYMENT CORRECTION
FROM LOAN : HCB000148810
PAYMENT ID : 0009914207
AMOUNT : 1,234.70
TO LOAN : HCB000148801
REASON CD : 04
ENTER=VALIDATE PF5=APPLY PF3=EXIT
Code: PCR ## Stages 1. Request (human, skill: reconciliation) 2. Review (human, skill: reconciliation) 3. Apply in Payments and Anchor Core (automated) 4. Notify the bank (automated) 5. Close (automated) ## Rules - PCR-001: A corrected payment and its suspense entry change together, or neither changes. - PCR-002: The person who reviews a correction is not the person who requested it.
TWPY updates the payment and suspense entry in one CICS unit of work. That guarantee was invisible to users and can't be lost, so PCR-001 states it. The apply stage crosses into Anchor Core, so it's a posting with its own direct and indirect rules, like Post Late Fee.
The terminal had no second reviewer. Adding PCR-002 changes how the work is done, so it's a recorded decision that the operations manager made, not something the migration carried over.
Marcus enters a TWPY correction in 14 seconds, without a mouse. The request form is accepted against that number, using the Standard's keyboard-first task forms. Type-ahead and predictable field order are what make it possible.
Pseudo-conversational CICS programs keep state between screens in a COMMAREA. Read it closely, because it shows what the task needs to carry from one step to the next.
KeelTrack's DDS display files retire with the product, but staff depend on the screen's F4 prompt for looking up collateral. That goes on the product's acceptance list.
Web interfaces · at Tidewater
The rule only the browser knew.
BankLink is newer than the terminals, and it has a problem they don't: its second-approver check for large payoffs runs only in the page. The bulk upload path never loads that page, and six production payoffs went straight through.
if (payoffAmount > 250000 && !secondApprover) {
showError("Second approver required");
}
The bulk upload path doesn't run this.
## Parameters | Parameter | Type | Meaning | |------------------------|-------|--------------------| | second approver limit | money | Above this, two | | | | people must agree | ## Rules - PQ-003: A payoff above the bank's second approver limit needs a second person's approval, whichever way it was requested.
The method treats this as a fixed defect, with a follow-up on the six payoffs. The limit becomes a tenant parameter too: Granite Valley's caution was always a setting waiting to happen.
Rules
MIG-025 to MIG-028
- MIG-025
A screen is specified by the task it serves, not by its layout.
- MIG-026
A high-volume task's time on the terminal is measured, and its replacement is accepted against that number.
- MIG-027
Data that a source transaction committed together is stated as a rule about what succeeds or fails together.
- MIG-028
A rule found only in a user interface is restated in a spec, so that every path into the system obeys it.