UCX 4.1 - RCP Problems

[Surya Rao]

Hi,

I have a VMS box in Asia and a Sun Solaris box in London linked to each other via a 128kbps dedicated bandwith

My question is on the vms box

VMS is running 7.1 with UCX 4.1 ECO-9

There are applications running on VMS and SUN boxes which transfer files between the 2 boxes using "RCP"

1. We occasionally used to encounter file transfer errors with mysterious errors like below
%RCP-E-CONHST, error connecting to remote host

But we _could_ connect to the host via telnet. Also upon immediate retry the file transfer would go through.

The file transfer problems normally surface with big files around 4mb...but occasionally with smaller files as well.

2. I contacted HP support who asked me to increase SMALL_BUFFERS from 200 to 1000. Did that and it solved the problem for a while.

But still get problems occasionally.

Then HP asked to upgrade to 4.2 - did not solve the problem at all

3. then HP support asked me to upgrade to 5.1 (on VMS 7.1 itself). Did that and then the problem got worse! ALso the SMALL_BUFFERS parameter had been rendered redundant and we could not fiddle around with that either.

In desperation we restored back a system image from a backup taken with the ucx 4.1 ECO 9 since with this version the situation was atleast tolerable

So we are now back to square one.

Now HP says, 5.1 was not supported on VMS 7.1 and so they are asking us to upgrade to atleast 7.2-1 and UCX 5.0a

I am a bit reluctant to do that since I did not see any patch release documents stating that this problem has EVER been fixed in 5.0a or 5.1 patches.

We then contacted the network engineer who manages the 128kbps link over whch we rcp the files. He looked at the router and link stats and said he could not see anything wrong!


So now what do I Do??>?

Any suggestions?

I have test systems to play around with and give you any output you may want


one more interesting thing is that there are 2 ways to rcp a file

run rcp on sun and pull the file from vms to sun

or

run rcp on vms and push the file from vms to sun

from my tests the second one is more likely to fail.

BUT with some other applications, on the sun which run rcp on the sun to PUSH files to the VMS, I've seen failures too

totally nonplussed and don't know what is the way to even start approaching to tackle this issue

surya
======

[Lokesh_2]

Hi Surya,

As you said the problem is with both VMS & SUN ( though with VMS more likely ), so I guess the problem might be with network ( though intermittent ) . Anyway, can you use ftp instead of RCP and check whether it also fails or not ?? If with FTP also you are facing the problem from both SUN & VMS , then we can suspect network problem...

Thanks & regards,
Lokesh

[labadie_1]

Depending on what you have on the Sun, but maybe you can use Decnet ( dnincp or something like that on Sun).

For you problem, I think there is a Tcp parameter you have to adjust to avoid it (sorry, I have forgottent which one, I will try to find)

[labadie_1]

and anyway,you should avoid rcp, which does not have a strict rfc (or does not have a rfc at all), and is not the best tool.

you should have a look at FTSO, which is the same as FTSV, but using the IP transport. There is checkpointing, so if you reboot the Vms or the Sun when you have copied 90% of a file, it will just copy teh remainig 10 %.

[Surya Rao]

Hi Lokesh,

I tried with FTP as well as RCP for a large number of trials. FTP did not fail. But I can't use FTP since with FTP I need to provide a password and due to security reasons, I can't do that. With RCP I can use proxies.

Also we have 2 other VMS 7.1 TCPIP 5.0a systems which also have file transfer operations with the same SUN box and they don't have any problems whatsover. These 2 other VMX boxes are located closer to the SUN box and have a bandwidth of 256kbps.

But network engineers say they don't see any problems related to bandwidth. They say if bandwidth was the problem, then the file transfer won't fail, it will just take longer.

surya
=====

[Surya Rao]

Hi labadie,

Please take a look at my reply to Lokesh on why we use RCP

Also how do I use FTSO and FTCV? I am not able to invoke these commands on the DCL. I am not a VMS expert but not a real novice either - just to give you an idea on my level of VMS knowledge

Can you tell me which TCP parameter to tune?

surya
======

[Wim Van den Wyngaert]

Hi,

We also had some ftp's losing their connection to a remote site. After a long search we found that the firewall decided to reset the connection (because of obscure bugs).

It was also present in all UCX and TCP versions.

It was solved by using high portnumbers on vms.

Set ipport_userreserved_min to e.g. 51000 and ipport_userreserved to 59999 and test again. I don't remember how to do it in UCX.

[labadie_1]

Ftso is a commercial product, see the Spd at

http://h18000.www1.hp.com/info/SPD/#SPD_F

look for

54.34 File Transfer Spooler for Open systems, Version 1.6 26 Feb 2001

Sorry I have to search in my notes to find the Tcp parameter.

[Surya Rao]

Thanks for the info on FTSO. but since we may have to change a number of applications to use FTSO, that could be 1 problem.

Tell me please, is there a way to use FTP and not hardcode the password?

surya
======

[Wim Van den Wyngaert]

Not to my knowledge.

[Stanley F Quayle]

> Tell me please, is there a way to use FTP and not hardcode the password?

I've done this before:

- In AUTHORIZE, create a rights identifier (FTP_PASSWORD, for example)
- Grant that rights identifier to the username that will do the FTP
- Put the username and password in a file (FTP_PASSWORD.DAT, for example)
- Establish an ACL so that only processes with the FTP_PASSWORD rights identifier can access the file
- When it's time to transfer a file, open FTP_PASSWORD.DAT and fetch the username and password

Ugly, but effective...

[Willem Grooters]

On FTP preventing a password:
I remember I had a similar problem between two TRU64 machines, but am uncertain how it was solved exactly. Anyway, there involved a hidden file on either side (sender of receiver, that I canot remember) and by that it was possible to start a FTP session without specifying a password.

The fact that your other machiens seem to have no trouble, makes me think of yet another issue: Some VMS machines do have trouble where NICs are set to "auto-negotiate". You'd better avoid that. We did have severe problems using FTP (VERY slow) where TELNET was no trouble at all, and it was solved by explicilty setting NIC and switch-port to 100Mb, secondly try half-duplex. It _may_ work with RPS as well.

[Surya Rao]

Hi all,

Thanks for the replies. Keep 'em coming.

Just to make a slight correction to one of my earlier posts (not the very first post)

QUOTE
Also we have 2 other VMS 7.1 TCPIP 5.0a systems which also have file transfer operations with the same SUN box and they don't have any problems whatsover. These 2 other VMX boxes are located closer to the SUN box and have a bandwidth of 256kbps.
END QUOTE

The correction is that these 2 other boxes are VMS 7.2-1 and TCPIP 5.0a. So the 2 variables between the ones that work and the one that has problems are as follows

1. lower bandwidth
2. physically located much farther than the other 2 VMS boxes (and the SUN box) that don't have a problem
3. earlier versions of vms and ucx on the box that has problems

I have noted the suggestion of setting the NIC to 100M/full and not to use AUTODETECT and will test this out to see if this helps. I am now working on producing a reproducible test case - one that can help us figure out which "variable" actually is the culprit.

planning to upgrade to vms 7.2-1 (from 7.1) and to TCPIP 5.0a (from ucx 4.1 eco-9) and test that first. if it works, we wont touch the bandwidth. if that doesn't work then we will try increasing the bandwidth - but somehow I've got a gut feeling that bandwidth congestion will not cause the type of ERRORS. it may only have an impact on performance.

Does anyone agree with my suggested approach or does the whole exercise of VMS upgrade etc seem a waste of time and are there any other parameter tuning that can be attempted before we embark on the VMS upgrade exercise?

tia

surya
=====

[Wim Van den Wyngaert]

Is there any firewall in place ? Which one (version) ? Some firewalls impersonate one site and add packages that were not sent. I had a firewall that added RST (ask for a reset of the connection). The RST was added because the firewall was convinced that there was a security breach.

The RST can be checked with TCPTRACE.

[Surya Rao]

Hi,

There is no firewall anywhere between these boxes

rgds
surya
=====

[Wim Van den Wyngaert]

Reread the story. The problem only occurs when making the connection ?

On VMS :
$ ucx sho comm
and check if peak column reaches maximum
if number of routes peaks are high (e.g. 100), I could be small buffers that must be increased (I had the problem once).
$ ucx sho servi rsh/fu
and check if limit was reached by peak value.
Are quotas low ? Did the line had to be opened and did it take longer than the connection timeout ?

On the Sun :
$ netstat -a | wc
If high, the limit could be reached (which is at 10.000 connection as far as I know, it could be dangling connections).
Check the same things as on VMS.

Try to capture a tcptrace (tcptrace/fu/prot=tcp/pack=1000000). The reason may be readable.

[Willem Grooters]

1. lower bandwidth
2. physically located much farther than the other 2 VMS boxes (and the SUN box) that don't have a problem

Combined this _could_ lead to time-out problems. Normally, distance should NOT be a problem, nor would low bandswith alone. BOTH may introduce timeouts, causing the connection to be dropped.
Also, line quality is a matter of concern. A 'bad' line requires more retransmission requests - causing more traffic - causing more collisions - causing more delay - causing retransmissions and so on. At a certian point, the connection may be dropped due to "too much errros".
It may be worthwhile to check the counters. Which ones, check http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=276091

[Wim Van den Wyngaert]

Please post a TCPIP trace. This shows if any retransmissions are done.

[Stanley F Quayle]

How about assigning some points to the responses?

Pointer to help on points:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Thanks in advance.

[Ian Miller.]

FTSO is now free
http://h71000.www7.hp.com/freeware/freeware70/ftso/http://h71000.www7.hp.com/freeware/freeware70/ftso/