Problem using RCPY or COPY/FTP or COPY/RCP

[Thomas Simpson]

Greetings,

I'm unable to copy a file from one VMS host to another VMS host using TCPIP with proxy access. It works fine if I supply a username and password in the copy command. I have added the TCPIP proxy entry and defined the remote host in the local HOSTS database (on the remote node, ORADEV). Is there anything else that needs to be setup?

Both systems are running VMS 7.3-2 with all the current patches and TCPIP V5.4 ECO 5.

Our network switches will not be supporting DECnet for much longer and we need to replace the DECnet copies that we currently do with the eqivalent IP-based commands.

I really want to use proxy access so that we do not have to code the username and password into all the command procedures...

Here is what the proxy entry looks like:

ORADEV> tcpip show proxy

VMS User_name Type User_ID Group_ID Host_name

SYSTEM CD D_TEST 172.29.23.29

Here is the IP info for the host receiving the file:
ORADEV> tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 5
on a AlphaServer 4100 5/466 4MB running OpenVMS V7.3-2


Here is the error from the local host:

MILC1(D_TEST)$ copy/rcp/user=system fubar.txt oradev:: ! (this worked)

MILC1(D_TEST)$ copy/rcp/user=d_test fubar.txt oradev::
TCPIP$RSH - Permission denied - VMS user:D_TEST

%RCP-E-CONHST, error connecting to remote host oradev.mayo.edu

Note that when user = system, the command worked. I'd like to know why, since there is no proxy entry for system.

On the remote system, I see this message:
%%%%%%%%%%% OPCOM 1-NOV-2006 10:12:26.22 %%%%%%%%%%%
Message from user INTERnet on ORADEV
INTERnet ACP RSH Reject Request from Host: 172.29.23.29 Port: 1023

The user D_TEST does not exist on the remote system, that's why I using the SYSTEM account (for testing).

I thought I could use COPY/FTP with a proxy, but apparently if no user name is specified, the ANONYMOUS user name is used and there is no way to over-ride this unless you specify both the user name and password.

This should not be that difficult of a task...I must have missed something!

Regards,
Tom

[EdgarZamora_1]

TCPIP proxy does not work for ftp (as you found out).

You can use COPY/RCP command. The reason your copy command didn't work is because you misunderstood the /USER= switch. That specifies the remote user you want to use. Just take out the /USER switch from your command line. And do the command while logged in to D_TEST and it should work.

[Thomas Simpson]

I've got it working with a little help from HP. The problem is my understanding of how the TCPIP proxy works...

What I was misunderstanding was that you need to execute the r-command from an account on the local system that has the same account on the remote system along with the a valid proxy or use the /user switch to specify a valid remote user account (with a valid proxy).

Here are the remote proxies:
ORADEV> tcpip show proxy

VMS User_name Type User_ID Group_ID Host_name

SYSTEM CD SYSTEM milc1.mayo.edu
SYSTEM CD D_TEST milc1.mayo.edu
TCPIP$FTP CD D_TEST milc1.mayo.edu

Here are the r-commands and results using the D_TEST account:
MILC1(D_TEST)$ rsh oradev show time
%RSH-E-FAILED, TCPIP$RSH - Permission denied - VMS user:D_TEST
(from remote)
MILC1(D_TEST)$ rsh/user=d_test oradev dir show time
%RSH-E-FAILED, TCPIP$RSH - Permission denied - VMS user:D_TEST
(from remote)
MILC1(D_TEST)$ rsh/user=system oradev show time
1-NOV-2006 20:32:50
MILC1(D_TEST)$ rsh/user=tcpip$ftp oradev show time
1-NOV-2006 20:33:11

So as you can see, I'm logged in as D_TEST, have a proxy for D_TEST on ORADEV, but the r-command will never work unless I can specify a valid remote VMS user name with the /USER switch.

Maybe someone else can explain it a little better than I can... It's similar to DECnet proxies but definitely not the same, which is what confused me.

[Steven Schweda]

I think that they're more similar than not.
The trick is keeping track of which user
name is used where.

Your local user name is your local user name.

You may specify the remote user name, but the
default is the same as your local user name
(except where anonymous FTP gets used).

With DECnet, you specify the remote user name
in the file spec: 'rem_node"rem_user"::[...]'
(with the password obviated by having the
proper DECnet proxy).

With IP, you specify the remote user name
using a "/USER = rem_user" qualifier.

On the remote system, there must be a proxy
which allows your local user to act on the
remote system as the specified remote user
(which might be defaulting to be the same as
the local user). So, the proxy involves the
original local user and the user-specified
remote user. (Of course, _on_ the remote
system, the "local user" appears remote,
while the "remote user" appears local.)

Anyway, it was clear to me before I started
to explain it.

[David B Sneddon]

Tom,


Our network switches will not be supporting DECnet for much longer and we need to replace the DECnet copies that we currently do with the eqivalent IP-based commands.


We had a similar situation here many years ago...
routers/switches that no longer supported DECnet.
Use DECnet over IP and everything runs as usual.
You will not be able to replace all your DECnet
functionality with IP -- it just don't work that
way.

Use DECnet over IP, it is not as difficult as
some make out.

Dave