OK. If you're on Linux, then the tn5250 app is reading from stdin. You should be able to drive it as a child process via IO::Pty (or open2/open3)and send it the same escape sequences that it expects to see.

e.g., to simulate pressing an up arrow to tn5250, you'll send a short character sequence to it's standard input.

You can work out which chars to send by hitting the docs or just running tn5250 under 'strace' and seeing it reads from fd 0 (the read(0, "...") bit when you hit the key.

You'll get the screen contents back from the stdout of the tn5250 process. These will contain escape sequences suitable for the terminal which tn5250 thinks you're running (probably vt100), which you could interpret and write the data at the appropriate offset in a screen buffer.

So, you'll end up emulating keystrokes to the tn5250 and understanding the escape sequences it sends back, so not a trivial task. It's perhaps also one which is prone to deadlock, if you're doing blocking reads from the app, so you'll probably want to use nonblocking reads if you can.

Maybe I've misunderstood, but I think that's what would be required. (Well, or re-implementing the 5250 network protocol your console app uses, or pulling apart the console app so you can call into it as a C API wrapped in XS, or adding (or finding) an existing scripting mechanism for this app, or...

Ah...CPAN goodness, there's Term::VT102 which might help a lot.

Perhaps by studying the sourcefiles you can learn more about this protocol. The project also has some termcap and terminfo files which detail the codes used to drive the terminal.