sys$node logical doesn't persist through reboot

JustinDoss — Fri, 05 Aug 2016 19:47:08 GMT

I run tcpware's net$configure.com and the logical sys$node gets defined but when I reboot for some reason that logical is lost. My other systems do not do this and can't figure out why.

Re: sys$node logical doesn't persist through reboot

Hoff — Fri, 05 Aug 2016 22:47:10 GMT

SYS$NODE is a logical name defined by the DECnet network stack, so — if you don't have DECnet around — you shouldn't have and shouldn't expect that logical name to be defined.

The TCPware package should not be defining that logical name, either. That it's defining that (and not cleaning up) is arguably a bug in that package, and I wouldn't depend on that behavior continuing to work over upgrades.

There is (also?) a net$configure.com configuration command procedure that's used for DEC/Compaq/HP/HPE DECnet-Plus network product — what's also called DECnet Phase V or DECnet/OSI — and that's not related to TCPware. (I don't know off-hand if there is a similarly-named configuration tool in TCPware.) That package is associated with the SYS$NODE logical name,

if you're looking to configure DECnet-Plus here and not TCPware, then have a look at the available documentation (installation and configuration, and management) , and ensure that the installation and system configuration is correct and that prerequisite settings are correct and that the software licenses are installed and such — DECnet-Plus is a fairly complex package to configure and operate — and if there are any errors being logged during the OpenVMS system bootstrap.

DECnet-Plus doesn't usually require adding a startup to SYSTARTUP_VMS.COM, though some DECnet-Plus components can require that. If that's failing, it's usually due to a parameter or licensing or a bad configuration.

If you have some local code that requires that logical name and you cannot change the associated code (and if you're using TCPware here and not DECnet-Plus, or if you don't care what network stack is in use) then the hack-around is to DEFINE the logical name during the local system startup procedure. That can include adding a DCL command to DEFINE /SYSTEM /EXECUTIVE SYS$NODE {whatever} to create that logical name somewhere in SYSTARTUP_VMS.COM, for instance. Basically, make the TCPware misbehavior into your own misbehavior. That'll work, at least until DECnet — either Phase IV or Phase V / DECnet-Plus — gets involved or until some other misbehaving software also defines that logical name.

If you want the host name of the local OpenVMS server (and that's why you're looking for SYS$NODE here), then there are numerous places where OpenVMS itself and various common layered products and tools store a host identification string, and there's no particular consistency across the names and lengths involved, nor around the retrieval of that information, nor around how to modify the name. Of of the various choices for the host name, I'd probably use the name associated with the OpenVMS system parameter SCSNODE and the f$getsyi or sys$getsyi calls to retrieve the preferred host name value.

Re: sys$node logical doesn't persist through reboot

Ruslan R. Laishev — Mon, 08 Aug 2016 06:27:20 GMT

Hi !

TCPWare-TCP configuration is the TCPWARE:CNFNET.com

topic Re: sys$node logical doesn't persist through reboot in Operating System - OpenVMS

sys$node logical doesn't persist through reboot

Re: sys$node logical doesn't persist through reboot

Re: sys$node logical doesn't persist through reboot