Phillip Helbig (undress to reply)
2014-12-21 12:32:14 UTC
Yes, there have been discussions about this here before, but I want to
revive them, for two reasons. First, to get some feedback about a new
concept and second with VMS 8.4 in mind.
The general idea has been to copy the system disk and "change the node
name", which is quite complicated but various aspects of it have been
discussed at length. I did this a couple of times after replacing two
VAXes in my cluster with ALPHAs. It worked, but is not very
straightforward. I want to do something similar in the context of an
upgrade, i.e. upgrade a master system disk then propagate the changes to
other system disks.
I have never done this in the context of an upgrade. Back when I had a
mixed cluster, I had to do two upgrades anyway, and adding a third
wasn't that much difference. With 3 homogeneous cluster now, it means
about three times the work, not 50% more.
'Tis the season to be jolly, errr, to upgrade to VMS 8.4. :-) It looks
like I finally have the time to do so. I have been at 7.3-2 for about
10 years. Various distractions kept me from upgrading, then when I
finally had the time the access to patches for hobbyists was stopped; I
didn't want to upgrade and then experience a problem I couldn't get
patches. Around the time the new hobbyist programme was sorted out, it
looked like the writing was on the wall because of lack of Poulson
support. (This didn't affect me directly, but made an upgrade less
urgent. If 8.4 was to be the last anyway, there is no reason to rush
it.) Now, I am looking forward to VMS on x86 and hope that VSI will
support a mixed ALPHA/x86 cluster, at least for migration. Even if they
don't and I have to go to a higher VMS version and/or to Itanium first,
8.4 is better than 7.3-2.
I had been thinking that it is fortunate that I have an 8.3 hobbyist CD,
since I thought I couldn't go directly from 7.3-2 to 8.4. However,
looking at the OS upgrade chart at HP, it looks like I CAN go directly
from 7.3-2 to 8.4.
Is this correct?
Has anyone here done it?
Is there some reason to nevertheless go via 8.3?
Is there some reason to upgrade to 8.3 now, and to 8.4 later?
I am using 4-GB system disks now. Will this still be sufficient for
8.4, including various layered products etc?
I have the 8.3 CD and patches for 7.3-2, 8.3 and 8.4 which were
available on 16-SEP-2010. My source for 8.4 and newer patches will be
via the hobbyist download site. Is anyone running 8.4 with only the OS
and patches available from the hobbyist download site? Is there any
reason not to upgrade to this configuration?
All the system disks (one for each boot server) are two-member shadow
sets, so producing copies by making and breaking shadow sets is
straightforward. Rather than "changing the node name", my new idea is
to first get all system roots onto all disks and in synch. (I already
have separate numbers for the SYS$SPECIFIC root for each bootserver
node, even though there is only one node booting from each disk.) The
idea is then to upgrade one disk and then just use a direct copy for the
other nodes, the idea being that all the node-specific stuff is in
SYS$SPECIFIC. (Alternatively, I could upgrade a master disk and then
copy SYS$COMMON:[*...]*.* to the other disks. However, this would be
more work than the "automatic" shadow copies. It would avoid having all
system roots on all disks, though.)
This assumes, of course, that all node-specific stuff is in
SYS$SPECIFIC:[*...]. Is this actually the case? Or is their some
software which doesn't follow this convention? (Note: I have only DEC/
Compag/HP stuff on the system disk; none of my own stuff nor any third-
party software.)
I have long since moved SYSUAF etc (the stuff in SYLOGICALS.TEMPLATE as
well as ACCOUNTNG and VMS$AUDIT_SERVER; I also define OPC$LOGFILE_NAME
to be somewhere else) off the system disk. What I tested for a while
with ONE of the VAX nodes was defining various TCPIP logicals to move
some stuff which should be common to all nodes. These were:
TCPIP$CONFIGURATION
TCPIP$HOST
TCPIP$PRINTCAP
TCPIP$NETWORK
TCPIP$PROXY
TCPIP$ROUTE
TCPIP$SERVICE
Presumably it would be better to enable this functionality for all nodes
first before doing any upgrading. Since the default location is in
SYS$COMMON and not in SYS$SPECIFIC, but contains information about
individual nodes, presumably there is some node-based stuff in there,
breaking with the tradition that all node-specific stuff should be in
SYS$SPECIFIC. I guess this means I will have to reconfigure TCPIP on
each node after the upgrade. I guess I would have to do this in any
case, but having this stuff off the system disk should make replicating
the system disk simpler, and might mean that I don't have to reconfigure
as much on each node.
Does anyone here actually define the logicals above to point to
somewhere off the system disk?
revive them, for two reasons. First, to get some feedback about a new
concept and second with VMS 8.4 in mind.
The general idea has been to copy the system disk and "change the node
name", which is quite complicated but various aspects of it have been
discussed at length. I did this a couple of times after replacing two
VAXes in my cluster with ALPHAs. It worked, but is not very
straightforward. I want to do something similar in the context of an
upgrade, i.e. upgrade a master system disk then propagate the changes to
other system disks.
I have never done this in the context of an upgrade. Back when I had a
mixed cluster, I had to do two upgrades anyway, and adding a third
wasn't that much difference. With 3 homogeneous cluster now, it means
about three times the work, not 50% more.
'Tis the season to be jolly, errr, to upgrade to VMS 8.4. :-) It looks
like I finally have the time to do so. I have been at 7.3-2 for about
10 years. Various distractions kept me from upgrading, then when I
finally had the time the access to patches for hobbyists was stopped; I
didn't want to upgrade and then experience a problem I couldn't get
patches. Around the time the new hobbyist programme was sorted out, it
looked like the writing was on the wall because of lack of Poulson
support. (This didn't affect me directly, but made an upgrade less
urgent. If 8.4 was to be the last anyway, there is no reason to rush
it.) Now, I am looking forward to VMS on x86 and hope that VSI will
support a mixed ALPHA/x86 cluster, at least for migration. Even if they
don't and I have to go to a higher VMS version and/or to Itanium first,
8.4 is better than 7.3-2.
I had been thinking that it is fortunate that I have an 8.3 hobbyist CD,
since I thought I couldn't go directly from 7.3-2 to 8.4. However,
looking at the OS upgrade chart at HP, it looks like I CAN go directly
from 7.3-2 to 8.4.
Is this correct?
Has anyone here done it?
Is there some reason to nevertheless go via 8.3?
Is there some reason to upgrade to 8.3 now, and to 8.4 later?
I am using 4-GB system disks now. Will this still be sufficient for
8.4, including various layered products etc?
I have the 8.3 CD and patches for 7.3-2, 8.3 and 8.4 which were
available on 16-SEP-2010. My source for 8.4 and newer patches will be
via the hobbyist download site. Is anyone running 8.4 with only the OS
and patches available from the hobbyist download site? Is there any
reason not to upgrade to this configuration?
All the system disks (one for each boot server) are two-member shadow
sets, so producing copies by making and breaking shadow sets is
straightforward. Rather than "changing the node name", my new idea is
to first get all system roots onto all disks and in synch. (I already
have separate numbers for the SYS$SPECIFIC root for each bootserver
node, even though there is only one node booting from each disk.) The
idea is then to upgrade one disk and then just use a direct copy for the
other nodes, the idea being that all the node-specific stuff is in
SYS$SPECIFIC. (Alternatively, I could upgrade a master disk and then
copy SYS$COMMON:[*...]*.* to the other disks. However, this would be
more work than the "automatic" shadow copies. It would avoid having all
system roots on all disks, though.)
This assumes, of course, that all node-specific stuff is in
SYS$SPECIFIC:[*...]. Is this actually the case? Or is their some
software which doesn't follow this convention? (Note: I have only DEC/
Compag/HP stuff on the system disk; none of my own stuff nor any third-
party software.)
I have long since moved SYSUAF etc (the stuff in SYLOGICALS.TEMPLATE as
well as ACCOUNTNG and VMS$AUDIT_SERVER; I also define OPC$LOGFILE_NAME
to be somewhere else) off the system disk. What I tested for a while
with ONE of the VAX nodes was defining various TCPIP logicals to move
some stuff which should be common to all nodes. These were:
TCPIP$CONFIGURATION
TCPIP$HOST
TCPIP$PRINTCAP
TCPIP$NETWORK
TCPIP$PROXY
TCPIP$ROUTE
TCPIP$SERVICE
Presumably it would be better to enable this functionality for all nodes
first before doing any upgrading. Since the default location is in
SYS$COMMON and not in SYS$SPECIFIC, but contains information about
individual nodes, presumably there is some node-based stuff in there,
breaking with the tradition that all node-specific stuff should be in
SYS$SPECIFIC. I guess this means I will have to reconfigure TCPIP on
each node after the upgrade. I guess I would have to do this in any
case, but having this stuff off the system disk should make replicating
the system disk simpler, and might mean that I don't have to reconfigure
as much on each node.
Does anyone here actually define the logicals above to point to
somewhere off the system disk?