- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: copy/ftp not responding
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 05:17 PM
тАО08-19-2010 05:17 PM
The application is restarted every morning. One of the servers is classed as the тАЬmasterтАЭ server and the other 3 are real time backups.
Typically the master would start up at approx 6:30am with the other servers following. The location of the servers is split between a master site (where the master and another server live) and a recovery site where the other 2 servers are situated.
So, if the master dies, its partner should take over immediately. If the master site dies the servers at the recovery site should be able to take over immediately.
There are a couple of mechanisms for transferring data between servers: messages coming from external sources go to the master and are then distributed to the other servers via the Ethernet. But my concern is user data which is passed via the тАЬcopy/ftpтАЭ command.
FTP just works! Or that is the way the system is designed. At several points of the day тАЬcopy/ftpтАЭ sends information from one server (not necessarily the master) to all other servers.
One day the customer had huge network problems. The link between master and recovery site was down for several hours. The link was restored eventually and the system continued with the disaster recovery capability enabled and FTP working.
But, at end of day I was alerted to the fact that the system тАЬlocked upтАЭ: the operators tried to initiate the end of day activity and their interface did not respond тАУ the screen hung.
After a bit of digging around I realised that an FTP job was sitting in the batch queue. The operators initiate end of day activity on the master server. Before this server can begin its own processing it uses FTP to alert all other servers to begin their activity.
I tried to FTP from DCL on the master to another server and the job hung also тАУ I didnтАЩt get an error returned it simply sat there. I canтАЩt remember how long I waited but I would say 5-10 minutes before I used CRTL-C to kill this action.
This is the first and only time I have ever seen this problem. I am convinced that the customer had started to investigate their earlier problem and the knock on of that affected me. The silence on their part begins to confirm this.
BUT, my experience with FTP is that it either works or it doesnтАЩt work. The command issued is:
COPY/FTP filename node username password::dest_file_name
This is part of a command file which is submitted to the SYS$BATCH
I would be grateful if anyone can advise:
тАв Why would FTP hang?
тАв I donтАЩt see a timeout qualifier on COPY/FTP. Is there a more prudent way to use FTP?
Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 05:54 PM
тАО08-19-2010 05:54 PM
Re: copy/ftp not responding
Sure it does. But, for a VMS-to-VMS COPY
operation, I'd tend to use DECnet rather than
FTP. (Or, in a cluster, plain-old COPY
to/from a served/shared disk.)
> [...] Open VMS8.2-1.
TCPIP SHOW VERSION
> [...] Why would FTP hang?
DNS problems? Network problems? Many things
are possible.
HELP COPY /FTP /VERBOSE
Hard to say what happens without some info on
what it's doing when it happens.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 06:08 PM
тАО08-19-2010 06:08 PM
Re: copy/ftp not responding
Your thoughts on why FTP doesn't work sort of correspond with mine. That is - it could be any one of a number of reasons.
My remit is to support the host system and let the network guys field network problems. I would though like to ensure the host is as informative as it can be. I will investigate the /VERBOSE switch.
I did check the TCPIP information:
$ tcpip show version
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.5
on an HP rx2600 (1.40GHz/1.5MB) running OpenVMS V8.2-1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 07:22 PM
тАО08-19-2010 07:22 PM
Re: copy/ftp not responding
I see ECO 3 for that one:
ftp://ftp.itrc.hp.com/openvms_patches/layered_products/i64/
Or, perhaps V5.6 ECO 5, if it's suitable.
(That's what's on my V8.3-1H1 system.)
No bets that either would matter, but a look
might pay off. The release notes seem to be
hidden in the kits, not available separately
from the FTP server. (Which, of course, is
itself set to disappear soon, so get those
patches while you can.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 07:46 PM
тАО08-19-2010 07:46 PM
Re: copy/ftp not responding
Check the time period of the "hang". No distrespect intended, but in my experience, when a user says "I would say 5-10 minutes", it's usually significantly less. A DNS timeout can be several minutes, especially if there are several name servers defined (timeout on each in turn). To prove the point, start the COPY and go to lunch. If it's still hanging when you get back, I'll believe it really is hung!
You need to check that both nodes can see ALL their name servers, and that they can successfully translate each other's node names in both directions (name->number and number->name).
> I don├в t see a timeout qualifier on
>COPY/FTP. Is there a more prudent way
>to use
There are several possible timeouts, but they're defined system wide in TCPIP. As a hack, (and assuming IMCP messages are allowed), you could check PING connectivity prior to starting the COPY (but if it's a DNS issue, you'll possibly suffer the same delay).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2010 10:02 PM
тАО08-19-2010 10:02 PM
SolutionI've seen similar problems on systems using COPY/FTP with MultiNet. Usually it was a problem on the FTP server but that didn't explain all occurrences.
In the end I wrote a program which would issue a $FORCEX on the COPY/FTP. You can pick up a copy of this from
ftp://ftp.vsm.com.au/kits/timeout.zip
Here's how I used it:
$ timeout := $ute:timeout.exe
$ timeout 00:02:00 /forcex
$ copy/ftp/log 'sourcefile' remote.node::'destfile'
$
If the COPY/FTP takes more than two minutes it will be forced to exit. Depending on the job, you could replace /FORCEX by /DELPRC or /KILLJOB. See TIMEOUT.PAS in the zipfile for details.
Regards,
Jeremy Begg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-20-2010 04:12 AM
тАО08-20-2010 04:12 AM
Re: copy/ftp not responding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-20-2010 05:22 AM
тАО08-20-2010 05:22 AM
Re: copy/ftp not responding
Try acc/fu/since=just before the copy/ftp to see if you have a weird
Do on the remote node repeated
$ sh sys/net
during the copy/ftp
and check to see the final status code
Check the file tcpip$ftp.log in the account of the remote node.
By the way, you should leave VMS 8.2-1, and go to 8.3 (or 8.3-1H1) with the latest patches, but this may be completely unrelated to your problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-20-2010 06:35 AM
тАО08-20-2010 06:35 AM
Re: copy/ftp not responding
Far from the first case here.
That stinking and festering and absurd and hideous pile of galactic-scale stupid known as ftp isn't the first suspect here. Your network hardware is. Then your IP. Then your routers. Your switches are absolutely suspect. VLANs and firewalls, too. As is your DNS. As are your network duplex settings.
Trust your network staff, but remember to verify what you're told.
Here's the most recent discussion of ftp as a "canary" for a lower-level issue:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1439155
And no, I'm not a fan of (gag) ftp.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-20-2010 07:13 AM
тАО08-20-2010 07:13 AM
Re: copy/ftp not responding
As has been noted there are a variety of possible causes. If the cause is not obvious, please consider using a LAN monitor such as WireShark to see what is actually happening on the network.
I have seen these sort of problems caused by DNS, switches, firewalls, routers, LOGIN.COM, SYLOGIN.COM, disk problems, and numerous other causes. In the end, the LAN trace is often a useful step (to rule in/out network issues). I would also check the logs on the remote system (both FTP and accounting) to see if there is any information there.
- Bob Gezelter, http://www.rlgsc.com