Reloading, Redux: How To
October 7, 2015
It used to be the worst thing that could happen to an HP 3000 was a reload of its data. Adager gained its central place in the 3000 manager's toolbox because it would prevent the need for a reload after database restructuring. Although the worst thing to happen to today's 3000 is the loss of an expert to keep it healthy and sustained, reloads are still a significant event.
Not very long ago, a 3000 manager was looking for a refresher on how to do a system reload. Ernie Newton explained why he needed one and shared what he knew. Advice about adding the DIRECTORY parameter, and using BULDJOB1 to set up the accounting structure, followed when Ernie said
We suffered a double drive failure on our Raid 5 disk array yesterday and I'm thinking that I may have to do a reload. It's been almost 15 years since I've done one. If I recall, I do a load when bringing the system up, then do a restore @[email protected]@.
Our resident management expert Gilles Schipper provided detailed instruction on doing a reload. We hope it's another 15 years for Ernie until he's got to do this again.
Here are the instructions, assuming your backup includes the ;directory option, as well as the SLT:
1. Boot from alternate path and choose INSTALL (assuming alternate path is your tape drive)
2. After INSTALL completes, boot from primary path and perform START NORECOVERY.
3. Use VOLUTIL to add ldev 2 to MPEXL_SYSTEM_VOLUME_SET.
4. Restore directory from backup (:restore *t;;directory)
5. openq lp
6. Perform a full restore with the following commands
7.Perform START NORECOVERY
The reason for limiting LDEV to 75 percent is to minimize the otherwise already heavy traffic on LDEV 1, since the system directory must reside there, as well as many other high traffic “system” files.
You won't want to omit the ;CREATE and ;PARTDB options from the restore command. Doing so will certainly get the job done -- but perhaps not to your satisfaction. If any file that exists on your backup was created by a user that no longer exists, that file (or files) will NOT be restored.
Similarly, if you omit the ;PARTDB option, any file that comprises a TurboIMAGE database whose corresponding root file does not exist, will also not be restored.
I suppose it may be a matter of personal preference, but I would rather have all files that existed on my disks prior to disk crash also exist after the post disk-crash RELOAD. I could then easily choose to re-delete the users that created those files -- as well as the files themselves.
Another reason why the ;SHOW=OFFLINE option is used is so that one can quickly see the users that were re-created as the result of the ;CREATE option. Purging the "orphan" datasets would be slightly more difficult, since they don’t so easily stand out on the stdlist.
Finally, it’s critical that a second START NORECOVERY be performed. Otherwise, you cannot successfully start up your network.