Skip to content

OpenVMS

Iain Smith edited this page Sep 15, 2026 · 7 revisions

OpenVMS

veetee is developed against OpenVMS hosts and aims to behave exactly like a DEC terminal for DCL and screen applications.

Connecting

veetee --telnet vms1                  # TELNET service (TCP/IP Services, MultiNet, TCPware)
veetee --ssh system@vms1              # SSH server on OpenVMS
veetee --serial /dev/ttyUSB0          # console or terminal port, 9600 8N1 XON/XOFF
veetee --serial COM3                  # the same from Windows

Telnet sessions are 7-bit unless you ask for more: OpenVMS answers the Telnet BINARY option by putting the terminal in PASSALL, where DELETE stops erasing and DCL command recall goes with it. Add --telnet-binary for 8-bit controls on a host that handles them. See Connections.

Terminal characteristics

After logging in, let OpenVMS identify the terminal:

$ SET TERMINAL/INQUIRE
$ SHOW TERMINAL

/INQUIRE sends a Device Attributes request; veetee answers as the selected model (a VT420 by default, see Terminal Models), and OpenVMS sets the device type and its capabilities from the reply. To make this permanent, put SET TERMINAL/INQUIRE in LOGIN.COM, guarded by F$MODE() .EQS. "INTERACTIVE".

With --model vt520 or --model vt525 the reply identifies a VT500-series terminal instead, for applications that use VT500 features such as colour.

SSH sessions need the device type set by hand

/INQUIRE only reaches a terminal over Telnet, on the _TNAn: devices. On the pseudo-terminals an SSH server creates, _FTAn:, it is silent: OpenVMS sends no Device Attributes request at all, so there is nothing for veetee to answer, and the terminal type SSH carries in its pty-req is ignored as well. The device keeps the type it was created with — a VT102 on OpenVMS V8.4-2L3 with TCP/IP Services — and SHOW TERMINAL then reports No Eightbit, No Soft Characters and none of DEC_CRT2, DEC_CRT3 or DEC_CRT4, whatever model veetee is set to.

Set the type explicitly for those devices in LOGIN.COM, so Telnet sessions go on configuring themselves:

$ tt = F$GETDVI("TT","DEVNAM")
$ IF F$LOCATE("FTA",tt) .LT. F$LENGTH(tt) THEN -
      SET TERMINAL/DEVICE_TYPE=VT400_Series/PRINTER_PORT

Use VT500_Series with --model vt520 or --model vt525.

/PRINTER_PORT is there because /DEVICE_TYPE does not set everything the inquiry does. veetee's DA1 reports a printer port — parameter 2, as the hardware did — so a Telnet session comes up with Printer port set and an SSH session configured by device type alone does not. It only matters if something on the host drives the port, and a port is not a printer: DSR still answers CSI ? 13 n, no printer attached. If SHOW TERMINAL shows any other characteristic off that the model has, add it the same way: /EIGHT_BIT, /SOFT_CHARACTERS, /DEC_CRT4.

To see which of the two is happening on your own system, record a login and look for the request:

veetee --record inquire.vtrec --ssh system@vms1

Over Telnet the recording holds an H line carrying ESC [ c and the R line answering it, for a VT420 ESC [ ? 64;1;2;6;7;8;9;15;18;21 c. Over SSH it has neither, and no R lines at all.

You can also set characteristics explicitly:

$ SET TERMINAL/DEVICE_TYPE=VT400/EIGHT_BIT
$ SET TERMINAL/WIDTH=132
$ SET TERMINAL/PAGE=24

Applications

These rely on DEC features that veetee implements:

Application Features used
EDT, EVE/TPU Application keypad (PF1 Gold), editing keypad, scrolling regions, Help and Do keys
DECforms, FMS Protected fields and selective erase, DEC Special Graphics boxes, status line, double-size lines, 132-column mode
SMG$ screens Scrolling regions, line drawing, insert/delete line, video attributes
MAIL, PHONE, MONITOR Cursor positioning, double-size lines, 132 columns
DCL line editing Arrow keys, Ctrl keys, answerback

Keyboard layout: Keyboard. In EDT and EVE, Num Lock is Gold (PF1) and keypad / is Help (PF2).

Recording applications for testing

Real sessions become regression tests. Record one with checkpoints at the screens that matter:

veetee --model vt420 --record edt-keypad.vtrec --telnet vms1

Log in, work through the application, and press Ctrl+Shift+M at each screen worth checking. Then replay it:

vt-headless replay edt-keypad.vtrec --bless    # writes edt-keypad/checkpoint-01.screen, …

Read each screen against what the session showed. Recordings that are right go in tests/conformance/openvms/, where cargo xtask openvms replays them in CI. The checklist of applications still to record (EDT, EVE/TPU, MAIL, FMS, DECforms, MONITOR, SMG$ and SET TERMINAL/INQUIRE) is in that folder's README.

Typed keys are left out of a recording unless you add --record-keys, but everything OpenVMS prints is kept — the node name, the user name it echoes, file contents. Save recordings outside your git checkout and review them before sharing.

If a screen does not look right, please open an issue with a recording attached.

Tips

  • If DCL line editing or EDT keys behave oddly, check SHOW TERMINAL for the device type and whether ANSI_CRT, DEC_CRT (2–4) and EIGHT_BIT are set.
  • Hold Screen (F1) holds output without losing any, which is handy for long TYPE output.
  • The default VT420 scrolls smoothly, which makes long output slow; choose Jump Scroll in Display Set-Up and Save if you prefer speed.
  • Double-click selects a whole file specification, ready to paste into a command.

Clone this wiki locally