Connections

veetee opens one connection per session. Choose it on the command line; without one, veetee runs your login shell.

Option	Connection
(none)	Your login shell ($SHELL; Command Prompt on Windows) on a local pseudo-terminal
--command 'CMD'	Any program, run with /bin/sh -c (cmd /C on Windows)
--telnet HOST[:PORT] or telnet://HOST:PORT	Telnet (port 23 by default)
--ssh [USER@]HOST or ssh://USER@HOST	SSH through the system OpenSSH client
--serial DEVICE	A serial line: /dev/ttyUSB0 on Linux, COM3 on Windows
--port PORT	TCP port for --telnet or --ssh

Add --sessions N to open up to four sessions (on a VT520 or VT525) to the same destination in one window, or open each with New Session, which asks where it connects (see Sessions).

Saved connections

Connections… in the window menu lists saved connections. Open one in a new window with its arrow button, or add, edit and delete them; Save as Connection… saves the current window's connection. Each has a name, a type (Telnet, SSH, serial line, local shell or command) with its host, port, device or command, serial line settings, the terminal model, phosphor, one or two sessions, and optionally a log file.

They are kept in ~/.config/veetee/profiles.toml (%LOCALAPPDATA%\veetee\profiles.toml on Windows), which can be edited by hand:

[profile](/issinoho/veetee/wiki/profile)
name = "vms1"
connection = "telnet"         # shell, command, telnet, ssh, serial or lat
host = "vms1"
model = "vt420"
phosphor = "green"
log = "~/logs/vms1-%Y%m%d.log"
log-timestamps = true

[profile](/issinoho/veetee/wiki/profile)
name = "console"
connection = "serial"
device = "/dev/ttyUSB0"
baud = 9600
parity = "n"                  # n e o m s
flow = "x"                    # x (XON/XOFF), h (RTS/CTS), n

veetee --profile vms1 opens one from the command line; options given with it override it (for example --profile vms1 --model vt520). veetee --list-profiles lists them. A window opened from a saved connection is titled with its name.

The default connection

The star beside a connection in Connections… makes it the default: what veetee opens when it is started without a connection, such as from the application launcher, instead of your login shell. Click the star again to go back to the shell. The connection editor has the same choice as a Default connection switch, so Save as Connection… can set it in one step. Only one connection is the default at a time.

It is saved as default-profile at the top of profiles.toml, before the first [profile](/issinoho/veetee/wiki/profile):

default-profile = "vms1"

Options such as --model or --phosphor still apply to it, as they do to --profile. Anything that names a connection — --profile, --telnet, --ssh, --serial, --lat or --command — overrides it, and veetee --shell opens your login shell whatever the default is. --list-profiles marks the default. A default-profile that names no saved connection is reported rather than ignored: veetee says so on stderr and opens the login shell, so a mistake in the file never keeps the terminal from opening.

Logging a session

Log to File… in the window menu writes the active session's text to a file as it arrives, until it is chosen again. The log holds the characters as the terminal shows them — DEC line drawing and national characters as Unicode — with a line break for each new line; the status line is left out. Timestamp Log Lines starts each line with the date and time.

Option	Does
--log FILE	Adds the session's text to FILE; ~ and %Y %m %d %H %M %S are expanded
--log-timestamps	Starts each logged line with the date and time
--log-raw	Logs the host's bytes exactly as received instead

Telnet, SSH and serial windows stay open when the connection closes, so you can still read and copy the final screen. Local shells and commands close their window when they exit.

Telnet

veetee has its own Telnet client. It negotiates:

• TERMINAL-TYPE — the model name, e.g. VT420
• NAWS window size, SUPPRESS-GO-AHEAD, ECHO and terminal speed
• BINARY, for 8-bit DEC control characters and the DEC Multinational set, but only when asked

BINARY is offered with --telnet-binary, or telnet-binary = true in a saved connection, because OpenVMS answers it by putting the terminal in PASSALL: the driver passes input through untouched, so DELETE stops erasing and DCL command recall goes with it. A host that proposes BINARY itself is still answered. SET TERMINAL/INTERACTIVE undoes an earlier session's PASSALL.

F5 (Break) sends a Telnet BREAK.

SSH

SSH runs your system ssh -tt (on Windows, the OpenSSH client that ships with Windows). Keys, agents, ~/.ssh/config, ProxyJump and known_hosts therefore behave exactly as they do in a shell. TERM is set to the model's terminfo name (vt420 by default). Password prompts appear in the terminal window.

veetee --ssh system@vms1
veetee --ssh vms1 --port 2222

OpenSSH only sends a BREAK through its escape sequence: press Return, then type ~B.

On Windows the client runs on a pseudo console, which reads its output as UTF-8 and so destroys 8-bit C1 controls; use Telnet, or SET TERMINAL/NOEIGHTBIT, for hosts that send them (Windows).

Serial lines

veetee --serial /dev/ttyUSB0                                  # the saved Set-Up: 9600 8N1, XON/XOFF
veetee --serial /dev/ttyUSB0 -b 19200 -d 7 -p e -s 1 -f h     # picocom-style options
veetee --serial COM3                                          # Windows

Option	Values	Default (saved Set-Up, else DEC factory)
-b, --baud	bits per second	9600
-d, --databits	5, 6, 7, 8	8
-p, --parity	n none, e even, o odd, m mark, s space	n
-s, --stopbits	1, 2	1
-f, --flow	x XON/XOFF, h RTS/CTS, n none	x

The line comes from Communications Set-Up, as on the terminal (from 1.6.0): --serial opens with the saved Set-Up, and the options change what they name for that connection, as does a saved connection's own line. Set-Up then shows what the line is doing, and leaving Set-Up with a new speed, data format, stop bits or XOFF changes the line at once — the window's subtitle follows, and a port that refuses a setting is left as it was, with a message. On a VT500 model the host can change the line too, with DECSCS, DECSPP and DECSFC; OpenVMS's SET TERMINAL/INQUIRE puts the terminal in VT200 mode, so a procedure selects VT500 level first:

$ esc[0,8]=27
$ write sys$output esc+"[65;1""p"+esc+"[1;7*r"     ! VT500 level, then 19200 baud
$ set terminal/speed=19200

To change the speed of an OpenVMS terminal port by hand, change it at the host (SET TERMINAL/SPEED) and then in Set-Up; on a port with Autobaud, log out, change Set-Up, and press Return at the login. Set-Up's DSR and DTR flow control are RTS/CTS on the port.

The port is opened for exclusive use. F5 sends a line break. F1 (Hold Screen) stops reading, so the host is flow-controlled just as with the Hold Screen key on a real terminal.

On Linux, join the dialout group and log in again to use a serial port without root:

sudo usermod -aG dialout $USER

Terminal servers (RFC 2217)

The serial line options work with --telnet as well as --serial. Given with --telnet they ask a terminal server — a DECserver, Lantronix or Moxa — to set up the line behind it, using Telnet COM Port Control:

veetee --telnet decserver:2001 --baud 19200 --parity e --flow h

F5 then sends a real line break down that line rather than a Telnet BREAK, and a saved connection keeps the settings. Leaving Communications Set-Up with new ones asks the server for them again, while connected (from 1.6.0). The option is offered only when line settings are given, so an ordinary host never sees it.

LAT

LAT (Local Area Transport) is DEC's own terminal protocol. It runs straight on Ethernet rather than IP, so it reaches only machines on the same segment, and there is no host name and no port: a node announces itself, and you ask it for a service.

veetee --lat MYI64                    # the node, as it announces itself
veetee --lat MYI64 --interface eth0   # where more than one Ethernet interface is up
veetee --lat MYI64 --service TERMINALS    # a service other than the node's own name

The interface is worked out where only one Ethernet interface is up. A wireless one is offered but never chosen: a segment with DEC equipment on it is a wired one. In the connection dialog, choose LAT, and the button beside Node lists what is announcing itself — pick a node rather than typing it. Announcements come about once a minute, so the list fills in as they arrive.

OpenVMS treats it as one of its own. SET TERMINAL/INQUIRE at login identifies veetee as Device_Type: VT400_Series and sets the line up for a VT420, on an LTA device it creates for the session.

Linux only, and it needs a capability. Raw Ethernet takes CAP_NET_RAW, which nothing that draws a terminal should hold — and GTK refuses to start with it at all — so a small helper opens the socket and hands it back. The capability is not granted when veetee is installed:

sudo setcap cap_net_raw+ep /usr/libexec/veetee-lat-helper

Again after every upgrade. The capability is an attribute of the file, so it survives reboots and logins but not a new package: installing a new veetee replaces the helper, and the new one has none until it is granted. veetee says as much when it finds it cannot open a socket, naming the path it looked in, and the row carries a button that puts the command on the clipboard.

Be aware what the grant allows: anyone who can run the helper can open a socket for LAT frames on one interface and send them. That is much narrower than CAP_NET_RAW itself, the socket carrying one protocol, but it is not nothing.

LAT cannot work in the Flatpak at all. Its sandbox refuses a raw Ethernet socket outright, and no capability changes that, so use the package or the tarball. There is no raw Ethernet on Windows either, without a driver.

vt-headless lat INTERFACE prints every LAT message on a wire, slot by slot, which is how the protocol was read; --connect NODE opens a session without a window. veetee's implementation is clean-room from packet captures of OpenVMS LATACP rather than from latd, which is GPL, and what has been read is written down in lat-protocol.md. See Roadmap.

File transfer

Send File… and Receive File… in the window menu transfer files with Kermit over any of these connections; see File Transfer.

Recording a session

--record FILE.vtrec records a session: everything the host sent, the terminal's replies, and named checkpoints. Press Ctrl+Shift+M, or choose Mark Checkpoint in the window menu, whenever the screen shows something worth checking.

veetee --record edt.vtrec --telnet vms1
vt-headless replay edt.vtrec --bless     # write edt/checkpoint-01.screen, …
vt-headless replay edt.vtrec             # later: compare the screens again

Typed keys are left out unless you add --record-keys, so passwords do not end up in the file. The host's output is recorded, though, including anything it echoes (such as your user name) and the text of every screen. Review a recording before sharing it.

A .vtrec file is plain text: a header with the terminal configuration, then one line per event with a timestamp and base64 data. Recordings of real OpenVMS applications become tests; see OpenVMS and Conformance Testing.