upgrade 7.3-1 --> 7.3-2
From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 05/21/05
- Next message: Stevie B: "unsubscribe"
- Previous message: Richard Maher: "New Cluster Interconnects"
- Next in thread: Peter 'EPLAN' LANGSTOEGER: "Re: upgrade 7.3-1 --> 7.3-2"
- Reply: Peter 'EPLAN' LANGSTOEGER: "Re: upgrade 7.3-1 --> 7.3-2"
- Reply: George Cook: "Re: upgrade 7.3-1 --> 7.3-2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 21 May 2005 14:53:56 +0000 (UTC)
I have a few questions regarding a 7.3-1 --> 7.3-2 upgrade.
First, though, I'm happy to say that it went well, and I now have a DEC
3000/300LX with 48 MB RAM (yes, I know that the official minimum is
more) running 7.3-2 (I did the upgrade on a 3000/600 with 192 MB RAM,
though) and apparently all is OK. (I also have TCPIP 5.4 ECO 4 now.)
I've done fresh installs with 7.1 (ALPHA), 7.2 (VAX), 7.3 (VAX) and
upgrades 7.1 --> 7.2-1 (ALPHA), 7.2 --> 7.3 (VAX), 7.2-1 --> 7.3-1
(ALPHA) and now 7.3-1 --> 7.3-2 (ALPHA). Only in this most recent case
did I see these problems; previously, everything went without a hitch.
First, I got this during the VMS upgrade (I simultaneously upgraded
DECnet, TCPIP, DECwindows and all the required stuff):
%PCSI-E-PARUDF, file [SYSLIB]SYS$STARLET_C.TLB was not previously
installed or is present but out of scope; module update skipped
Terminating is strongly recommended. Do you want to terminate? [YES]
First, I terminated as suggested. I was then informed that the target
disk had been changed. I had a backup with 7.3-1, of course, but now
that the target disk was already changed, I saw no harm in trying again,
since at worst it wouldn't work and I would have to revert to 7.3-1. I
then tried it again except that I didn't terminate.
I then saw some "DCL-W-skipdat" warnings, apparently from the
installation procedure, but no errors and, as I say, everything seems to
be OK.
The file in question exists on the 7.3-1 disk, on the 7.3-2 source disk
and the 7.3-2 target disk, so I really don't understand where the
message is coming from.
Directory DISK$ALPHASYS_3:[VMS$COMMON.SYSLIB]
SYS$STARLET_C.TLB;1
6070/6075 4-NOV-2004 20:41:46.97 15-MAR-2005 10:56:01.88
What does the message above actually mean? How could I test whether
something is indeed wrong with this file? (From the dates, however, it
looks like the version I currently have came from a patch. I did
verify, though, that it was on the 7.3-2 source disk and on the target
disk (with an earlier date) after the upgrade, and of course it was on
the 7.3-1 disk.)
Some related questions: After the upgrade, I immediately applied all
patches (the latest UPDATE and all patches not in that). (It would be
nice if PRODUCT INSTALL were supported within the restricted DCL
environment!) I first applied the PCSI patch, and it said I could
either log out and log back in or do a "SET COMMAND". I chose the
latter. The next installation complained about "BLOCK_SIZE".
Apparently the installation went OK though. To me, this looks like the
SET COMMAND didn't take effect. Has anyone seen this?
Since I was installing from a different account than the one I normally
use for installation, the installation of the UPDATE kit crashed due to
too low quota. I then modified the account, logged out and logged back
in, and repeated the installation. It apparently went through OK (here
and in the above case if PRODUCT tells me it has been successfully
installed, I'm hoping that that is in fact the case), but gave some
strange "kitnotsame" messages, though of course it was the same kit.
I also noticed in the ACRTL patch it sometimes says in the text file
that it is for 8.2 rather than 7.3-2, but in other cases talks about
7.3-2, which is apparently correct. Probably a cut-and-paste error.
I'm also confused about the PCSI messages regarding the saving of
recovery data. Normally, I apply a few patches one after the other,
then reboot once when I am done (then usually again after an AUTOGEN a
day or two later). One is advised to save recovery data, but the
messages make it sound like one can undo only the last patch applied,
though based on other messages this is not completely clear. Can anyone
explain this in detail? If one can only undo the last patch, I don't
see much benefit from this, but I also don't see any reason for this
restriction. Or am I missing something?
Due to lack of time and wide-SCSI expansion boxes, as a backup I just
have the other member of the original system disk. As soon as I feel
happy with 7.3-2, I'll add it back to the system-disk shadow set and
will have no 7.3-1 system disk anymore. Thus, I'm particularly
interested in what the strange errors above actually mean and whether I
can safely move permanently to 7.3-2 (i.e. overwrite the 7.3-1 system
disk with a shadow copy).
- Next message: Stevie B: "unsubscribe"
- Previous message: Richard Maher: "New Cluster Interconnects"
- Next in thread: Peter 'EPLAN' LANGSTOEGER: "Re: upgrade 7.3-1 --> 7.3-2"
- Reply: Peter 'EPLAN' LANGSTOEGER: "Re: upgrade 7.3-1 --> 7.3-2"
- Reply: George Cook: "Re: upgrade 7.3-1 --> 7.3-2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
