[Simh] Simh Digest, Vol 90, Issue 16

[Gary Lee Phillips]

Thanks for the detailed explanations. I do have access to much of the
standard VMS documentation, though most of what I have is for version
5.x. Knowing what the parameters on SET TERM should mean is not
usually the problem, though occasionally the manuals will be overly
terse. (As in "Set the XYZ parameter to turn on XYZ" without any
explanation of just what XYZ meant to VMS.) Much of the OpenVMS 7.3
documentation was available on the HP support site until recently, but
now it seems to have disappeared or at least to have been moved so
that all I am finding is for the Alpha 8.3 version. Most, but not all,
of that should still apply I think.

My comment about secrets and hints was more related to the behavior of
SIMH and the VAX emulations based on it. What I have seen for the DZ
(DH11) and VH (DHV11) emulated devices is extremely terse and doesn't
really tell you what signals will be sent or honored between OPENVMS
and the virtual device, or how those are translated into TELNET
protocol. Hence my careful testing of each possible parameter in as
many combinations as possible. That is faster, in my case, than trying
to read the source code to puzzle it out.

I did report earlier in the thread that the Operator log records a
"timeout waiting for input" when using the DZ virtual device for any
session after the very first one. This is what the 20-30 second delay
is. At the terminal window in telnet, however, it appears that input
is just not being accepted. The keyboard is dead for that 20-30 second
interval, and no prompt has yet appeared on the screen. Somewhere in
the handshake between VMS, the VAX emulation, and the device
emulation, there is a mismatch so that VMS seems to think it has sent
a prompt but the telnet screen doesn't display one, and telnet input
is apparently not getting through to VMS. After the timeout takes
place, then you get a login prompt by pressing enter and everything
proceeds as it should. When you logout, the timeout issue returns for
the next session. I would expect that setting the -am options on the
pseudodevice in vax.ini should take care of this by making all lines
act like modem connections, but it seems to make little difference.

The VH virtual device does not suffer from this apparent bug. However,
it seems to have no way to limit the number of terminal lines it
activates, and always generates a full 32 terminals as if four DHV11
cards were installed.

In all cases with both devices, whether the terminal is set AUTOBAUD
or NOAUTOBAUD, it still does not prompt for login until the enter key
has been pressed (and actually received, in the case of DZ, which is
"deaf" during the timeout period.)

--Gary

On Mon, May 23, 2011 at 1:05 PM, Timothe Litt <litt at ieee.org> wrote:
>
> VMS is actually pretty well documented; this stuff isn't as mysterious as
> folks seem to think.
>