PCSI update of software on a different disk than it was installed on
Alan Winston - SSRL Admin Cmptg Mgr
VMS Alpha 7.3-2
I used to have my CSWS tree installed on a $web "pseudo-disk"; a rooted
logical on another disk. (So $WEB was actually DKA2:[WEB.]). At Christmas
I moved all that stuff to a volume of its own, so $WEB is now $9$DKA103., and
that's the volume with APACHE$COMMON, etc.
Now I come to update PHP to 1.2 from 1.1.
PCSI wants to install it in DKA2:[WEB.]
which of course doesn't work. It also can't uninstall it, because that tree
doesn't exist anymore.
What's the recommended procedure here? I'm going to have this trouble again
with CSWS_PERL and with CSWS itself (or SWS, anyway) when I go to upgrade it.
I would rather avoid having to copy the whole apache$common tree back to the
DKA2: so I can PRODUCT REMOVE it and then do a fresh install to the new disk.
What do I do? What should I have done to avoid this problem in the first
place?
Thanks,
-- Alan
--
===============================================================================
Alan Winston --- WIN...@SSRL.SLAC.STANFORD.EDU
Disclaimer: I speak only for myself, not SLAC or SSRL Phone: 650/926-3056
Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA 94025
===============================================================================
Karl Rohwedder
> Gang --
>
> VMS Alpha 7.3-2
>
> I used to have my CSWS tree installed on a $web "pseudo-disk"; a rooted
> logical on another disk. (So $WEB was actually DKA2:[WEB.]). At Christmas
> I moved all that stuff to a volume of its own, so $WEB is now $9$DKA103., and
> that's the volume with APACHE$COMMON, etc.
>
> Now I come to update PHP to 1.2 from 1.1.
>
> PCSI wants to install it in DKA2:[WEB.]
>
> which of course doesn't work. It also can't uninstall it, because that tree
> doesn't exist anymore.
>
> What's the recommended procedure here? I'm going to have this trouble again
> with CSWS_PERL and with CSWS itself (or SWS, anyway) when I go to upgrade it.
> I would rather avoid having to copy the whole apache$common tree back to the
> DKA2: so I can PRODUCT REMOVE it and then do a fresh install to the new disk.
>
> What do I do? What should I have done to avoid this problem in the first
> place?
>
> Thanks,
>
> -- Alan
>
>
>
Please check for the PRODUCT REGISTER VOLUME command.
Alan Winston - SSRL Admin Cmptg Mgr
Doesn't look like it'll do the trick, if I'm reading the HELP correctly.
This apparently allows changing the registered volume label, not the underlying
disk device.
Thanks, though!
JBl...@acme.com
("Alan Winston - SSRL Admin Cmptg Mgr") wrote:
>Gang --
>
>VMS Alpha 7.3-2
>
>I used to have my CSWS tree installed on a $web "pseudo-disk"; a rooted
>logical on another disk. (So $WEB was actually DKA2:[WEB.]). At Christmas
>I moved all that stuff to a volume of its own, so $WEB is now $9$DKA103., and
>that's the volume with APACHE$COMMON, etc.
>
>Now I come to update PHP to 1.2 from 1.1.
>
>PCSI wants to install it in DKA2:[WEB.]
>
>which of course doesn't work. It also can't uninstall it, because that tree
>doesn't exist anymore.
>
>What's the recommended procedure here? I'm going to have this trouble again
>with CSWS_PERL and with CSWS itself (or SWS, anyway) when I go to upgrade it.
>I would rather avoid having to copy the whole apache$common tree back to the
>DKA2: so I can PRODUCT REMOVE it and then do a fresh install to the new disk.
>
>What do I do? What should I have done to avoid this problem in the first
>place?
>
>Thanks,
>
>-- Alan
It looks to me as though, PRODUCT is looking at the volume-label
of the destination device, and translating the associated logical,
and saving that in the *.PCSI$DATABASE file.
In my experience with (very simple) .pcsi KITS is that PRODUCT REMOVE
needs to 'see' the (destination) device originally recorded in the
respective *.PCSI$DATABASE,
but the dir-tree need not be actually populated (or even exist).
The device can be faked out with a /job/exec logical,
but afaict, it must point to a existing, mounted device.
Yet, I'd wager there could be rather more to it than that.
particularly, if there is a command proc specified for
'execute ..remove" phase in the original .pcsi$desc.
Could perhaps experiment w/ small .PCSI kits to verify
your understanding.
$ create/log ALPHA.COM;
$ create/log BRAVO.COM;
$ create/log CHARLIE.COM;
$ create/log DELTA.COM;
$!
$ create/log []ALANW.PCSI$DESC;
product SLAC AXPVMS ALANW V02.03-001 full;
file [THIS]ALPHA.COM ;
file [THAT]BRAVO.COM ;
execute
install "@PCSI$DESTINATION:[THIS]CHARLIE.COM "
remove "@PCSI$DESTINATION:[THAT]DELTA.COM " interactive
;
end product ;
$!
$ product package ALANW -
/SOURCE=[]ALANW.PCSI$DESC -
/destination=[] -
/material=[] -
/format=sequential
$!
$! should have a SLAC-AXPVMS-ALANW-V0203-1-1.PCSI in curr. dir
$!
$! try various /DESTINATIONS, for PRODUCT INSTALL;
$! look at SYS$SYSYSTEM:SLAC-AXPVMS-ALANW-V0203-1.PCSI$DATABASE
$! and see how the destination dev/dir is recorded.
$!
A missing execute...remove .COM looks approx, like so:
...
...
Portion done: 0%
%DCL-E-OPENIN, error opening LOG3DISK:[WEB.][THAT]DELTA.COM; as input
-RMS-E-DNF, directory not found
...60%M-W-NOSUCHFILE, no such file
%PCSI-E-EXERMVFAIL, product supplied EXECUTE REMOVE procedure failed
-RMS-E-DNF, directory not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate?[YES]NO
Portion done: 70%...80%...100%
The following product has been removed:
SLAC AXPVMS ALANW V2.3-1 Layered Product
%PCSIUI-I-COMPWERR, operation completed after explicit continuation
from errors
$
Alan Winston - SSRL Admin Cmptg Mgr
>On Tue, 17 Aug 2004 08:09:23 GMT, win...@SSRL.SLAC.STANFORD.EDU
>("Alan Winston - SSRL Admin Cmptg Mgr") wrote:
>>I used to have my CSWS tree installed on a $web "pseudo-disk"; a rooted
>>logical on another disk. (So $WEB was actually DKA2:[WEB.]). At Christmas
>>I moved all that stuff to a volume of its own, so $WEB is now $9$DKA103., and
>>that's the volume with APACHE$COMMON, etc.
>>
>>Now I come to update PHP to 1.2 from 1.1.
>>
>>PCSI wants to install it in DKA2:[WEB.]
>>
>>which of course doesn't work. It also can't uninstall it, because that tree
>>doesn't exist anymore.
>It looks to me as though, PRODUCT is looking at the volume-label
And what I ended up doing was simply installing it anew on the new disk,
ignored the recommendation to terminate. This seems to have worked this time,
although of course I have to manually delete the old images.
Charlie Hammond
of the Pollycenter Software Installation (PCSI) utility developers.
I hope it is of some use.
= start ========================================================================
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("<dev>","logvolnam")
This logical name is created by the MOUNT utilty when the volume is
mounted and a logical name of the form DISK$<label> 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=<your-prod-name> /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 <your-prod-name> -
/SOURCE=<where-kit-is-located> -
/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 ==========================================================================
--
Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale FL USA
(hammond@not@peek.ssr.hp.com -- remove "@not" when replying)
All opinions expressed are my own and not necessarily my employer's.
Alan Winston - SSRL Admin Cmptg Mgr
>The following information was provided for posting here by one
>of the Pollycenter Software Installation (PCSI) utility developers.
>I hope it is of some use.
Thanks for the follow-up! This looks like a complete explanation of what's
needed.
Appreciate it.
David J Dachtera
>
> The following information was provided for posting here by one
> of the Pollycenter Software Installation (PCSI) utility developers.
> I hope it is of some use.
Thanx, Charlie!
I've saved that locally for my archives!
D.J.D.