10-20-2011 10:59 PM
This migh sound stupid, but im a little curious to test this just wanted to know it there is an option for that.
I received a system disk backup which is a non image backup. command used was
$ backup/ignore=inter sys$sysdevice:[000000...]*.*;*
This was actually taken by mistake on the other end, I will get another image soon with /image qualifier which will server my purpose.
In the mean time I wanted to test, whether with this backup we can boot or not. So what I did, I transferrred this save set to my FreeAXP disks and restored it to another disk with no other data except system files *.sys
and I got this command from hoff's site and written the boot block.
$ RUN SYS$SYSTEM:WRITEBOOT
When I gave a try to boot the machine... It booted.
And all the normal activities are fine.. all the startup are running, TCp/Ip is starting. I am able to login with the sysuaf restored from that backup.
But if some operation at low level is tried where the RMS and file id referencing is happening. The actual proble shows up.
$$ prod install *
%PCSI-E-SYSDIRERR, SYS$SYSDEVICE:VMS$COMMON.DIR and SYS$SYSDEVICE:VMS$COMMON.DIR;1 have different File ID numbers
-PCSI-E-CHKSYSDIR, check system directory structure
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition.
Index file is having different value in the header whereas the actual file is having a different value for File ID.
Is there any way to fix this up. Just out of curiousity...
10-21-2011 02:06 AM
I would not spend much time with this and would not rely on any free advice... Do a
10-21-2011 02:10 AM
May be your directory structure is a little bit damaged:
The sys$sysdevice:[SYSn]syscommon.dir and sys$sysdevice:vms$common.dir must point to the same file.
As an example, if everything is in good shape:
$ dir sys$sysdevice:[sys0]syscommon.dir/file_id
This is the same file-id as vms$common.dir:
If this is not the case, delete all trees sys$sysdevice:[SYSn.syscommon...]*.*;* and finally
and restore the correct directory structure via
$ set file/enter=sys$sysdevice:[sysx]syscommon.dir sys$sysdevice:vms$common.dir
Be warned. control every step very carefully.
If file-id is already identical the procedure does not solve your problem.
Hope this helps
10-21-2011 07:57 AM
See BACKUP Tips: Image and Alias and Saveset Processing and likely some other topics available around the 'net via Google.
Yes, this disk saveset can likely be easily restored, through the addition of the system directory backlinks and rewriting the boot block. It's not a direct replacement, but it works. (Things get more interesting with OpenVMS I64 disk structures, as that path really needs (wants) correct use of /IMAGE.) This centrally involves resetting the directory links though - if you've been running with this for a while - there are potentially other issues here.
Now for the downside of this backup. It's not the lack of /IMAGE that'll cause you problems (once you know the structures of an OpenVMS system disk). It's that /IGNORE=INTERLOCK that tends to cause problems with the restoration.
If you're going to use BACKUP, please take the time to read the examples in the BACKUP documentation and the BACKUP help text. BACKUP is one of the most arcane and cryptic tools on OpenVMS, and it's both effective at its task, and can also be a most excellent way to eliminate data integrity.
For best results, I'd probably reinstall from distro, and reload the OpenVMS and layered product software, and reset the BACKUP savesets. More work, but you know what the results are within the OpenVMS system files and structures. Now as for your local data, the data integrity of that is still questionable. That'll likely also get you current software versions and (if you take the extra steps) current patches.
This forum software still can't manage to edit an embedded link correctly, and it doesn't trim the blanks on the ends of the URL. Which also points to failures in the testing.