Urgent help needed - to restart multinet ftp process without rebooting VMS Server?

[gunners]

Hi we have a very old version of multinet on a very old (V6.2) Version of VMS - running on a Charon Virtual setup.

Every so often ftp hangs and the only way to clear it is reboot the four Vax clusters - which takes about 1hour 30 mins by the time we get everything up and running again.

Is there a way in multinet (Im not a network person but Im presuming ftp is running via multinet as this is what we use for everything else network related) to restart ftp on the servers ? - ie some command ? (I know there is in unix for tcpip.

SO the basic question is - is there some multinet command I can issue just to kill and restart the ftp server process on VAX ?

Many thanks

[Hoff]

While you might get lucky, consider either skimming the Process manuals for your version of Multinet, or asking the Process Software folks directly.   Multinet is not an HP product, after all — best to go to the source when asking a question.

Based on a quick Bing web search, the command to (try to) restart ftp is probably something underneath:

$ MULTINET CONFIGURE /SERVER
SELECT FTP

Based on this Multinet document, it appears that the necessary command is:

RESTART

No idea if that RESTART will work here, as there are no local "target practice" Multinet servers to test that with.  Fire up a spare emulation and run an experiment or two, or experiment with a non-critical host in the main cluster.

The above information was based Bing web searches,  starting with the obvious /process multinet restart ftp/ query, and working through and refining the search commands from there.  (I don't have the Multinet commands memorized, and have to look them up.)

It's not at all clear what's wrong with ftp or with Multinet here nor whether an ftp server restart might or might not help, nor whether there might be some VMS or emulator or underlying host software issue triggering the (unspecified) ftp problem here — ftp is a perverse protocol, and commonly run afoul of firewalls, and twenty-year-old-software has bugs.

Depending on the Multinet version, this Multinet ftp bug might be relevant to the question.  Chatting directly with Process might answer that, and there may well be other ftp bugs in other Multinet versions.

90 minutes to restart the cluster?   That's unusually long, even for a VAX restart.  I'd look at why that's the case.

I'd also suggest acquiring access to a formal escalation channel, as well.   A user forum is a just not appropriate channel for an "urgent" question on a production server.

ftp is completely and utterly insecure, and splatters the usernames and password credentials in cleartext for anyone with a privileged network position to monitor.  The credentials involved are wholly exposed.

[gunners]

Hoff,

Thanks as always for your invaluable knowledge. Yes these systems are over 20 yrs old (I think they may finally be moving to a modern platform) - re the 90 mins (that also includes SYBASE and many other jobs that Apps teams have to startup which take a long time (Vaxes themselves come back quickly enough)

I will keep note of your info and perhaps try on a test box if they will allow - its a strange enough issues - IT happened at exactly the same time (same day) last month.

ftp locks out and no mail gets sent either - IM thinking there is an internal tool that the company use to scan ALL servers for ftp , smtp etc etc - is causing this to lock or flood and the only way each time is a complete restart - although I will have a look at that multinet option next time as a starting point.

[Kelly Stewart_1]

Using our VAXStation running OpenVMS 7.3 and Multinet V5.3, I've confirmed that the Restart command under Multinet Configure/Server restarts the process MULTINET_SERVER. This is the "master server" that listens for incoming connections to services, including FTP.  It does not affect existing FTP connnections. So if the problem is that you can't open new FTP sessions this is probably what you're looking for.

[gunners]

Kelly - I really appreciate your help and going to the trouble of testing out this command. Thanks very much indeed for the assistance. Brilliant to know for next time (may save me so much hassle and time)