ftp issue

[tl123]

Hi, I support a system running OpenVMS V8.2-1. The system consists of 4 itanium servers. One server is classed as the "main", this processes all transactions and passes these transactions to the other 3 servers. The servers are split into 2 locations - a main site and a recovery site. 2 servers at each.Any of these servers can be the main - it is a case of who starts up first. They are all running the same software.

During the day a number of small files are passed via FTP from one server to all others. EG. When a user logs in to any server, the user profile is passed to all other servers.

At end of day all 4 servers transfer a number of files between each other using FTP. The "main" server is the most active sending and receiving more files.The size of the files can range between 1kb and 1mb.

Over the last 2 nights we have been experiencing problems at end of day. The main server locks up when sending its first file. The other servers send and receive their files correctly. The main server receives okay. After the problem occurred the first time we changed the main server to ensure there were no hardware issues. The same problem occurred on the new main server.

I don't have a sample of the actual transfer but the command looks like:

$ copy/ftp filename tcpip_node"username password"::destination file

As I write the system is ticking over and using FTP to transfer files. I can almost guarantee that in 12 hours time when it closes down the problem will reoccur.

When I receive the call tonight I am hoping to try a few tests. I guess a simple "copy/ftp" from the command line is a good idea. Are there any FTP/TCP logs I can look at?

Finally, I know these guys have been playing with their network recently (a 3rd party is receiving badly formed messages down a TCP port). Is is possible a network setting could hinder traffic?

Any ideas appreciated? Thanks

[Steven Schweda]

> Are there any FTP/TCP logs I can look at?

   Perhaps SYS$LOGIN:TCPIP$FTP_SERVER.LOG

      COPY /FTP /VERBOSE [...]

> Is is possible a network setting could hinder traffic?

   A network problem could cause networking problems.

[Volker Halle]

A problem with a hung FTP transfer would most likely occur on the 'remote' end of the transfer (FTP Server side instead of FTP client side). Except if it is a caused by a problem with DNS name resolution (could be local or remote).

If you've changed the main server, did you consider that the problem could be on the remote end of the FTP transfer ?

Look for the actual failing/hanging command and check - as Steven has suggested - the TCPIP$FTP_SERVER.LOG file in the account used on the FTP server side.

Volker.

[tl123]

thanks Steven and Volker. Regarding the log you have triggered some thoughts in the back of my mind which are worth investigating.

And to be quite honest I didn't think of asking the admin guys to check the ftp server. Plenty to investigate.

Cheers

[Mike Kier]

If the systems are all VMS, is there any particular reason not to run DECnet over IP and use regular COPY rather than COPY/FTP (and all of the other integrated DECnet capabilities and utilities)?

[Hoff]

And for completeness, get off of V8.2-1 and its associated products and versions, and get (more) current.

Definitely get to V8.3-1H1, or (only if you have support and particularly access to current patches) maybe V8.4.

[tl123]

Hi All, just to fill in the details. I was part of a team who maintained this product. Our company bailed out of support and development for the product. Another company took over the software maintenance with me as the support engineer. Which leaves the customer in a mess but they seem content.

Mike, originally DECNET was used to pass files between nodes. When the system was upgraded from Vax to Itanium the relevant people decided to replace this with FTP. This decision is causing plenty of problems as time goes by but is unlikely to be reversed due to lack of resources.

Hoff, OS maintenance is not part of our contract although this is not the first time an upgrade has been mooted. I am about to write a report for the customer and I will think about how to broach this topic.

Again, thanks for all the input. The points raised give mesome ideas on what to research before moving on. FYI the problem didn't reoccur over the weekend. Suggesting a network patch has been removed!

[Mike Kier]

OK, so long as you realize that DECnet-over-IP gives you both without having to hassle with the networks folks as the lower level protocols are only the TCP/IP stuff and they'll never see a DECnet packet in their monitors or have a MAC address change.

[Jeremy Begg]

I'll second the suggestion to use DECnet-Plus (aka DECnet over IP).

In the meantime ... you said, "The main server locks up when sending its first file."  Is the first file always sent to the same system?  Perhaps there's an issue on that system.  Or, if that system is at a remote site, perhaps there's a network issue between the sites.

A TCPDUMP (TCP/IP packet trace) might help you work out what's going on.

Regards,

Jeremy Begg

[tl123]

thanks for all the suggestions.The problem has not been seen for one week now. Which makes me suspect someone knows something they didn't reveal.

I have more ammunition if/when this problem reoccurs. I will also research the decnet angle and upgrading VMS.

Thanks again