The replay host

The replay host plays a session recording (a .wndrec file from Session recording) as if it were the mainframe. Anything that drives a session can run against it: an AI agent in sandbox mode, an old emulator macro being checked before you trust it, a script you’re writing, or a test in your build pipeline. No mainframe, no risk to real data.

wnd-automate replay "payroll-signon.wndrec"
WND_REPLAY listening on 127.0.0.1:52817 (14 screens, loose mode)

Connect WND Terminal (or any TN3270 client) to 127.0.0.1 on that port. You see the recording’s first screen. Press the key the person pressed in the recording and the next screen appears. Press a different one and the same screen comes back with a line at the bottom: REPLAY: expected PF3, got Enter.

Each time a connection ends, the replay host prints a report:

{"keys":13,"played":13,"mismatches":[],"finished":true}

Loose and strict

• Loose (the default) checks the key only (Enter, PF3, PA1, Clear, ...).
• Strict (--strict) also checks what was typed into the fields, wherever the recording kept it. Hidden fields (passwords) and masked values (card numbers, your MaskPatterns) were never recorded, so they aren’t compared.

What it plays

Mainframe (3270) recordings, at their own screen size. Screens are rebuilt from the recording’s text and input fields, which is what programs and agents read. Colors aren’t sent. IBM i recordings are refused with a message saying so.

Where it’s used

• Agents. Sandbox mode opens every session on a replay host (see AI agents).
• Old emulator macros. The migration readiness report, Verify with a recording… in the Macros panel and wnd-automate macro verify check a macro by running it against a recording of a person doing the same task, in loose mode (see Run your existing macros). The readiness report does it for every macro with a .wndrec of the same name next to it.
• Your own tests. Start wnd-automate replay in CI and run your scripts against it.