Installing OpenVMS on x86-64 system

[r010159@comcast.net]

Some time ago I received my “Community License Package” with a url for downloading OpenVMS. Recently I have downloaded the package and apparently ended up with a couple files that represent a virtual disk where the OS has been installed. So I created a virtual machine per instructions found online. I attached this virtual drive to the VM. I see an async console is required. However, I found instructions to enter in the VM config file to permit a putty session between my Linux VM and this VM.

Please note that I am using a 2019 iMac (64-bit x86) running the Sanoma MacOS. I am using the latest version of VMWare Fusion. I booted from the boot loader using the “BOOT” command. The VM window instructs me “Graphical output has been Suspended” and “Use a terminal utility for access”. I cannot find a local address to connect to from my Linux VM.

I do not know how to solve this problem after much searching on the Internet. Can anyone help me?

Thank you!

UPDATE:

I did telnet to 127.0.0.1 using the socket number I specified in the VM config file. The connection was refused.

Bob

[cct]

I believe VSI does not support Ethernet over WiFi, so you would need to connect the host to the router with an ethernet cable. You could then access access the VM over WiFi

[sms]

Code: Select all

> [...] Around here: [...]

   Regarding Telnet (and/or FTP) on a Mac, I failed to mention that
Apple (in its wisdom) has ripped out the Telnet (and FTP) client and
server from High Sierra (10.13) and onward.

   I've been transplanting these clients and servers from an older macOS
version (into /usr/local -- the clients are easier than the servers),
and then forgetting about the extra work until the next major macOS
upgrade.

   A Web search should find a few different alternative schemes to get
similar results, in case you don't have a sufficiently obsolete Mac
lying around.

[r010159@comcast.net]

Thank you for the help. It worked. Now when I get to the part where I set the new password, it aborts with an invalid syntax error message. I need to find out what the syntax is. I guess one step at a time.

Bob

[sms]

Code: Select all

> [...] I need to find out what the syntax is. [...]

   Pick one without special characters?  RTFM?

      https://docs.vmssoftware.com/

   I don't remember if there's a way to get to any HELP on this before
getting logged in, but it's easy enough after:

ITS $ help set password

SET

  PASSWORD

[...]
       A user password can contain up to 32 alphanumeric and special
       characters. Unless your system manager has set the PWDMIX flag
       in your authorization account record, the only special characters
       permitted are the dollar sign ($)  and underscore (_). Without
       the PWDMIX authorization, all lowercase characters are converted
       to uppercase before the password is encrypted. For example,
       "eagle" is the same as "EAGLE."

       If you have PWDMIX authorization, you can specify uppercase and
       lowercase alphabetic characters, and you can use any special
       characters in the printable character set. However, avoid using
       characters that have special significance for layered products
       that accept passwords. For example, a double quotation mark (")
       would be unacceptable in a password in a DECnet access control
       string.
[...]

   The safer assumption would be that PWDMIX is not defined by default.

[dgordon]

"Invalid syntax" almost always means your connection to the console is sending CRLF and the CR is being captured as the last character of your "new password." Although that case causes login failure as well. Depends on if this is the password set request during installation, or as part of expired password processing during login.

The acceptable password character set for an account without the PwdMix bit set is A-Z0-9$_ case-blind. If PwdMix is set, passwords may contain any printable, non-whitespace character and are case sensitive. That means that if PwdMix is clear, and your password is "mycleverpassword" and you then set PwdMix, then you must log in with "MYCLEVERPASSWORD".

[r010159@comcast.net]

Thank you very much for your help! Can you answer just one more question? First off, I did “mode char” in the telnet app which helped. I created the new password before I did this. Now VMS is not recognizing my new password. I cannot get into the mode with the “$” sign prompt to resolve this by setting a new SYSTEM password. I am so close now. I have been waiting forty years for this chance to use VMS again, so I can wait some more.

Bob

[sms]

Code: Select all

> [...] Now VMS is not recognizing my new password. [...]

   At some point it becomes advantageous to take all your hard-won VM
knowledge, and apply it to a freshly unpacked VMDK.  (If you've never
been able to log in, then you can't have done much customization of the
VMS system.)

[r010159@comcast.net]

Yes. That should work.

[bobwilson]

I've found that In addition to:

telnet> mod char

...that I need to do:

telnet> unset crlf

I don't know if that will solve your issue, but that's what I do (I use iTerm on macOS Monterey (12.7.5) with VMWare Fusion [in addition to VBOX])

[sms]

Code: Select all

> telnet> unset crlf

   I recently tried VirtualBox (7.1.4) on a Mac (mini 2018, Sequoia
15.1), using an XQuartz xterm and telnet (from an older macOS version),
and had what seem to be the usual problems with telnet.

   What I ended up doing was:

      telnet> mode character
and:
      telnet> unset echo

   My experimentation (fiddling) suggested (to me) that the VirtualBox
"serial" interface is not a full-featured telnet server, and hence it
does not properly negotiate the telnet settings, which leaves the client
in its default, "old line by line" mode, which implies local echo. 
According to "man telnet":

     In ``character at a time'' mode, most text typed is immediately sent to
     the remote host for processing.

     In ``old line by line'' mode, all text is echoed locally, and (normally)
     only completed lines are sent to the remote host. 

   I was seeing behavior like:

$ type nl:
type nl:
$ 

where the real problems seemed to be line-by-line mode and local echo,
not really CRLF.  However, these telnet options are sufficiently tangled
that either pair of commands seems to yield the same result.  Before:

telnet> status
Connected to localhost.antinode.info.
Operating in obsolete linemode
Local character echo
Escape character is '^]'.

   After these:

      telnet> mode character
      telnet> unset crlf

telnet> status
Connected to localhost.antinode.info.
Operating in single character mode
Catching signals locally
Remote character echo
Escape character is '^]'.

   And after these, it's the same:

      telnet> mode character
      telnet> unset echo

telnet> status
Connected to localhost.antinode.info.
Operating in single character mode
Catching signals locally
Remote character echo
Escape character is '^]'.

   So, your choice.

   The most annoying part of all this is that the ~/.telnetrc file
appears to be useless in this situation.  My interpretation of the docs
is that the ~/.telnetrc file is processed once, when the program starts.
This is before the connection is made.  Then, the problem settings are
negotiated when the connection is made.  Thus, when dealing with a
brainless telnet server, ~/.telnetrc can't override these (antique)
default settings, and the victim is forced to do that manually.

   But, if anyone has wiser wisdom, I'd be interested.