Interesting result using Remote Delete and Copy.

[The Brit]

I have a process which is used to refresh my development node with data from Production. Basically, it runs on the production node, deletes a file on the remote node, and then copies in the new version. This has been working fine until a recent run producted the following (paraphrased)

$ Delete/NoConfirm/Log :::*.*;*
%DELETE-I-FILDEL, ::: deleted (19124523 blocks)
$ Copy/Log :::
%COPY-E-OPENOUT, error opening ::: as output
-RMS-F-FUL, device full (insufficient space for allocation)
%COPY-W-NOTCOPIED, not copied

Note the file deleted was 19M Blocks, the Prod_File replacement was 13M Blocks, i.e. significantly smaller.

Q. Why did I get the "device full" message?

A "show dev" after the failure indicated that there were only ~5M blocks available, even though the "delete" command should have released 19M blocks?

The "Free Blocks" issue is fixed, and the disk is now showing ~24M blocks free, however I am still interested in what could cause this to happen

thanks Dave.

[Wim Van den Wyngaert]

Try it :
create a.lis
open/read/share x a.lis
del a.lis.*
(the file should be deleted)
close x
(at this moment the diskspace gets freed)

So, the file was still open and thus the space was not yet given back.

Wim

[The Brit]

Thanks,
It looks like this might have been what happened.

Dave

[Hoff]

This sequence shouldn't generate this device full error, of course. I'd have to guess the file was contiguous, or that the lock value block got messed up or the delete got stalled. The block counts reported certainly imply the latter.

There's been a long game of whack-a-mole with the freeblock count in the volume lock, and several leaks have been fixed over the years. Are you current on ECOs on whatever version of OpenVMS and of DECnet is operating here?

It's also possible that FAL is operating and overlapping the operations. That you got the done back from FAL before it was really done. Wildcard copies have had the tradition of starting more than one parallel operation. (Guess: DELETE finished after the COPY started; the DELETE completion arrived back too quickly.)

Did somebody enable erase on delete? That switch can throw off the command timing.

Poke around in the NET*SERVER.LOG files, if you still have them, and see if there's any detail there. (See if you have an overlap in logs here based on time, for instance.)

About the best I can see here is loading the ECOs, and to instrument the code and the remote NET*SERVER so that you have more evidence of this sequence should it crop up again. This to have more details for the HP support folks.

The skewed block counts imply you've something messing up or messed up in the file system.

[Wim Van den Wyngaert]

Here is a full example.

Wim

[The Brit]

Hoff,
I carried out the same test as Wim, and got the same result, vis. the delete appears to be successful, "Dir" indicates that the file is gone, and no error is generated, however a "show device" indicates that the diskspace does not reappear until the file is closed.

In my case, I have reason to believe that the file might have been open for read (although it should not have been)

Supporting this conclusion is the fact that the diskspace returned to normal at some point after the copy attempt, without any intervention by myself, or any other of my developers.

Dave.