Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename
From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 04/19/05
- Next message: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Previous message: nutznbolz: "Re: Login mystery"
- In reply to: Hoff Hoffman: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Next in thread: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Reply: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Reply: Hoff Hoffman: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 19 Apr 2005 07:10:12 +0000 (UTC)
In article <K_V8e.4096$BU.1984@news.cpqcorp.net>, hoff@hp.nospam (Hoff
Hoffman) writes:
> In article <d416ql$4kh$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
> :What I mean is that I now have, say, SYS$NODE_FOO. I want to add a new
> :node, BAR.
>
> I will assume the new node is licensed for all products found on the
> existing node.
Yes; there is a common license database with the hobbyist PAKs. Of
course, the new node has its own base license with /MODIFY/INCLUDE=NODE.
[Sidebar: the license database is on a non-system disk, which is
shadowed. So first, each node mounts this disk (and has its own
system-disk shadow set, of course) and I get a message complaining that
there is no shadowing license. The disk mounts anyway, though. I then
do an explicit LICENSE LOAD. I suppose that this is intended to work
this way. The alternative would be to maintain local license databases
with everything one needs until the main one is loaded.]
> There is extra effort involved in the parallel management of OpenVMS
> software installations; by running parallel system disks, of course.
Right, but my hardware doesn't support dual-ported disks, and I like the
robustness of being able to lose a node.
> Officially, you'll want to perform a clean installation of OpenVMS
> and of the layered products.
Right, that's the supported way. However, I doubt that shops which have
hundreds of system disks actually upgrade them individually; they
probably upgrade a master disk, make copies of it and change the node
names appropriately.
> To (try to) replicate, add SYS$NODE_BAR to the shared RIGHTSLIST, then
> shut down FOO::, BACKUP/IMAGE the system disk to another node, mount
> the target disk, disable the network startups for TCP/IP services and
> for DECnet Phase IV (and I'd blow away the network database files) and
> such, set NISCS_LOAD_PEA0 and CLUSTER parameters for non-clustered
> operations, set SCSNODE to BAR, copy over clones of the shared SYSUAF
> and RIGHTSLIST files for the initial node operations, boot the disk on
> the target host system, and then re-configure the host network stacks,
> get rid of the temporary SYSUAF and RIGHTSLIST files, grab a copy of
> the and CLUSTER_AUTHORIZE.DAT file, set NISCS_LOAD_PEA0 and CLUSTER
> system parameters for clustered operations, shut down and reboot.
OK. One question: to add the SYS$NODE_BAR identifier, does it matter
what the numerical value is?
> I have probably missed a few steps here.
>
> And do please note that the above is *NOT* officially supported.
Yes, I realise the only way is to upgrade/install each system disk
individually, for OS and LPs.
> I don't generally recommend cloning disks -- it usually works, but it
> is not supported. It is often easier to go to a common system disk --
> which would be my preference, as managing multiple parallel individual
> system disks is, well, work -- or to perform the work and to reinstall
> the products on the new (parallel) system disk. (Cloning system disks
> means that the products are replicated as well as the existing cruft.)
Right, but my hardware doesn't support more than one direct connection
to a disk, and it DOES take a long time to install all the layered
products, so I want to do it just once.
> Now if there are no shared interconnects or such, well, I definitely
> feel your pain. :-)
Right, these are mostly VAX(station) 4000 systems, built around 1990,
and a couple of early 90s ALPHAs.
- Next message: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Previous message: nutznbolz: "Re: Login mystery"
- In reply to: Hoff Hoffman: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Next in thread: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Reply: Phillip Helbig---remove CLOTHES to reply: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Reply: Hoff Hoffman: "Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|