Advanced Server - Large File Transfer Fails

[Ted Ripp]

When I try to copy a large file, 800 MB, to the Advanced Server the copy runs for a minute or so and then fails with the diagnostic: "The specified network name is no longer available." I am doing this from cmd.exe in Windows 2000.

On the VMS side the file is created and continues to grow (dir/size=all) even after the error message on the PC, up to around 600 MB. This takes a few minutes. After a while the file gets closed on the VMS side. It looks to me like AS is allocating space for the file which takes too long causing the PC to time out on the connection. Can I fix this somehow?

Advanced Server 7.3A ECO-3
VMS 7.3-1
TCP/IP 5.3
ODS-5 disk holds the directory share
cluster size 64 extend 256.
The disk is software RAID-0 but I have the same problem on a single ODS-2 disk.

Also, do any of you have an idea of when the 4 GB limit will be lifted on the Advanced Server?

[Volker Halle · Accepted solution]

Ted,

is the disk set up for 'file high-water marking' (check with SHOW DEV/FULL and look in Volume Status:) ? If so, try $ SET VOL/NOHIGH disk to disable high-water marking. This should speed up filespace allocation

Volker.

[Antoniov.]

Hi Ted,
I remember another thread like yours; if you have server based licence might be during long time copy licence expires.

Antonio Vigliotti

[Brad McCusker]

>Also, do any of you have an idea of when
>the 4 GB limit will be lifted on the
>Advanced Server?

This is not an easy task - Advanced Server uses 32 bit file pointers and changing them to 64 bit is not a trivial task. I don't see it on the roadmaps anywhere. I also have not heard of many requests for this, either.

Brad McCusker

[Brad McCusker]

Oh, regarding the primary point of the thread - High Water Marking is a good idea to check.

If that doesn't help, then, the fact that you are using the CMD prompt might be significant. Do you get a failure with drag and drop?

I've seen discussions around the TCP parameter, TCPNODELAY (UCX SET PROTOCOL TCP/NODELAY), but haven't heard those rumblings lately - so I don't recall the specifics of when this comes into play. If its easy for you to test, you might want to try it.

Regards,

Brad

[Paul Nunez]

Hi,

As Halle noted, it's likely high-water marking on the volume which is slowing the file allocation effort, but disk fragmentation could also be contributing...

Also, I think you have to remount the volume after disabling high-water marking.?.

Can anyone confirm?

Paul

[Wim Van den Wyngaert]

No remount needed.

Wim

[Wim Van den Wyngaert]

Another possibility is that the volume is setup with "erase_on_delete" AND that the file has previous versions AND there is a version limit that causes a purge of a previous version.

set volume/noerase !

Wim

[Ted Ripp]

Volker,

Vielen Dank. Setting /nohigh solved my problem. Thank you for your quick and accurate response.

I had considered setting /nohigh but when I used help init/high on my 7.3-1 system the help message began with:

"Affects Files-11 On-Disk Structure Level 2 disks only."

It seems this is not the case.

TR

[Jan van den Ende]

Ted,


"Affects Files-11 On-Disk Structure Level 2 disks only."


Well, on OpenVMS 7.3-2 the Help text is:

"Applies to Files-11 On-Disk Structure Level 2 (ODS-2) and Level 5 (ODS-5) disks only."

... but on 7.3-1 I indeed get your text.

So, documentation was a bit slow to catch up with new feature, but it IS updated in 7.3-2


Jan