1.1.2: the fault underneath the other three, and a second retraction Troubleshooting said the LAT freeze was fixed in 1.1.1. It said the same of 1.1.0 this morning. Both were wrong, and 1.1.1 is the worse of the two: it kills a session within minutes of any login. The page now leads with the fault that was killing every session underneath the others -- a new sequence number taken for every message sent, acknowledgements included, against a host that acknowledges only what carries slots, so the gap grew by one every keepalive until it passed MYI64's queue limit of 24 and the host stopped accepting anything at all. The three credit and acknowledgement faults found on the way are kept below it, each with the version it belongs to, because each was real. The trace section gains `kernel=in/dropped`, which tells a loss veetee inflicted on itself from a loss on the wire, and says what `unacked` should look like -- the number that was in the first trace of the day and went unread. Releases, Home and Getting Started carry 1.1.2 and say plainly that 1.1.0 and 1.1.1 are both to be avoided for LAT.
1.1.1, and a correction: 1.1.0 is the release to avoid for LAT Troubleshooting said the LAT freeze was fixed in 1.1.0. It was not. 1.1.0 introduced a worse version of the same fault, and anyone reading that page today would have drawn the opposite conclusion from the truth. It now gives both faults a version apart: what 1.0.0 got wrong by counting only what arrived, what 1.1.0 got wrong by reading the gaps in the numbering without counting the host's own acknowledgements, and why the result looked frozen rather than disconnected -- veetee sent LAT's keepalives from the first and did none of its deciding, so it went on acknowledging into a circuit the host had already released. Releases, Home and Getting Started carry 1.1.1 and say it should be taken in preference to 1.1.0.
1.1.0: the LAT credit fault, Close Session, and the signing order Releases gains a 1.1.0 paragraph, and Making a release gains a step that has now been got wrong twice: the winget manifests must be pointed at a release *after* the Windows zip is signed, because signing replaces both the zip and SHA256SUMS. Troubleshooting gains a section for the fault itself -- a LAT session going quiet after a while on a wire that drops frames -- saying what it looked like, that 1.1.0 fixes it, and how to watch a session with VEETEE_LAT_TRACE, including that the DATA variant writes the password out in clear. Using veetee gains Close Session, and says why a lone session keeps its screen when it ends while one of two does not. Roadmap is deliberately untouched: what 1.0 does not do is all still true, and 1.1.0 closed none of it.
LAT: the two reasons a wire looks silent Both cost an afternoon getting two OpenVMS nodes to see each other, and neither says anything about itself: the symptom of each is silence, which reads like a protocol that does not work. OpenVMS answers nothing if LATCP has not been told to allow connections, whatever services the node offers. And a guest on QEMU/KVM behind macvtap is never given the multicast: it asks for the group, the request is not passed to the host interface, and the guest hears nothing while announcing into the void. Both are in Troubleshooting beside the interface being on the wrong segment, since all three look the same from the browser.
0.8.10: what to do when LAT cannot open a socket Troubleshooting gains a LAT entry, which is where somebody stuck will look: each message it can give, what to type, and the two things that catch people out -- that the capability goes again with every upgrade, since it belongs to the file, and that granting it to veetee itself stops the program starting at all. Connections says the same about upgrades, mentions the button that copies the command, and states plainly that the Flatpak cannot do LAT at all rather than leaving it as a clause at the end.
OpenVMS: SSH sessions need the device type set by hand SET TERMINAL/INQUIRE only reaches the terminal on Telnet (_TNAn:) devices. On the SSH server's pseudo-terminals (_FTAn:) OpenVMS sends no Device Attributes request and ignores the pty-req terminal type, so the device keeps its created type (a VT102 on V8.4-2L3 with TCP/IP Services) and loses Eightbit, Soft Characters and DEC_CRT2-4. Confirmed from session recordings of the same host from the same client: the Telnet login carries ESC [ c with veetee's ESC [ ? 64;... answer, the SSH login carries no request and no replies at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Flatpak, screen readers, faster output, Windows signing
VT500 menu Set-Up, Display Controls and fonts; release 0.7.1
Set-Up, sound, smooth scroll and CRT effects
Update for 0.6.0: Windows, keymap editor, key programming, recordings, fonts
Add veetee documentation Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016YDmAmHSpzviSn4u4VuqKw