TCPIP question

[Willem Grooters]

I ran into the following problem in TCPIP 5.0, ECO 1 on VMS 7.1-2:

$ UCX SET SERVICE SPILCOM -
/PORT=6001 -
/PROTO=TCP -
/PROCESS=UCX_SPILCOM -
/USER=BPS_SPIL -
/FILE=DISK26:[USERS.SPIL]SPILCOM.COM -
/LIMIT=10 -
/INACTIVITY_TIMER=1 -
/SOCKET_OPTIONS=NOKEEPALIVE
$ UCX ENABLE SERVICE SPILCOM
$ UCX SET CONFIG ENABLE SERVICE SPILCOM
%TCPIP-E-CONFIGERROR, error processing configuration request
-SYSTEM-F-BADPARAM, bad parameter value

Trying the very same on VMS7.3-1, TCPIP 5.3 ECO 1, I did not get the error, it just succeeded.

Solution:

UCX SET CONFIG ENABLE NOSERVICE SPILCOM

So 5.3 is somewhat more intelligent, or will my permanent database contain 'lost data'?

I wonder, where is this database located, so I can have a look....



Willem

[John Gillings]

Willem,

The TCPIP SERVICE data base is pointed to by the logical name TCPIP$SERVICE, or, by default in SYS$SYSTEM:TCPIP$SERVICE.DAT. It's a binary file, so, if you really want to peek, try DUMP/RECORD. You're better off examining the data with the TCPIP SHOW SERVICE command.

The TCPIP$SERVICE data base holds information about the services. The configuration (SET CONFIG) just contains names of services to be enabled. (the file is TCPIP$CONFIGURATION.DAT) So:

TCPIP SHOW SERVICE
TCPIP SHOW CONFIGURATION SERVICE ENABLE

should show you all you need.

I have no explanation for the BADPARAM error, but since it's from such an old version, and you have been unable to repeat the condition on a newer version, it's probably not worth investigating

[Robert Atkinson]

Willem,
I'm running 5.1 eco 3, and have a similar problem.

I set up a couple of services in the database, but initially got the parameters wrong.

Any subsequent attempts to correct the parameters or start the service just came back with an error.

The only course of action left at the time was to delete the services database and recreate everything from scratch.

I still have a residual problem on one node, with starting the services. Doesn't matter what SET CONFIG commands I use, whenever we reboot the node, the service does not automatically restart itself. Luckily this is on a test machine, so it's not too critical.

It would be nice if you could show what's in the permanent database, as well as the volatile, but if this is fixed under 5.3, maybe I shouldn't worry too much!

Robert.

[Willem Grooters]

Robert,

It seems to be even more weird.
There is a logical that points to the database:
TCPIP$CONFIGURATION" = "SYS$COMMON:[SYSEXE]TCPIP$CONFIGURATION.DAT;1

**** MIND THE VERSION NUMBER ****

Now check this file:

dir SYS$COMMON:[SYSEXE]TCPIP$CONFIGURATION.DAT

(without version....)

You _should_ have version ;1 there - and just that one. I couldn't get to the system involved but since SET CONFIG ENABLE NOSERVICE did the trick I think there is just one such file in my case. Still, you could be helped with this information.

[Robert Atkinson]

Only one file there, version ;1, but good try!

I think the .DAT entry is basically just screwed up and needs deleting/reinserting.

It would just be nice if I could what the permanent database contains.

Rob.

[Willem Grooters]

Since it's just a testmachine, can you mess with it? Unhappily enough I can't do it no more. I promoted my Alpha to production and I don't have a spare one (yet) :-(

** login directly (on console)
** Stop TCPIP
** dump ALL info
** RENAME the file
** @SYS$MANGER:TCPIP$CONFIG
** Configure system again
** Check this new file (supposing it's created ;-)) with the old one.

I know, you shouldn't mess with it but you may get a good file (if it screws up your system you can alway get back since the old file still exists...)

Curently, I have a project with higher priority but it's worthwhile to dive into this file....