Nam block errors

[gunthjl1]

yes...directory tree structures exceed 8 levels at times. I would have thought that the backup would ignore those and continue on but that is evidently not the case. I'll play around with it a bit tomorrow. Thanks again for your help!!!

jack

[Hoff]

SHOW LOGICAL /FULL GOLLUM

It is quite common for a concealed rooted logical name to be incorrectly defined. Stuff can mostly work with incorrect logical name definitions. Match how the SYS$SPECIFIC logical name is defined, for instance, with both the concealed and terminal attributes and with the trailing dot.

Also SHOW ERROR, and see if there are hardware errors.

Also ANALYZE /ERROR to look for (recent) hardware errors.

Post up a few of the BADHEADER errors from ANALYZE /DISK as well, assuming that the first ANALYZE /DISK /REPAIR does not clear this up.

This could be a bad logical name definition, a bad definition, or otherwise.

OpenVMS VAX V6.1 and its associated VAX hardware is sufficiently ancient that this could be an OpenVMS VAX bug, a logical name declaration error, bad hardware, or...

[Volker Halle]

Jack,

where is the directory level of 8 exceeded, in the disk saveset on tape or on the disk, where the logical GOLLUM points to ? Is this logical actually a concealed logical pointing to a directory on that disk ?

Is the DISKE saveset from a BACKUP/IMAGE operation ?

If you search in comp.os.vms (e.g. with Google Groups) for RMS-F-RLF, you'll find a couple of discussions about backup and directory depth. Some information in there may actually help...

Volker.

[Kelly Stewart_1]

Volker,

I tried your search suggestion (in fact I cut-and-pasted the error name from your post) for Google group comp.os.vms and got the following result:
"Your search - RMS-F-RLF - did not match any documents. "

So I tried "rms rlf" instead and got some usable hits - and the first one contained the string "RMS-F-RLF". Oh well!


Jack,

We had a similar problem recently.

In our case, the system allowed a user to define a directory tree with some subdirectories 8 levels deep not counting the root directory; something like "[d1.d2.d3.d4.d5.d6.d7.d8]". BACKUP by default inserts the root directory into the specification - "[000000.d1.d2.d3.d4.d5.d6.d7.d8]" - making 9 directories.

We worked around this by using the BACKUP/SELECT qualifier to pick out sub-trees (such that there were fewer than 8 levels) from the saveset, and a concealed, rooted logical name as the output device, but we had to do a separate restore operation for each sub-tree. There are some examples in comp.os.vms.

By the way, recent Alpha and Integrity versions of OpenVMS allow much greater directory depth.

Kelly

[Volker Halle]

Kelly,

try with searching for %RMS-F-RLF - it just worked for me and returned 7 matches.

Volker.

[gunthjl1]

Thanks all for your help with this. I'm outta here for 2 weeks so I'll play around with it more when I get back.

Yes, using the select parameter works and is okay if you are only doing limited files and directories. Unfortunately, I'm trying to restore entire 9 gig disk backups for 4mm tape. There are a lot of tapes per backup so using select is very time consuming.

Again, thanks for all the help!!!

Jack

[Volker Halle]

Jack,

if you are restoring an 'entire disk', you should use BACKUP/IMAGE (if the backup has been done that way). This should prevent those problems.

Volker.

[Hoff]

> By the way, recent Alpha and Integrity versions of OpenVMS allow much greater directory depth.

If circa decade-old software counts as "recent", yes.

[Kelly Stewart_1]

Volker,

This is weird. Tried it with Firefox and IE7 and got "Your search - %RMS-F-RLF - did not match any documents.". With and without quotes. Don't know what I'm doing different. This was with the "search this group" option at http://groups.google.com/group/comp.os.vms/topics. But as I said I did find the relevant topics with "rms rlf".

Just to see, I tried the %RMS-F-RLF search at www.google.com, and it returned one result - this thread :)


Hoff,

Okay, "more recent" :) Actually, my VAXes are running 7.3-1 which I could legitimately call "most recent", not that it helps!

[Hoff]

> Okay, "more recent" :) Actually, my VAXes are running 7.3-1 which I could legitimately call "most recent", not that it helps!

Um, I'd call that miraculous, actually. :-) AFAIK, there exists no release past V7.3 for OpenVMS VAX.

If the boxes in question are running OpenVMS Alpha and some Alpha boxes and not some VAX boxes, there's no (technical) reason not to go to V8.3 as the biggest bump in the upgrade road is probably the TQE work in the kernel that happened between OpenVMS Alpha V7.3-1 and V7.3-2. The cost of purchasing and of upgrading and of testing certainly applies here, of course.