Fixing an empty File Name in the file header

[Jeremy Begg]

Hi,

Running a mixed cluster of OpenVMS Alpha 8.3 and OpenVMS IA64 V8.4, I've been looking into "hot files" on the system using SHOW MEMORY/CACHE=(VOLUME=dev,TOPQIO=20).

I've noticed a few files, especially on the Alpha system disk, are shown with incomplete file names.

For example,

_$1$DGA20624:[VMS$COMMON.]DECC$SHR_EV56.EXE;1 (38314,158,0) (open)
 Caching is enabled, active caching mode is Write Through
    Allocated pages             67     Total QIOs            2503279
    Read hits              2502155     Virtual reads         2503279
    Virtual writes               0     Hit rate                   99 %
    Read aheads                  3     Read throughs         2503277
    Write throughs               0     Read arounds                2
                                       Write arounds               0
                                                                                                                                    

You'll notice in the filename that the final part of the directory name is missing: it should be _$1$DGA20624:[VMS$COMMON.SYSLIB]DECC$SHR_EV56.EXE;1

So I did a little digging and a dump of the file header for SYS$COMMON:[000000]SYSLIB.DIR shows:

$ dump/head/bl=c=0 sys$common:[000000]syslib.dir

Dump of file SYS$COMMON:[000000]SYSLIB.DIR;1 on 12-OCT-2012 15:15:32.38
File ID (1602,1,0)   End of file block 89 / Allocated 105

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (1602,1,0)
    Extension file identification:        (0,0,0)
...
Identification area
    File name:
    Revision number:                      141
    Creation date:                         6-FEB-1996 07:54:29.31
    Revision date:                        19-JUN-2012 15:43:01.76
    Expiration date:                      <none specified>
    Backup date:                          13-SEP-2012 10:56:34.71

Map area
    Retrieval pointers
        Count:        105        LBN:   76980015

Checksum:                                 27243
$

Is there a way I can fix the File Name field in the Identification Area section, without shutting down the system?  I tried

$ RENAME SYSLIB.DIR SYSLIB.DIR

but that didn't work.  I suspect if I rename it to some other name entirely, and back again, that will do the job.  (But if a program is starting up at the wrong moment it's going to fail with file not found error when the image activator attempts to load any shareable images the program may require.)

Thanks,

Jeremy Begg

[Hein van den Heuvel]

Here are some, admittedly unfinished thoughts....

0) too bad (DFU) SET FILE does not have this huh? 

Should be too hard to write a program to stick a filename in there (and update the checksum)... 

1) Typically no program/script knows directly about SYSLIB.

They know through a logical name, notably SYS$LIBRARY and SYS$SHARE.

So you could define those as a searchlist of  [SYSLIBTMP],[SYSLIB] then rename SYSLIB.DIR to SYSLIBTMP.DIR and back and clean out the logical. 

I recommend experimenting on a test logical, or even on quick copy of a system disk for an emulator (FreeAXP or other) .

2) is this a cluster?

Through SYS$SYSROOT there is already a searchlist.

Does  [SYS0.SYSLIB] have anything useful in there? Can you do without for a minute?

You could try

2a: rename [SYS0]SYSLIB.DIR away to [SYS0]SYSLIB_save.DIR

2b: rename [VMS$COMMON]SYSLIB.DIR  to [SYS0]SYSLIB.DIR

2c: rename  [SYS0]SYSLIB.DIR back to [VMS$COMMON]SYSLIB.DIR 

2d: rename [SYS0]SYSLIB_save.DIR, back to [SYS0]SYSLIB.DIR 

Before doing any on this... Use DIR/FILE to know exactly which file you are addressing.

Maybe use SET FILE/ENTER to create an alias for SYSLIB as backup just in case you drop something on the floor while juggling... or is that how the empty name came to be.

So how do you think this situation came to be? Any guesses?

What OpenVMS version was used for the install? (too long ago to know?)

Does anyone else see this?

Good luck!

Hein

[Hein van den Heuvel]

Steven wrote>> pipe rename blah1 blah2 ; rename blah2 blah1

I don't see how pipe would be better than a quick command file... except that it is a single liner not needing a (temp) file. I would prefer a command file. Better understood.
But either way, it would activate RENAME twice introducing the risk Jeremy is worried about that the second rename migth fail becaus SYSLIB files can not be found.

So my preference would be a single program activation.
Write your own with C rename or LIB$RENAME.
I might use PERL's buildin rename functions... 
If you use perl for it, then practive first notably when there are dollars in the name strings.
You need to escape $ as \$ or use q(xxxx) to pass the string without attemps at variable interpolation.

Hein

[John Gillings]

My concern about the two RENAME commands is the image activation of the second command. If SYSLIB was "moved" by the first, how will the second find all the shareable images it needs?

I think Hein's idea of setting up a search list for SYS$SHARE would be prudent. I think I'd also take a private copy of all of SYSLIB and redirect to that for the duration of the operation, just to be on the safe side.

Other things to check... what do installed images look like? Known file activation is fairly picky about file names, will changing it underneath mess up activations?

What happens if you take a COPY of SYSLIB.DIR into a private directory? Does it give you something you can experiment with?

[Jeremy Begg]

Hi all, and thanks for your comments.

Both **bleep**/DISK and DFU VERIFY have no complaints about this disk.

I think John's hit the nail well and truly on the head with his comments about the second RENAME command -- it probably wouldn't have run!  I could get around that by running the commands on a system which boots from another disk (i.e. either of the Itanium servers in this cluster) but I think I'll follow up on the search list idea and SET FILE/ENTER suggestions.  I'll also look at writing a simple C program to do both RENAMEs in a single image activation.

As to how things got into this state ... the best theory I've been able to come up with, given the long history of these systems, is that it's the remnants of a botched attempt many years ago to fix broken backlinks for these directories.  (Which I think in turn was caused by a broken BACKUP image many moons ago, when all customers were advised to rename SYSCOMMON.DIR.)

Anyway, more research and experimentation required ...

[Jeremy Begg]

Just a bit more info ... I tried John's suggestion of taking a copy of SYS$COMMON:[000000]SYSLIB.DIR, i.e.

$  copy/log sys$common:[000000]syslib.dir sys$login:

which produced a perfectly valid but empty directory file.  Using BACKUP instead of COPY produced the same result.  And on reflection, wouldn't have got me any closer to the solution because I'd still have to get rid of the original at some stage.

[John Gillings]

Jeremy,

   I was expecting the copy to be empty. What I was curious about was the filename field in the header. Would COPY blindly propagate the empty field? I guess not, which leads to the question of why it didn't complain and how it figured out what should be there. Have you looked at a raw dump of this file header? Maybe it's just a broken field length?

[Jeremy Begg]

Hi John,

I didn't expect the copied directory to be empty, which shows how often I've done it.

It would appear the filename in the header is actually blank.  Here are is the start of the header formatted using DUMP/FILE, and then without /FILE ...

Dump of file SYS$SYSDEVICE:[000000]INDEXF.SYS;1 on 15-OCT-2012 16:15:25.14
File ID (1,1,0)   End of file block 209619 / Allocated 209650

Virtual block number 2166 (00000876), 512 (0200) bytes

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (1602,1,0)

   ...

Dump of file SYS$SYSDEVICE:[000000]INDEXF.SYS;1 on 15-OCT-2012 16:15:58.01
File ID (1,1,0)   End of file block 209619 / Allocated 209650

Virtual block number 2166 (00000876), 512 (0200) bytes

 005A0000 00690000 02000802 00000000 00000000 00010642 02010000 FFFF6428 (d......B.................i...Z. 000000
 00010004 00030000 00202080 00000000 00000000 00000000 00000200 00000000 .....................  ......... 000020
 20202020 20202020 20202020 20202020 0000006A 00000000 00000001 000FAA88 .ª..........j...                 000040
 DDCF0000 00000000 000000AC 31BAAC3D 3F060099 D7F0CE7D 9BAB008D 20202020     ..«.}Îð×...?=¬º1¬.........ÏÝ 000060
 20202020 20202020 20202020 20202020 20202020 20202020 202000AC 7526E77C |ç&u¬.                           000080
 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020                                  0000A0
 00000000 00000000 00000000 00000000 00000496 9F2F8068 20202020 20202020         h./..................... 0000C0
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000E0
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000120
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000140
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0
 6A6B0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ..............................kj 0001E0

I won't speculate on how COPY or BACKUP know what to call this file when it's copied.

[Hein van den Heuvel]

SMOP... See attached.

1 Bottle of Ommegang Abbey Ale, a handy example, and 32 minutes...

Tested for exactly 1 success and 1 failure situation. Trust but verify.

I recommend testing on an LD or MD virtual disk first. 

During the test I was reminded that DELETE likes to check the name in the header to try figure out what to do with ALIAS entries in the same directory.

If you are not careful, then ANALYZE.DISK will quickly report...

%ANALDISK-W-LOSTHEADER, file (12,1,0) Hello
        not found in a directory

Usage example where I add an extra entry in the directory to make delete happy...

$ init/size=1000 mda5:  hein
$ mount /sys mda5: hein ram
%MOUNT-I-MOUNTED, HEIN mounted on _EISNER$MDA5:
$ cre/dir ram:[hein]
$ cre  RAM:[HEIN]ABC.TXT;
test
$ pipe dump/head/bloc=count=0  RAM:[HEIN]ABC.TXT | search sys$pipe "File name:"
    File name:                            ABC.TXT;1
$ set file/log/enter=XYZ.DAT ram:[hein]ABC.TXT
%SET-I-ENTERED, RAM:[HEIN]ABC.TXT;1 entered as RAM:[HEIN]XYZ.DAT;
$ dir/file/nohead/notrail/wid=file=30 ram:[hein]
RAM:[HEIN]ABC.TXT;1             (12,1,0)
RAM:[HEIN]XYZ.DAT;1             (12,1,0)
$ pipe dump/head/bloc=count=0  RAM:[HEIN]ABC.TXT | search sys$pipe "File name:"
    File name:                            ABC.TXT;1
$ mcr sys$login:ZAP_NAME_IN_HEADER RAM:[HEIN]ABC.TXT "XYZ.DAT;1"
$ pipe dump/head/bloc=count=0  RAM:[HEIN]ABC.TXT | search sys$pipe "File name:"
    File name:                            XYZ.DAT;1
$ dele ram:[hein]ABC.TXT;1/log
%DELETE-I-FILDEL, RAM:[HEIN]ABC.TXT;1 deleted (1 block)
$ **bleep**/disk ram:
Analyze/Disk_Structure for _EISNER$MDA5: started on 15-OCT-2012 00:17:53.65
$

Enjoy...