In article <[log in to unmask]>, [log in to unmask] (Aaron Porter) writes: > Miami Computing & Information Services (MCIS) News ([log in to unmask] ) wrote: > > : MCIS Technical Support reports that users of the centrally managed, > : multi-user Digital OpenVMS cluster in Oxford, MiaVX1, may experience > : difficulties attempting to ftp to Microsoft's anonymous ftp server, > : ftp.microsoft.com. These difficulties involve the MultiNet TCP/IP > : software MiaVX1 and many other Digital OpenVMS systems run. As a work > : around, MCIS Technical Support suggests using the following command at > : the $ command prompt when ftp'ing to Microsoft: > > : FTP/NoVMS ftp.microsoft.com > > Why only microsoft.com? What seems to cause the problems? The problem is with the FTP server being used by Microsoft. It appears that they're using Version 3.51 of the Windows NT FTP Server. I assume that any other sites running this same FTP server will have similar problems. This is the only site that I've seen reported, though. There was a significant discussion about it in one of the Multinet newsgroups. When an FTP connection is established, the 2 sides can do some negotiation to establish the best connection. One of the things our TCP/IP package does is to try see if the other system is another VMS system and if so, it sets some parameters to make transferring files a little easier. Microsoft's FTP server should be ignoring this negotiation (because it's not a VMS system) or responding with a message saying that it's not a VMS system. Instead, it seems to hang the connection. I haven't heard any word on whether Microsoft has acknowledged this problem or not. The /NoVMS qualifier on the FTP command instructs our FTP program to stop doing this VMS specific negotiation. -- Kent Covert, Software Coordinator Miami Computing and Information Services Miami University, Oxford, OH [log in to unmask]