Presentation-layer guide

How to Modernize IBM i Screens Without Rewriting RPG

Selective presentation work fits a specific kind of problem: the host application is reliable, but a bounded workflow is difficult to learn or visually dense. This guide explains the safeguards that keep an interface improvement from becoming an accidental rewrite.

By S-Block Technologies LLCPublished August 8, 2026Updated August 8, 2026

The short answer

A 5250 application can gain a clearer browser interface without moving its business rules out of RPG. A presentation template reads the current, redacted host screen, binds approved controls to exact host fields, and sends edits and terminal keys through the same live session. RPG still validates input and Db2 still records the transaction.

This approach is useful when the application works but selected workflows are difficult to learn, visually dense, or exposed to users who do not need the full terminal vocabulary.

Start by separating three goals

Teams often use “modernization” to describe different projects:

  • Access modernization replaces a workstation install with managed browser entry.
  • Presentation modernization changes how selected host fields and actions appear.
  • Application modernization changes program structure, interfaces, data architecture, or language.

These goals can support each other, but they have different cost, risk, and outcomes. A screen template is not a substitute for API design or code remediation. It is also not necessary when experienced operators prefer a dense Classic terminal.

What a safe presentation layer must preserve

Exact screen identity

A template should not activate because a few words happen to look familiar. PristineScreen400 recipes match exact rows, columns, literal text anchors, and field geometry. If the fingerprint stops matching, the workspace returns to Classic view.

Host field protection

A protected host field cannot become an editable browser control. A non-display field cannot become readable text. Field length, state, keyboard lock, workspace revision, and terminal sequence are checked again when input is submitted.

Host actions

A modern button maps to one approved terminal key such as Enter or F10. It does not contain arbitrary JavaScript, SQL, commands, macros, or program calls. That keeps the browser presentation inside the established host workflow.

A complete fallback

Classic view remains the complete terminal. It covers unmatched screens and gives users a direct return path while a template is active. This limits the blast radius of a presentation defect or host-screen change.

Choose screens based on work, not appearance

A practical first template is a frequent, bounded workflow with clear fields and actions. Good candidates often have:

  • a stable 24 by 80 layout;
  • a small number of meaningful inputs;
  • known validation and return paths;
  • measurable training or navigation friction;
  • no dependency on unsupported printer or workstation behavior.

Avoid beginning with an entire application inventory. First prove that one workflow can preserve host behavior, improve comprehension, and return safely to Classic.

When deeper modernization is the better choice

Choose APIs, RPG Open Access, source conversion, or a rewrite when the goal is to remove the 5250 dependency, reorganize business logic, support a new channel with independent workflows, or change the data and integration architecture. Those projects can create capabilities a presentation template cannot.

A responsible roadmap may combine approaches. Browser access can solve an immediate delivery problem, templates can improve high-value screens, and deeper work can proceed where the business case justifies it.

Evaluation checklist

  1. Record the authoritative host screen dimensions and anchors.
  2. Identify protected, editable, and non-display fields.
  3. List every terminal key and validation transition.
  4. Define the browser components and labels without adding new business behavior.
  5. Test matched, unmatched, stale, locked, error, and Classic fallback states.
  6. Publish a version and assign it only to reviewed grants.
  7. Observe real use before selecting the next workflow.

Authoritative references

Choose the first screen

Evaluate one bounded workflow before planning a wider rollout.

A useful review records the screen fingerprint, editable and protected fields, host actions, failure states, and Classic fallback before any template is proposed.

Request a demo