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

[VAXman- at SendSpamHere.ORG]

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.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"