[Info-vax] FTP sesion against a vms server fails

[Richard B. Gilbert]

VAXman- @SendSpamHere.ORG wrote:
> In article <65142276-f7fa-4d10-9305-e6ab9abeb3f2 at v20g2000yqm.googlegroups.com>, John Wallace <johnwallace4 at yahoo.co.uk> writes:
>> On Aug 6, 5:16=A0am, moro... at world.std.spaamtrap.com (Michael Moroney)
>> wrote:
>>> I have also noticed some FTP funniness with VMS (V8.3 Alpha). =A0On my LA=
>> N
>>> (all systems 100BT), FTP from one PC running XP works, but is very slow. =
>> =A0
>>> From another PC running XP, it runs at normal speed. =A0In each case the =
>> FTP
>>> client is the basic simple Windows client (DOS window->ftp). =A0Since I
>>> rarely FTP from the "slow" system, I haven't investigated further.
>> Based on experience (rather than evidence), stuff like that is often
>> down to physical layer issues - autonegotiate mismatch, duplex
>> mismatch, speed mismatch, etc. Either genuine hardware issues or maybe
>> just driver misbehaviour. Either way, a $10 network card might help
>> quickly identify where the problem lies.
>>
>> Back to the OP though.
>>
>> Wireshark (formerly Ethereal) is a wonderful tool for knowing what's
>> been happening in IP packet terms on a PC. If I recall correctly some
>> VMS IP stacks have their own packet-trace facilities too.
>>
>> A log of the packet exchange between PC and VMS system would allow
>> folks to be making evidence-based suggestions rather than the educated
>> guesses we're getting so far.
>>
>> Also, a less ambiguous problem description might be helpful. I *think*
>> the ftp failure problem summary is:
>> pc1 -> vms1 : ftp fails
>> pc1 -> vms2 : ftp fails (identically?)
>> vms1 -> vms2 : ftp OK
>>
>> To date, the definition of "fails" unfortunately does not include the
>> exact commands issued and the exact results they generated, or any VMS
>> OPCOM output which might potentially be relevant.
>>
>> Best suggestion I've seen so far is VAXman's request to use telnet to
>> manually drive ftp and note the exact results, though later on, the
>> same logic VAXman uses to deduce that the problem must be in MS
>> territory ("VMS ftp always works for me so the problem must be
>> Windows") is the same logic most folks would normally use to point the
>> finger at VMS in this picture ("Windows ftp always works for me so the
>> problem must be VMS").
> 
> Take a glance back at the introductory thread and I believe that there
> was a statement that other FTPs to the VMS system work.  Yup...
> 
> 	When I open an ftp sesion from a Windows PC to a vms machine
> 	it fails. It is stack endlessly.  Trying to work against another
> 	VMS machine brings the same result. Other protcols like telnet ,
> 	ping work fine. Trying to open a sesion from another VMS machine
> 	works fine. 
> 
> So, if the server responds for other FT clients, I would decude that the
> problem lies with WEENDOZE.
> 
> 

"decude"????  Maybe you should use a spelling checker!!

Did you mean "conclude"???
Or "decide"???

Or are you throwing in a little Klingon?