SS$_NOSUCHDEV when running TCPIP$CONFIG

[john weed]

I am currently installing four HP Itanium 26xx serious platforms, each running OpenVMS831h1. Two of the installations went smoothly and are up and running. Two others both hit the same problem; while trying to execute the TCPIP$CONFIG command procedure. After completing the input for the domain name, the procedure moves on to configure the insterfaces. At this point an error pops up indicating that there is no such device (SS$_NOSUCHDEV). The command procedure aborts completely, backing out to the command prompt.

When trying to execute the interface portion specifically (without specifying All), the erros comes back saying that the host name must be specified of DHCP enabled. THe procedure aborts after that as well.

Bottom line is that I am unable to configure TCPIP as the command proecedure does not recognize any interfaces.

Help?

Also, the TCPIP version is the one that comes with the 8.3-1H1 factory installed installation5.6 if I remember.

Anyone ever come across this one?

[Steven Schweda]

> [...] 26xx [...]

"xx" = ?

> Anyone ever come across this one?

Not I.

Shell> info boot

Any interesting "%Exy0 [...]" messages at
boot time?

DCL$ show device e0

SET VERIFY on TCPIP$CONFIG.COM sounds
painful, but might be informative.

[john weed]

No strange messages at boot, or config or console.
Show device e shows all ethernet devices, ewa0, ewb0 and the ei series.
I'm stuck here in the sandbox with two worthless, EXPENSIVE Itaniums.
My left you know what for an Alpha.
This isn't platform dependent, it's something going on in the OS.
The other two systems came up fine, no problems.
But these two are basically expensive boat anchors.
Time to strap some C4 on them and use them as door openers!

Why is this so painful?
The message comes up twice, obivously for both EWA0 and EWB0.

The eia thru eid devices are there too.
It's just that TCPIP$CONFIG can't see the EW devices.
But I can manually configure them with UCX SET INTER WE0/Host=xxxxxxxx/Net= etc. and and UCX set route.... it'll work until reboot.
Some config file is jammed, for lack of a better word.
Damn

[Steven Schweda]

> The message comes up twice, obivously for
> both EWA0 and EWB0.

Obvious to you, perhaps. I prefer evidence.

> But I can manually configure them with UCX
> SET INTER WE0/Host=xxxxxxxx/Net= etc. and
> and UCX set route.... it'll work until
> reboot.

TCPIP HELP SET CONFIGURATION
TCPIP HELP SET CONFIGURATION INTERFACE

> Some config file is jammed, for lack of a
> better word.

Throw out TCPIP$SYSTEM:*tcpip*.dat (or some
subset thereof)?

[Hoff]

You're right. Something looks badly wrong here. What might be wrong here, unfortunately, is not yet clear.

New box? Call HP support.

As for here in ITRC? We can't help here without rather more detail around the device and the configuration. rx2600? rx2620? rx2660? Which NIC? New box? Bad hardware?

Please attach a text file with a SHOW DEVICE /FULL of the widget (there are many EW widgets), and post up a failed ALL configuration.

And as suggested earlier, clean out the old DAT files for TCP/IP Services, and try an ALL configuration. And call HP support, or whomever sold the boxes to you.

Given HP support will likely recommend it, I'd skip on the disk-based version of TCP/IP Services that arrived with the OpenVMS I64 V8.3-1H1 distro DVD; I'd download and try the V5.6 ECO4 (complete install) kit, or (as available) later. I'd expect your call to HP support will ask you to load that, as well as the current UPDATE for V8.3-1H1.

[john weed]

Thanks for the reply, resources are slim out here. The boxes are 2660s, and the devices that are failing are the EWA0 and EWB0, builtins, not the aded 4-port NIC card.

I'll do what I can for downloads of info, however they are on a classified LAN and getting anything off of them is problemmatic.

It used to be on the Alphas that the fastest way to readdress or change IP configurations was to just delete the TCPIP$*.DAT files form system and run the configuration file again. THis whoever no longer works.

I'll play with this tonight and try to supply more information.

[Hoff]

Download all of the ECO kits for OpenVMS and for TCP/IP, burn a disk, and bring the disk in. (Importing data into these environments is slightly easier than exporting data, in my experience. But given the reviews and paperwork that can be involved, only slightly.)

And call HP support; I'd expect there are folks there that can help service these boxes in this environment.

Classified LAN? I understand your pain here. But look at the bright side; at least you're not running multi-level here. That's really painful.

[john weed]

Once upon a time in a land far, far away was born a god child, and her name was Ami Murtha. And this child was an OpenVMS Goddess, that eclipsed the knowledge of her elders (me).

Thank you Ami... I barely pulled this one off.

All, the problem was all mine. The message was staring me right in the face.

When I did a Set Verify on the TCPIP$CONFIG, I didn't realize that the SS$_NOSUCHDEV was not pointing to EWA0:, but to the sys$pipe command.

Ami had seen this before and did a wiki and it turns out its a sys$pipe (or rather SYS$PIPEDRIVERF.EXE) lack-o-load that causes it.

If you do MCR SYSMAN IO CONNECT MPA0: /DRIVER=SYS$PIPEDRIVER /NOADAPTETR /LOG=ALL you will be able to execute the TCPIP$CONFIG with no problem.

Sad thing is that with over 25 yars of device driver writing experience on VMS 4 thru today I didnt see it. Too much sand in the eras I guess.

I still don't understand the relationship between killing the TCPIP$*.DAT files and the failure of sysd$pipe but at least I'm up and running.

Thanks for everybody's help.

Ami, there aren't words to explain what yoyu've just done for our country.

Long live OpenVMS!!!!!!!!!!!!!!!!!!!!!!

[Steven Schweda]

> Sad thing is [...]

Some might say that the sad thing is someone
thinking that what's failing inside the black
box is _obviously_ anything, when it is, in
fact, anything but obvious.