Problem with Authorise command VMS 6.2

[Dale Samson]

Hi
I'm having a problem with a record when using the Authorise utility in OpenVMS 6.2.

At the UAF prompt, when I type: show , I get the error:
%UAF-E-SHOW_ERR, error during SHOW
-RMS-F-CHK, bucket format check failed for VBN = 103.

As explained in previous posts, I'm a returnee to VMS and have been assigned an Alphaserver which has been running on autopilot for years. I'm assuming, with my limited recollection, that there's corruption in the sysuaf.dat file. Although I have recently been taking monthly images of the system disk, I'm almost certain that this problem predates these, and so I don't have a good backup of this file.

Other records seem ok - when I do SHOW/BRIEF *, it shows a large number of records up until the error (although there are probably a further number of records after it). The records of the current small number of users are ok at present, but I'm worried that this corruption may spread and effectively lock them out.

Anyone have any ideas?

Thanks

Dale

[Dean McGorrill]

hi Dale,
Yes it sounds like an corruption of
some kind. make a few copies of the sysuaf.dat. you might be able to take out
the bad record with
$ open/read/write/share -
xx sys$system:sysuaf.dat

$ read/del/key="BADUSER" xx x
$ close xx

or try running a convert on it

$ convert sysuaf.dat sysuaf.dat

Dean

[Hoff]

This SYSUAF.DAT file does appear to be corrupted.

This could be triggered by an RMS-level corruption, or by a bad block underneath the file.

Given the particular file involved, I would be tempted to code and use a series of $get and $put calls within an application, this to rebuild the file under direct manual control. Somewhat easier than coding this, a CONVERT or mayhap a MERGE over into a known-good file might be expeditious here.

If you get rid of any SYSUAF, RIGHTSLIST, NET*PROXY and related logical names (if any exist), and SET DEFAULT to somewhere other than the directory containing SYSUAF.DAT, AUTHORIZE can create a new file for you. The other option is to grab the template copy off a distro, as IIRC there are slight differences between what the distro contains and what AUTHORIZE creates. (And most folks will have the version provided by the distro.)

It's certainly potentially feasible to dig around and patch the file structure, but that's a fair chunk more work if this can be resolved by a record-level COPY, or a MERGE or CONVERT into a new file.

There are low-level errors in this vintage in the CONVERT implementation, IIRC. Do check that the ECOs on this box are current, too.

I'd also be looking for disk-level errors, and related damage. If this was a block-level error, there can be others of its kind lurking. Having a full disk BACKUP would be another recommended task.

Stephen Hoffman
HoffmanLabs.com

[Robert Gezelter]

Dale,

I concur with Hoff.

Use OpenVMS BACKUP to make a backup copy before doing anything (I would also suggest the VERIFY option). Then, after placing a copy of the UAF in an alternate work directory, you can try the various recovery techniques, primarily some utilization of CONVERT, to check the file.

Depending on the account, you may also have the option of deleting the account (or renaming it), and then re-creating it.

- Bob Gezelter, http://www.rlgsc.com