e i g h t - c u b e d . c o m 

Rename weirdness

Consider the following directory structure:

$ dir my_disk:[top.branch...]

Directory MY_DISK:[top]

branch.DIR;1

Total of 1 file.

Directory MY_DISK:[top.branch]

archive.DIR;1       report1.rep;1       report2.rep;1

Total of 3 files.

Directory MY_DISK:[top.branch.archive]

20140611.DIR;1      20140612.DIR;1

Total of 2 files.

Grand total of 3 directories, 6 files.

During the day, a large number of reports are created in MY_DISK:[TOP.BRANCH].

The goal of the following set of DCL commands is to move these files to a directory called MY_DISK:[TOP.BRANCH.ARCHIVE.20140613]:

$ set prot=o:rwed my_disk:[top.branch]archive.dir
$ rename my_disk:[top.branch]archive.dir my_disk:[top]branch_archive.dir
$ set prot=o:rwed my_disk:[top]branch.dir
$ rename my_disk:[top]branch.dir my_disk:[top.branch_archive]20140613.dir
$ create/dir my_disk:[top.branch]
$ rename my_disk:[top]branch_archive.dir my_disk:[top.branch]archive.dir

Now imagine there are 80+ BRANCH.DIR directories (with different names of course) and we have that sequence of commands execute in parallel jobs, one for each directory.

The vast majority of the time, this works fine. However, on the odd occasion, the CREATE/DIR command says that the directory already exists, even though the preceding RENAME has returned a success status.

After the CREATE/DIR, the next RENAME also succeeds, however, right afterwards, the BRANCH.DIR directory has mysteriously gone missing! The directory is only then recoverable by performing an ANALYZE/DISK/REPAIR.

This is on I64 8.4 with UPDATE-V0800, FIBRE_SCSI-V0500, RMS-V0400, and SYS_V0300.

The underlying ODS-5 disk is a two member shadow set that a SET VOLUME/CACHE=NODATA has been issued against (the disk is 99.9% write) mounted on all nodes of a five member cluster.

I've logged a call with HP against this.