HP3000/HP 3000 FAQ

Last Updated: Thursday, February 01, 2007 02:38 PM

Issues when restoring files from an MPE/iX 5.0 HP3000 system to MPE/iX 4.0 then updating to MPE/iX 5.0.

3.11. Issues when restoring files from a 5.0 system to 4.0 then updating to 5.0.

I updated our 967 to 5.0 in early June. At that time, several 3rd party software accounts (e.g. VESOFT, ROBELLE, NSD, etc.) existed on our system volume. I left them where they were to address later. I decided the time had come to move them to the user volume, and read everything I could find, etc. and moved them accordingly. I had no problem with anything except NSD which I use extensively. Many files had been assigned acds during the restore to the user volume. I had to create some workarounds quickly to get the system available for users, and then began to research this problem. I had read everything I could find on the HP Support Line about user volumes, but I had not looked into into acds. Anyway, I finally found document A3799035 "ACDS WERE ASSIGNED TO RESTORED FILES. WHY?" My restore command should have been something like:

"restore*t;@.@.nsd;show=offline;volset=user_volume_set;olddate;account=nsd"

This was unknown to the software company, as well as to others within my corporation that I had talked with. The document follows for your reading and enjoyment pleasure.

Document Id: A3799035
Date Loaded: 06-06-95

Description: ACDS WERE ASSIGNED TO RESTORED FILES. WHY?

PROBLEM TEXT

I recently restored files from my 957 (which was recently updated from 4.0 to 5.0) to my 995 which is on 5.0. All the files came from one account on the 957.

After restoring these files, they all had ACDs on them and the security was changed to not allow anyone to access the file.

A LISTFIILE ./filename,-3 showed that READ, WRITE, APPEND, LOCK, and EXECUTE access was all blank. A LISTFILE ./filename,4 showed ACD EXISTS.

In addition. LISTFILE ./filename,-3 showed that the GROUP ID: contained the name of an account that does not exist on this system (995), or on the original system (957)

Why did the system put ACDs on the file and restrict access?

RESOLUTION TEXT

An ACD is assigned to a file when certain criteria is met. One of these criteria is if the "object is directly below MPE groups whose GIDs do not match the GIDs of the accounts in which they exist." (see Page 5-21 of the 5.0 Communicator).

When the files were restored to your 995, the file system checked this GID field, saw it did not match the account you were restoring into and enforced this ACD assignment.

Your case was a bit special, since the files from the originating system (957) did NOT have ACDs but the GID field did exist and showed a account name which did not exist on the 957 either.

We determined that these files were restored to the 957 when it was on 4.0 from a 3rd party vendor. The 3rd party vendor had created these files on a 5.0 system, which assigned a GROUP ID (GID) to each file. When the files were restored to the 4.0 system, this field was meaningless to the file system. When the 957 was updated to 5.0, still no ACDs were assigned since the file system does not search the system for files meeting this criteria. It's not until the files are acted upon (as in copied, renamed or restored to a different system) that the GID field is evaluated. Therefore, when you restored this account to your 995, the 5.0 file system did what it was supposed to do: evaluate the GID of the incoming files and act accordingly.

The problem was solved by adding ;ACCOUNT=accountname to the RESTORE command. This assigned the correct GID to the incoming files, allowing the same access they had on the originating system.

KEYWORDS LIST

POSIX GROUP ID
ACD SECURITY
RESTORE ACD

If you're fortunate enough to have access to MPEX (version 25), you could also have issued the following command:

%ALTFILE (fileset); LOCAL; DELACD

This will 1) fixup all GROUPIDs to match the ACCOUNT where each file is located, and then 2) delete all ACDs associated with each file. Fixing up the GROUPIDs is a prerequisite for being able to remove the ACD. Of course, re-RESTORING the files is fine, just a bit longer.