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

[Richard B. Gilbert]

VAXman- @SendSpamHere.ORG wrote:
> In article <6r6dnWu9I9LNdOfXnZ2dnUVZ_tednZ2d at giganews.com>, "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>> 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"???
> 
> Deduce.  If we're going to pick fun at handicaps like my dyslexia,
> I can find other forums in which to bide my time.
> 

Help stamp out dylsexia!

And a spelling checker really does help!  For VMS there used to be the 
Vassar spelling checker; just don't rely on the spellings that students 
added to the dictionary!!  I've lost all respect for Vassar! ;-)