Nam block errors

[gunthjl1]

Why am i getting invalid nam block records when I try to restore standard vms backup tapes. This is a new problem that just started happening and nothing has changed on the vms systems in years

[Volker Halle]

gunthjl1,

welcome to the OpenVMS ITRC forum.

It would help substantially, if you could provide further information about what you are trying to do (which command did you execute ?) and what the exact error message is.

Volker.

[gunthjl1]

Trying to restore files from a backup tape to hard disk...

using bac/lis/log mka500:diske/save_set [...]*.*;*

Error is... error writing to disk gollum:[000000]
Invalid nam block record

[Volker Halle]

gunthjl1,

just tried a BACKUP/LIS/LOG saveset/SAVE disk: command on OpenVMS Alpha V8.2 and it seemed to work in general.

Did you try without /LIST ?

Does a BACKUP/LIST of this saveset work ?

What OpenVMS architecture and version ?

Could you please give an exact example of the full error message ?

Volker.

[gunthjl1]

running open vms version 6.1. VMS wokstation (not an alpha)

Exact error message is...

BACKUP-E-OPENOUT, error opening GOLLUM:[000000]*.*;* as output
-RMS-F-RLF, invalid NAM block


Input command was...

bac/log mka500:diske/save_set [...]*.*;*

Thanks in advance for your help!!

Jack

[gunthjl1]

sorry...the error was... invalid related NAM block

[Volker Halle]

gunthjl1,

GOLLUM is supposed to be a logical name pointing to a mounted disk, right ?

What does $ DIR GOLLUM:[000000] give ?
And $ ANAL/DISK GOLLUM ?

BACKUP seems to have an internal RMS problem creating the destination file name.

Volker.

[gunthjl1]

Yes...Gollum is the disk name

dir gollum:[000000] lists the files on the top directory

analyze is giving me a TON BADHEADER errors....sound like a hard disk problem to you?

[gunthjl1]

First line after I issue the analyze command is...

error opening quote.sys....no such file

[Volker Halle]

gunthjl1,

the only mention of RMS-F-RLF errors in conjunction with backup, that I've found, are related to deep directories, i.e. if you try to restore to a directory deeper than 8 levels from [000000]. Could this be the case here ? What does BACKUP/LIS tape:diske/SAVE shows up as file names ?

The message about QUOTA.SYS missing can be igned, if you don't have disk quotas enabled on that disk.

Can you temporarily restore the desired files onto another disk ?

Volker.

[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.

[Volker Halle]

Kelly,

I re-tried the %RMS-F-RLF google search today and it does not work for me as well anymore. I'm pretty sure, that I tried it yesterday, before entering the reply in ITRC, but ??? As a workaround, search for RMS RLF BACKUP in google groups.

Volker.

[Hoff]

That the error is RLF invalid NAM block is weird; I'd have expected that to be one of the two errors:

%RMS-F-RLF, invalid related NAM block

%RMS-F-NAM, invalid NAM block or NAM block not accessible

Strangely, I don't see any hits in any of the search engines I've tried other than this thread. FWIW, it is increasingly infeasible and decreasingly effective to try to use Google to search for information at the HP site. (There are blocks in place preventing Googlebot from indexing?)

Definitely look to ODS-5 and to an OpenVMS release from this decade. :-) The RLF error does point to a bug in BACKUP, do look for ECO kits. That written, file-oriented operations with BACKUP with greater than eight directory levels means you need ODS-5 and extended filename specification support, or careful use of concealed rooted logical names with use of /SELECT.

[Kelly Stewart_1]

Hoff: "Um, I'd call that miraculous, actually. :-)"

Nothing miraculous about becoming senile! My machines are VAXes and the version, of course, is 7.3 not 7.3-1. Sometimes the fingers just keep typing by themselves. Jack's machines apparently are also VAXes ("version 6.1 ... not Alpha").

Volker: "I re-tried the %RMS-F-RLF google search today and it does not work for me as well anymore."

It seems to be about the hyphens. When I replace them with spaces, I get hits.

Hoff again: "The RLF error does point to a bug in BACKUP, do look for ECO kits."

I am confident I have installed all BACKUP related ECOs, but I'll double-check when time permits.

"That written, file-oriented operations with BACKUP with greater than eight directory levels means you need ODS-5..."

Well, in our case, we thought we _had_ limited ourselves to eight levels, but BACKUP disagreed. BACKUP without /SELECT automatically inserts the root directory into the file specification (at least during restoration); CREATE/DIR does not. The root cause(no pun intended), I suspect, is not BACKUP, but the(apparent)fact that the root directory is not counted toward the level limit unless it is explicitly entered.

All told, at my site it's a rare, moderate annoyance. Sound's like Jack has a more serious situation.

Kelly

[Steven Schweda]

> [...] file-oriented operations with BACKUP
> with greater than eight directory levels
> means you need ODS-5 and extended filename
> specification support, or careful use of
> concealed rooted logical names with use of
> /SELECT.

Which part of that don't I understand?

ALP $ backup /log btest.bck /save [*...]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV.
EIG]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV.
EIG.NIN]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV.
EIG.NIN.TEN]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV.
EIG.NIN.TEN.ELE]
%BACKUP-S-CREDIR, created directory ALP$DKA0:[BTEST.ONE.TWO.THR.FOU.FIV.SIX.SEV.
EIG.NIN.TEN.ELE.TWE]

ALP $ show devi /full ALP$DKA0:

Disk ALP$DKA0:, device type IBM-ESXS ST336605LC !#, is online, mounted, file-
oriented device, shareable, served to cluster via MSCP Server, error logging
is enabled.
[...]
Volume Status: ODS-2, subject to mount verification, protected subsystems
enabled, file high-water marking, write-through caching enabled.

[Hoff]

> Which part of that don't I understand?

Brain glitch on my part. BACKUP got tweaked to go deeper; an old limit was been removed from BACKUP. But not removed from my memory. BACKUP used to do only eight levels, and you could get another eight with artful use of a concealed rooted logical name and /SELECT. This limit was removed at V6.2, where BACKUP depth was increased to 32.