"product remove" from a dead disk

[Jansen_8]

I installed one layered product (GNV to be precise) at another disk than the system disk using the /destination switch on the product command. Unfortunatly this disk died and I had to run the cluster with one disk less. I got GNV running by just copying everything form backup to another disk and adjust the logicals. So far so good.
Today I tried to install the new version of GNV, but failed, since Product cannot remove the old version from the dead disk. What do I have to do to trick PRODUCT?

Jouk

[labadie_1 · Accepted solution]

Hello

Here is a paste from a post on comp.os.vms, from Mr Hammond

When a product is installed, the PCSI utility stores the associated
logical volume name of the destination device in the product database,
not the actual device name. Since the destination volume is no longer
mounted, PCSI cannot use this logical name to find the device on which
your product was orignally installed. The logical volume name is used
so that the user can move files to another physical device with the
same or different label. However, PCSI must be told what happened so
that it can update the product database.

First, let's define "logical device name". This is the string that is
returned from:

$ WRITE SYS$OUTPUT F$GETDVI("","logvolnam")

This logical name is created by the MOUNT utilty when the volume is
mounted and a logical name of the form DISK$ is associated with
the device. You cannot simply define the logical name -- it must be
created and associated by the MOUNT command for PCSI to be able to use
it.

[NOTE: You cannot correctly create this logical name because
it is related to other data structures created by MOUNT.
Note also that if you rename a volume, you must dismount and
remount it to get the logical name and other data structures correct. /CWH]

You should be able to use the following command to see this logical
volume name in your database:

$ PRODUCT SHOW OBJECT * /PRODUCT= /FULL

Each file object should have the dev:[dir]file.type listed.

Here's how you can recover.

----------
Scenario 1
----------

If you copied your product to the same directory tree on the new
device (ie, dev:[web.][prod-dir...]), then all you need to do is to
tell PCSI about the new volume using the following command:

$ PRODUCT REGISTER VOLUME

You will be prompted to enter:

_Logical volume name in database: ! what prod show object showed
_Device name of mounted volume:

PCSI will find the new associated logical device name to put into the
database. Reenter the PRODUCT SHOW OBJECT command to verify the change.
If all is well, then you're done.

----------
Scenario 2
----------

If you copied your product to a different directory tree on the new
device then things are more complicated. For example if the files
were copied from DKA2:[WEB.] to $9$DKA103:[000000] or $9$DKA103:[a.b.]
then changing the device information is not sufficient as PCSI will
think the files are in $9$DAK103:[web.][...]. The workaround requires
two steps.

1. Use PRODUCT REGISTER VOLUME as before (or mount a spare volume
with the old label), then use PRODUCT REMOVE to remove the product
info from the database. PCSI won't care that it cannot find the
files and directories, but it will remove objects from the
database.

2. Either re-install the product to the same place where it currently
resides, or use the following command:

$ PRODUCT REGISTER PRODUCT -
/SOURCE= -
/DESTINATION=dev:[dir]

Make sure the destination dev:[dir] specifies the directory path
under which all product files are placed - what you would have
specified if you had installed the product to this device using
the /DESTINATION qualifier.

Then do a PRODUCT SHOW OBJECT /FULL command as before to see that all
objects are recorded properly. Repeat step 2 for other products you
may have manually moved to the new divice.

= end ==========================================================================

[Jansen_8]

Thanks

I just defined the "disk logical" and it worked

Jouk

[Jansen_8]

solved

[labadie_1]

Fine.

I think PRODUCT should be modified to handle simply/transparently this kind of situation we have all experienced (dead disk or disk replaced by another one, a bigger one, a RAID 1/ RAID 5/ RAID 6...).

May be we should log a SPR on Hp User advocacy ? If we are enough to sign, HP may consider it.