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 <l...@ieee.org> wrote: > > VMS is actually pretty well documented; this stuff isn't as mysterious as > folks seem to think. > _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh