[Simh] Simh Digest, Vol 90, Issue 16

[Timothe Litt]

Ah, what that sounds like is:

The DZ is raising DSR to VMS too soon, starting a loginout process.  This
times out waiting for input (and 20-30 sec is about right).  VMS is
certainly doing the write.

Autobaud should just cost at most an extra CR.  What happens in real
hardware is that the baud rate is set (by the OS) to a middle value; a
character (often with a framing error) is accepted.  The bits are looked at
and the baud rate changed until the character is a clean CR, which is then
put in the OS's input buffer.  I don't think simh emulates framing errors or
malformed characters; so it should see a perfect <CR> every time.  

I'm not in a position to debug this at the moment, but a quick look at the
code indicates that the DZ's "modem control" mode is trying to run a state
machine for the modem control registers based on the host setting / clearing
DTR.  This is fine, but it doesn't seem to be interacting properly with tmxr
(the generic telnet terminal mux) offering a new connection.

This shouldn't be too hard to debug.  Sim_tmxr.c is the generic mux;
pdp11_dz.c is the DZ.  Pdp11_vh.c is the DHV.  New connection from tmxr
should look like RI from a modem.  DSR shouldn't set until some time after
DTR.  There are a couple of approaches to DTR - I'd have to look at the
terminal driver for VMS to see which it uses.  One is that DTR is left high
by the host, the other is that it's raised after seeing RI.  Real modems
generally assert RI when the telco sends a ringing voltage.  Sensible hosts
then raise DTR (so if they're down, they don't answer).  The modem goes
off-hook, and can take several seconds to establish carrier lock.  Then DSR
is asserted - and at that point the host will send data.  Data sent without
DSR may be dropped.

The simh logging will probably be helpful in sorting out exactly who's doing
what to whom.

Best I can do for now.

---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed. 
 
-----Original Message-----
From: Gary Lee Phillips [mailto:tivo.overo at gmail.com] 
Sent: Monday, May 23, 2011 14:31
To: Timothe Litt
Cc: simh
Subject: Re: [Simh] Simh Digest, Vol 90, Issue 16

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.
>