complete newbie question

[Robert Gezelter]

Dan,

I recommend caution here.

The last posting would seem to imply that this is not a true FTP connection. This would appear to be a special configuration using KERMIT running over a telnet connection.

Depending upon the versions involved, KERMIT may be able to be far more friendly, or alternatively, a true FTP connection may be feasible (since there is clearly a TCP/IP stack on the system).

My usual cautionary recommendations when making changes to production systems, particularly when there is limited expertise in-house, apply. It is far cheaper to do things correctly than it is to make innocent mistake and cause problems.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> Our current FTP parameters are:
> Connect using: Telenet
> Terminal Type: VT140, VT320, VT220
> Transfer Type: KERMIT

> The last posting would seem to imply that
> this is not a true FTP connection.

Your "FTP" appears to be a generic term for
some kind of file transfer scheme (program,
whatever), not "FTP" as normally construed
(File Transfer Protocol).

If the (intermediate) goal is to move some
files from a Windows system to a VMS system,
then several possibilities have been
suggested. Kermit would probably not be my
first choice, but at least it's using Telnet,
not an actual (slow) serial line.

I don't do much on Windows, but once, upon a
time long ago, I did use a GUI FTP client
program named SmartFTP, which seemed to be
able to handle a VMS TCPIP FTP server. (I
haven't tried it lately, so no bets).

You could try using the command-line FTP
client (in a DOS window, or whatever they
call it now), to see if you even have an FTP
server configured on the VMS system.

I gather that Microsoft Internet Explorer can
work as drag+drop FTP client, but a VMS TCPIP
FTP server tends to leave MSIE hopelessly
confused, so that's probably not a solution
unless you really have some other IP package
installed on your VMS system. (What does
"TCPIP SHOW VERSION" say?) There's also a
free FTP server (and client), HGFTP, which
can replace the TCPIP FTP server, and which
MSIE might like better.

Many things are possible. How much does your
VMS system manager know about its IP
software? How much fooling around on the VMS
system does anyone want to do? Configuring
its existing FTP server should be easy
enough. Other things (Pathworks/Advanced
Server/Samba, NFS, ...) would probably
require more work on one end or the other.
VMS V7.1 is old enough that some potential
options are probably excluded.

[Brad McCusker]

VMS 7.1? I'd pop PATHWORKS V6 on that in a heartbeat. Then it's a simple set up of a file share, a user or two, and drag and drop to your hearts content.

Only problem is buying a license - but you might already have a couple CA licenses depending on the packages purchased (remember the old NAS packages)

Sure PATHWORKS can get real complicated, real fast (I've got the scars to prove it), but, I suspect in this case you don't need many users, you don't need many shares, basic Win-NT security should be sufficent, no trusts or other domain issues, not a cluster, no license manager... It should be a pretty simple standalone server set up.

Brad McCusker
Software Concepts International
www.sciinc.com

[Willem Grooters]

or thing about Samba 2.2.8 - old version but ported to OpenVMS and (according to people that used it) usable. Since you have just a few users, it might be feasable to use that (Found it on http://mvb.saic.com/freeware/vmslt04b/samba/ with more recent versions - but 2.2.8 is known to work pretty well)

[Robert Gezelter]

Gentlemen,

With all due respect, I disagree with the proposed solution of installing Pathworks or Samba.

As simple as many of us would find that enhancement, this appears to be a site with limited focus on the OpenVMS system. It is also a system that is, quite literally, a production system.

Since the system is ALREADY appears to be running KERMIT, and from the date, quite possibly an older version of C-KERMIT, it may already have what it needs. Certainly, a review of how to fix the difficulties encountered is certainly within the batch transfer capabilities of C-KERMIT.

Fixing this omission is far simpler than installing and configuring any additional software. This is particularly so since the problem may entirely lie on the desktop side. We simply do not have enough information (and I am always cautious about prescribing "over the phone").

- Bob Gezelter, http://www.rlgsc.com

[Kumar_Sanjay]

Daniel,

Well, I always do file transfer by drag and drop in my environment.
Normally I transfer lot of application txt file or sometime VMS Patch also.

I use SSH TECTIA Client to connect to VMS server. Under SSH TECTIA you do have Option to transfer file window. Yes, you can drag and drop text files from our microsoft pc's to the VMS servers.

This is Secure communication, you server must be configured for SSH communication.


Thanks.
Sanjay Kumar.

[Brad McCusker]

Bob,

You aren't wrong, of course.

I infered from the OP's "very time consuming" statement that he was referring to the cumbersome-ness of using something like C-Kermit. We use C-Kermit all the time with some of our customers but it is still a 4 or 5 step process. With a file server you can configure your clients to map the drive on boot and your client is essentially "ready to go" all the time. A lot less time consuming than C-Kermit or similar telnet/SSH clients.

PATHWORKS can be a bear - no doubt about it. But in this case, I think it's a simple solution. (Samba probably is too - I just never really used the 2.8 version)

Brad McCusker
Software Concepts International
www.sciinc.com