On 2015-01-08 03:23, Paul_Koning at Dell.com wrote:
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
I haven't found any. :-(
On the other hand, I could have missed something.
The "old" way of possibly dealing with this would be to use the page structure mode in ftp, but that would appear to be seriously discouraged. And besides, it is still kindof a difficult fit here.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
paul
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Aha. Interesting output. That was sortof what I had a vague memory remembering it looking like. Now I need to decide if I want to do it similar.
Do people think file protection (for example) is useful to see? What about owner? I certainly have the information available, but I have not displayed it so far.
I would try to make it look as close to the *nix implementations, that way automated / GUI front-ends are more likely to work nicely with the server.
For example, I have a very nice GUI file transfer program called Transmit.app on OS X, but it REALLY gets confused when talking to VMS..
sampsa
On 2015-01-08 03:19, Sampsa Laine wrote:
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
IIRC unless the FTP server is working is "Passive Mode" port 21 is used just for control, and the server opens a random high-numbered port to which the client connects and the data is transferred over that - so that's where NAT'ing gets in the way.
Almost. In active mode, the ftp server initiates a second connection for data. This is by default on port 20 of the server, and by default to the same port as the control connection of the client. And the client is expected to listen for this specific connection.
However, NAT boxes normally knows this, and actually handles all needed for it to work.
I have no need for FTP on my boxes (I prefer Kermit) so haven't tried particularly hard to get around this problem.
:-)
Well, if your NAT box do something funny, then I'd just go for passive mode, which have a higher chance of working, since in that case, the client also opens the data connection.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 7, 2015, at 9:03 PM, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work )
Usually, but it depends on the protocol. Some protocols FTP is a notorious example carry addresses and/or port numbers inside the application protocol data.
Does this server support passive mode? A lot of NAT servers need passive mode for FTP to work, or work more reliably if you use passive mode. (I just like passive mode because it isn t quite so conceptually broken as the older mode of FTP.)
paul
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
IIRC unless the FTP server is working is "Passive Mode" port 21 is used just for control, and the server opens a random high-numbered port to which the client connects and the data is transferred over that - so that's where NAT'ing gets in the way.
I have no need for FTP on my boxes (I prefer Kermit) so haven't tried particularly hard to get around this problem.
sampsa
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
Aha. Interesting output. That was sortof what I had a vague memory remembering it looking like. Now I need to decide if I want to do it similar.
Do people think file protection (for example) is useful to see? What about owner? I certainly have the information available, but I have not displayed it so far.
Johnny
On 2015-01-08 02:50, Sampsa Laine wrote:
So I opened port 21 on my router but I don't think the OpenVMS 7.3 UCX FTP server likes being behind NAT'd routers.
But here's some sample output I took from a simple DIR command:
kermit at gorilla:~$ ftp gorvax
Connected to gorvax.
220 gorvax.inside.sampsa.com FTP Server (Version 5.1) Ready.
Name (gorvax:kermit): bqt
331 Username bqt requires a Password
Password:
230 User logged in.
Remote system type is VMS.
ftp> dir
200 PORT command successful.
150 Opening data connection for SYS$SYSDEVICE:[BQT]*.*;* (192.168.77.202,55552)
Directory SYS$SYSDEVICE:[BQT]
SMGTERMS.TXT;1 170/171 20-MAY-2002 16:12:23 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;3
0/9 8-JAN-2015 03:46:12 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;2
1/9 8-JAN-2015 03:44:10 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;1
1/9 8-JAN-2015 03:43:20 [BQT] (RWED,RWED,RE,)
TERMTABLE.TXT;1 1/9 20-MAY-2002 16:12:24 [BQT] (RWED,RWED,RE,)
VMSHELP.EXE;1 11/18 20-MAY-2002 16:04:05 [BQT] (RWED,RWED,RE,)
Total of 6 files, 184/225 blocks
226 LIST Directory transfer complete.
On 8 Jan 2015, at 02:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
So I opened port 21 on my router but I don't think the OpenVMS 7.3 UCX FTP server likes being behind NAT'd routers.
But here's some sample output I took from a simple DIR command:
kermit at gorilla:~$ ftp gorvax
Connected to gorvax.
220 gorvax.inside.sampsa.com FTP Server (Version 5.1) Ready.
Name (gorvax:kermit): bqt
331 Username bqt requires a Password
Password:
230 User logged in.
Remote system type is VMS.
ftp> dir
200 PORT command successful.
150 Opening data connection for SYS$SYSDEVICE:[BQT]*.*;* (192.168.77.202,55552)
Directory SYS$SYSDEVICE:[BQT]
SMGTERMS.TXT;1 170/171 20-MAY-2002 16:12:23 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;3
0/9 8-JAN-2015 03:46:12 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;2
1/9 8-JAN-2015 03:44:10 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;1
1/9 8-JAN-2015 03:43:20 [BQT] (RWED,RWED,RE,)
TERMTABLE.TXT;1 1/9 20-MAY-2002 16:12:24 [BQT] (RWED,RWED,RE,)
VMSHELP.EXE;1 11/18 20-MAY-2002 16:04:05 [BQT] (RWED,RWED,RE,)
Total of 6 files, 184/225 blocks
226 LIST Directory transfer complete.
On 8 Jan 2015, at 02:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
- Mark
