Strange message(s) in TCPIP Startup

[Peter Quodling]

Recently upgraded to V5.4 TCPIP and VMS 7.3-2

TCPIP Startup was report the following, and hating error messages, I went to track down the causes of the "nomore" messages.

The first one was easy enough - changes in the use of laarge buffers...

TCPIP set conf comm/dev=0/large=(free:0,max:0,min:0)/small=(free:0,max:0,min:0) fixed it.

The second one remains... (re "ALL COMMUNICATION OPTIONS" ) Obviously some thing, somewhere is trying to do something that is no longer valid. Any ideas?



%RUN-S-PROC_ID, identification of created process is 00000814
Starting TCP/IP Services for OpenVMS ...
␍␊%TCPIP-I-INFO, TCP/IP Services startup beginning at 25-JUN-2005 15:23:50.15
%TCPIP-I-NORMAL, timezone information verified
%RUN-S-PROC_ID, identification of created process is 00000819
%TCPIP-I-SETLOCAL, setting domain and/or local host
%TCPIP-I-SETCOMMP, setting communication parameters
%TCPIP-I-NOMORE, parameter or qualifier COMMUNICATION OPTIONS no longer support♦
%TCPIP-I-STARTCOMM, starting communication
%TCPIP-I-SETPROTP, setting protocol parameters
%TCPIP-E-CONFIGERROR, error processing configuration request
-TCPIP-E-INETERROR, internet interface error
-SYSTEM-F-BADPARAM, bad parameter value
%TCPIP-I-NOMORE, parameter or qualifier for ALL COMMUNICATION OPTIONS no longer♦
%TCPIP-I-DEFINTE, defining interfaces
%TCPIP-I-STARTNAME, starting name service
%TCPIP-S-STARTDONE, TCP/IP Kernel startup completed
%TCPIP-I-PROXYLOADED, loaded 0 NFS proxy records
%TCPIP-I-LOADSERV, loading TCPIP server proxy infor

[Robert Gezelter]

Peter,

Just a thought. Have you tried undoing the changes in the large buffers and seeing whether the message disappeats?

- Bob Gezelter, http://www.rlgsc.com

[Peter Quodling]

Bob, close but no cigar - you have misread - The first of the two NOMORE Messages was cleared by the buffer change - I am trying to determine the cause of the second one "ALL COmmunication options".

q

[John Gillings · Accepted solution]

Q,

Sounds like obselete procedures being executed. Are there any (old) TCPIP$*.COM procedures in the SYS$SPECIFIC root?

You didn't say where you upgraded from...

I guess if you're really desperate you could wipe the config and start from scratch.

Personally I'd be less interested in the -I-NOMORE message (it's not an error, it's informational). What about the -E-INETERR, internet interface error?

Check out SHOW CONF INTERFACE. Maybe there's an interface defined for a device that no longer exists?

[Peter Quodling]

Sounds like obselete procedures being executed. Are there any (old) TCPIP$*.COM procedures in the SYS$SPECIFIC root?

Most of the files in sys$specific:[000000...]tcpip$*.com have a date of 27-Apr-2005. Apart from a few in sys$examples: it would appear that lpd and bind are the only candidates.

Prd > dir [...]tcpip$*.com/before=1-apr-2005

Directory SYS$SPECIFIC:[000000.SYS$STARTUP]

TCPIP$LPD_SYSHUTDOWN.COM;2
1/9 26-SEP-2001 10:11:26.08
TCPIP$LPD_SYSTARTUP.COM;2
1/9 26-SEP-2001 10:11:25.96

Total of 2 files, 2/18 blocks.

Directory SYS$SPECIFIC:[000000.SYSCOMMON.SYSMGR]

TCPIP$BINDSETUP.COM;1
76/81 18-SEP-2003 20:20:34.14
TCPIP$BIND_CLUSTER_SETUP.COM;1
26/27 18-SEP-2003 20:20:35.46

Total of 2 files, 102/108 blocks.



There are still a bunch of UCX files - none of those should be being "read", but I will change their names to check.

You didn't say where you upgraded from...

Q>7.3-1 to 7.3-2 and TCPIP 5.3 to 5.4 (plus ECO's)

I guess if you're really desperate you could wipe the config and start from scratch.

Q> Pass... This place is a rats nest of undocumented interdependencies... Fixing bugs is like lifting rocks, and watching
the spiders scurry off.

Q> ON a related note, lots of people have privs, and lots of people seem to like changing routes on the system. Is there an easy way to protect against, or at least log route changes?

Personally I'd be less interested in the -I-NOMORE message (it's not an error, it's informational). What about the -E-INETERR, internet interface error?

Q> That has actually disappear that is in relation the the "big buffers change" which I had already found and fixed.. From "Startup.log" (gotta love startup_p2), I now get

list communication lo
show configuration interface
exit
$
$ if .not. $status
$ endif
$
$ tcpip start communication /initialize
%TCPIP-I-SETLOCAL, setting domain and/or local host
%TCPIP-I-STARTCOMM, starting communication
%TCPIP-I-SETPROTP, setting protocol parameters
%TCPIP-I-NOMORE, parameter or qualifier for ALL COMMUNICATION OPTIONS no longerâ ¦
%TCPIP-I-DEFINTE, defining interfaces
%TCPIP-I-STARTNAME, starting name service
$ if $status
$ then
$ call log_info "%TCPIP-I-INFO, TCP/IP network started"
$

Q> THis all appears to be generated within the command "tcpip start communication/initialize" in tcpip$inet_startup.com

Check out SHOW CONF INTERFACE. Maybe there's an interface defined for a device that no longer exists?

Nothing untowards there...
Prd > tcpip show conf interface

Interface: LO0
IP_Addr: 127.0.0.1 NETWRK: 255.0.0.0 BRDCST:

Interface: IE0
IP_Addr: 203.18.108.11 NETWRK: 255.255.255.0 BRDCST: 203.18.108.255

Interface: IE1
IP_Addr: 203.15.127.18 NETWRK: 255.255.255.240 BRDCST: 203.15.127.31

Interface: IE2
IP_Addr: 10.101.22.164 NETWRK: 255.255.255.248 BRDCST: 10.101.22.167
Prd

[Wim Van den Wyngaert]

In UCX you have set comm /allow_log that can be put as /all=xxx. And this option is no longer supported.

But if that is the option that caused the problem, you should have had the problem before the upgrade too.

Did you do
$ sea sys$startup:*tcp*.com "/all" ?

Wim

[Wim Van den Wyngaert]

It seems that start comm/init only accesses tcpip$configuration.dat (and the host file but nothing could be in that to create this problem). So, something invalid must still be present in the config. You could try tcpip set config comm/noallow to remove the setting.

Wim

[comarow]

These is a tcipip eco 5 rcently released.