Vax Console Input not Enabled

[Glenn_D]

I'm working with a Vax 4000-100 with a VT520 as the system console. It's pretty basic with only a three-bay StorageWorks attached, running OpenVMS V7.3. The machine startup is fine, you type in your boot command and sometime during the boot process, the console input is disabled. I can log on remotely and find no other problems; I can boot from the sysboot> prompt, using default settings and the console is fine. I have looked at startup and login files but I am not a VMS expert and see no obvious problem. The console still gets OPCOM messages, just no input. Maybe someone could point to some places to look further?

[Steven Schweda]

My old VAXes just work, so I know nothing,
but I'd start with:

SHOW TERMINAL OPA0

Look for "[No] Type_ahead". If it's "No",
then that might explain everything.

> [...] sometime during the boot process, the
> console input is disabled. [...]

Well, I'd say that it's disabled at the
beginning, and gets (re-)enabled late in the
start-up sequence (if ever).

[Hoff]

This is back in the era when OPCOM could occasionally (and erroneously) grab the console port.

To determine if this is the case and in addition to the SHOW TERMINAL, issue a SHOW DEVICE /FULL and see if there's an (non-zero) owning process PID listed for the console.

There were AFAIK patches, or (as most of us did) you simply disabled OPCOM output on the console.

[Bob Blunt]

Glenn, there's also another possible issue. Check to see if and/or when your startup procedure does a $ SET LOGIN/INTERACTIVE. Until that command is issued OPA0 will not allow login.

If you're able to login from another terminal or a remote system check the various suggestions that others have suggested. Also check OPA0 to see what it's terminal characteristics have become. Check for broadcast, broadcast mailbox, typeahead... I'm stretching my memory here and no longer have access to Notes that cover the issue with $ SET LOGIN, but I vaguely remember that in some circumstances you could still login from remotes or other terminals. All are worth a look to check. If you could post the output from $ SHOW TERM OPA0 as an attachment somehow that would help.

bob

[Volker Halle]

Glenn,

welcome to the OpenVMS ITRC forums.

When talking about 'input' on OPA0:, you are certainly expecting to get a Username: prompt, when typing at the console terminal. The fact that you can type >>> B shows, that the physical connection between the VT520 and the OPA0: serial port is o.k.

Some VAX 4000 systems have this 'annoying' feature, that you can't immediately login on the console terminal, once startup has finished. Sometimes you have to wait a little bit, maybe a couple of minutes. Did you try that ?

Please also check SHOW TERM OPA0: and SHOW DEV/FULL OPA0: - as requested.

Try to login from remote and issue a SET LOGIN/INTER=128, then try to login on the console again, if the previous checks did not show a problem.

Volker.

[Glenn_D]

Okay, let me try to make this clearer. I power up the machine and get what I call the boot prompt which is three chevrons, >>>. At this point I can type in commands, everything looks normal. I then type a boot command like >>>boot DKA100. System seems to boot normally, I get the usual "job terminated" message and the accounting information. Now I have no input from the VT520 keyboard. I can log on remotely and do whatever I want from a PC.
To answer some questions:
Current login interactive login limit is 64. Setting it to 128 made no difference. Current interactive value = 1, does this mean that my remote is one and OPA0 is not interactive?
I find no place in startup files where it calls for $ SET LOGIN/INTERACTIVE, but that may only be due to not looking in the right place. The "show terminal OPA0" file shows the device as interactive.
I've attached a couple of Word files for reference if anyone cares to look further. This has been running a good while like this, but it would be nice to get my console back.

[Steven Schweda]

> I find no place in startup files [...]

search sys$startup:*.com "/interactive"

> The "show terminal OPA0" file shows the
> device as interactive.

That's all it says? Really?

> Okay, let me try to make this clearer.
> [...]
> I've attached a couple of Word files [...]

And if I were sitting at a Windows system I
might care. (That's clearer?)

[Volker Halle]

Glenn,

when posting session output from a terminal session in an OpenVMS related forum, it would be appreciated, if you include simple plain ASCII .TXT files. Use cut & paste or the session log file function of your terminal emulator and post a .TXT file as an attachment.

Your OPA0: terminal is set to /TYPE_AHEAD and /INTERACTIVE, so that would be fine. Unfortunately the SHOW DEV OPA0:/FULL output is missing.

The SET LOGIN/INTER=n command will be executed from VMS$LPBEGIN-050_STARTUP.COM with a value of n = startup$interactive_logins - this global symbol could be defined in your startup files.

Did you try logging in on OPA0: after waiting for a couple of minutes after the 'Job terminated' message ?

To show, that physical input still works on OPA0:, once the system has booted, try this:

In your remote TELNET session, issue the following commands:

$ OPEN/READ/WRITE x OPA0:
$ READ/PROMPT="Hallo: " x line

Then you should see the "Hallo: " prompt on your OPA0:, enter some text and press on OPA0:

Then return to your TELNET sessiom , which should be at the DCL prompt again. Enter $ SHOW SYMB line - you should see your response typed on the OPA0:

Then don't forget to enter $ CLOSE x on your TELNET session, otherwise you'll block your OPA0: terminal from logging in again, because you have still a channel assigned to OPA0:

If the OPEN/READ/WRITE x OPA0: command fails, you might have found the problem ! Some other process may have a channel assigned to OPA0:

Volker.

[The Brit]

Glenn,
Could it be because the Device Type: is LA36 (which if I remember correctly is a Dot Matrix Printer.)??

Dave.

[Verne Britton]

did the VT520 ever work?

if so, then what has changed (VMS updates, wiring changes, etc) since then ?

WAG - VMS changes the baud rate or modem controls or something, resulting in the vt520 not being set properly ... I noticed AutoBaud is disabled ...

have you tried any other terminal (or terminal emulator) ... any other cables or adapters ... again just a wild guess.

Interesting problem :-)

Verne

[Glenn_D]

Sorry if my attachments were not politically correct. I'm a technician with Unix, Linux, Windows, DOS, OpenVMs, IOS and GE and Siemens PLCs. Not an expert at anything, just working on a problem.
I have several of these Vax 4000-100 systems running, each with VT520 consoles. I can move this boot drive from one to another and the problem moves with the drive. I can boot another drive in this machine and everything works, so I'm fairly certain that it is a login/startup file type problem. The machine has a login.com file that sets the terminal to a vt200, yet OPA0 boots up as an LA36. Can't find where that comes from.
Anyway, I work a swing shift and am working off. I'll post the attachments and get back on it next week. Thanks for help and guidance!

[Glenn_D]

Seems that I can only attach one file per session

[Glenn_D]

The login.com file

[Hoff]

The console terminal is "owned" by a process, which means you won't be able to log in until the device is freed up.

The owner process is listed as 00000104.

SHOW PROCESS /ID=104 /ALL

will tell you which process it is.

It's common to see OPCOM here. That's the error I mentioned earlier.

There have been cases back in this version range where the console can be owned by a non-existant process, which means that SHOW command will generate an error.

First stop is probably the mandatory ECOs.

Start at:

ftp://ftp.itrc.hp.com

And navigate through the links for the OpenVMS VAX V7.3 patches. Here are some pages that can help you decode the terms and concepts here:

http://labs.hoffmanlabs.com/node/348
http://labs.hoffmanlabs.com/node/570

If your OpenVMS VAX box has network connectivity outward to the network, you can fetch files from DCL directly using command-line FTP or via the FTP utility.

http://labs.hoffmanlabs.com/node/136

If you're more familiar with the Unix-style ftp utility, that too is available. (If there's an IP stack installed, and given you're connected from a Microsoft Windows box, that appears likely - IP is typical here, but a few boxes back in this era also had DECnet connectivity with Windows.)

The console ownership error is usually resolved by applying the "current" patches for this OpenVMS VAX V7.3 configuration.

As for which patches you need here, there's usually a "master listing" of patches stored in a text file in the directory.

I've attached the basic patch sequence as a text file and (at the end, where I use the unzip command to see what's in that) you'll RUN the ZIPEXE file to get the text file. That'll give you a flavor of what to expect.

Also at the end of the file, you'll see what the SHOW PROCESS /ID command for the local OPCOM process looks like.

(The example was from an Alpha, so there are various display differences.)

[Volker Halle]

Glen,

this is the problem:

Owner process ID 00000104

If OPA0: has a channel assigned or is owned by ANY process, you cannot login on OPA0:

Please first find the owner process with the process-id of 104

$ SHOW SYSTEM/ID=104

You can verify, that that process has a channel assigned to OPA0:

$ ANAL/SYS
SDA> SET PROC/IND=104
SDA> SHOW PROC/CHAN

... look for OPA0: in Device/File accessed column.

SDA> EXIT

Then look at your other systems, if there also is a process with that name.

Before you consider installing patches, try to verify the problem first. I couldn't find any mention of OPCOM or OPA0: in the OpenVMS VAX V7.3 patch description .TXT files.

Volker.

P.S. you could have easily put the output of all 3 commands into one .TXT file and attached that file.