topic Merging System Disks in Operating System - OpenVMS

Merging System Disks

Robert Atkinson — Fri, 10 Nov 2006 06:36:09 GMT

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.

Re: Merging System Disks

Karl Rohwedder — Fri, 10 Nov 2006 06:57:39 GMT

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

regards Kalle

Re: Merging System Disks

Hein van den Heuvel — Fri, 10 Nov 2006 07:56:22 GMT

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.

Re: Merging System Disks

Robert Atkinson — Fri, 10 Nov 2006 08:09:16 GMT

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

Re: Merging System Disks

Joseph Huber_1 — Fri, 10 Nov 2006 08:28:58 GMT

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.

Re: Merging System Disks

Robert Atkinson — Fri, 10 Nov 2006 08:36:54 GMT

No queues defined on that node, so nothing to take over.

Re: Merging System Disks

Art Wiens — Fri, 10 Nov 2006 18:01:41 GMT

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