Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Merging System Disks

Robert Atkinson
Respected Contributor

Merging System Disks

We currently have a 3 node cluster. 2 nodes share a system disk, SYS0 and SYS10.

The other (development) node has it's own system disk (SYS0), but we've decided we're going to bring it onto the main System disk as (SYS20), which will reduce the amount of housekeeping (patches, UAF, etc).

Does anyone have a tick list that I can check through to see if I've missed any key points.

I've got the obvious stuff like SYSUAF/RIGHTSLIST, new TCP/IP config, new DECNET config, create new system root, and am looking for the less obvious tasks?

Thanks, Robert.
6 REPLIES
Karl Rohwedder
Honored Contributor

Re: Merging System Disks

- special queues to be migrated
- layered products and/or application software
- data from MODPARAMS.DAT
- adjust quorum?


regards Kalle
Hein van den Heuvel
Honored Contributor

Re: Merging System Disks

Were sysuaf and rightslist not already shared?
If not, there are several writeup on how to merge those, with convert. Be sure to specify /exception=xxx.exception to catch probleme records

sys$system:vmsmail_profile.data

sys$system:VMS$PASSWORD_HISTORY.DATA (allthough a one time amnestie (amnesia!) is probably acceptable)

Hein.


Robert Atkinson
Respected Contributor

Re: Merging System Disks

Not already shared, but based on the number of records will be easier to do a manual check/copy.
Joseph Huber_1
Honored Contributor

Re: Merging System Disks


Well then there are the queue definitions:
if there are different queues to keep, best save the current definitions: use the FIXQUEUE.COM procedure from Keith Parris, on the freeware V6 I think. It creates a command file to restore the queues.

http://www.mpp.mpg.de/~huber
Robert Atkinson
Respected Contributor

Re: Merging System Disks

No queues defined on that node, so nothing to take over.
Art Wiens
Respected Contributor

Re: Merging System Disks

Have a close look at what might be in SYS$SYSROOT areas on your dev system ie. don't just assume what's in SYS$COMMON is it. Depending on the age of the system disk, there was a problem a long time ago where editing a file eg: SYS$MANAGER:SYLOGIN.COM (read from SYS$COMMON:[SYSMGR]) would write it out in SYS$SYSROOT:[SYSMGR] ... laying in wait all these years until one day someone decided to merge it with another ;-)

Cheers,
Art